WMS UAT Test Cases: The Complete Warehouse User Acceptance Testing Checklist

User acceptance testing is one of the most effective ways to reduce operational risk during a WMS migration or feature rollout. Even so, it's often compressed into the final weeks of a project. Test cases are assembled quickly, stakeholder reviews are limited, and most of the attention goes to whether standard transactions can be completed.

That can create false confidence.

A receiving test may pass because the WMS accepts an ASN, records the receipt, and creates inventory. Everything seems like it's working until the warehouse receives fewer units than expected. The receiver enters the quantity physically received, but the system closes the receipt using the full ASN quantity. The transaction completes without an error, but the WMS now shows inventory that never arrived.

The standard test confirmed that receiving could work when everything matched. The exception test determines whether the process protects inventory accuracy when it doesn't. That is where UAT provides its real value.

A useful set of WMS UAT test cases has to do more than confirm screens, buttons, and status changes. It should test the full physical and system workflow: the handheld prompts, labels, task states, inventory records, integrations, role permissions, and recovery steps that warehouse teams depend on after go-live.

The downloadable WMS UAT test case workbook included with this guide contains 139 scenarios across inbound, inventory, outbound, integrations, permissions, performance, and recovery. Use it as a starting point, then tailor it to the workflows, customers, automation, and exception paths in your facility.

Feature Testing Confirms the Software. Operational UAT Confirms the Warehouse.

Feature testing asks whether a function is in line with its design. A tester creates an ASN, receives the expected quantity, and confirms inventory appears. It's certainly needed, but it's only part of an effective testing regimen.

UAT asks whether the complete warehouse process runs under realistic conditions. The test includes the order source, the user role, the handheld, the label printer, the physical inventory, the integration messages, the exception path, and the downstream result. It also verifies that supervisors can identify and recover the problem when the standard path breaks.

Consider a short pick. The picker enters a short quantity and closes the task. The test isn't complete until the team confirms what happens next. Does the WMS deallocate the missing quantity? Does it create a count task automatically? Does the order reallocate from another location? Does the upstream OMS receive the correct shortage status? Can the picker continue working, or does the container become stranded in?

During any shift, a supervisor sees five short picks stack up with no clear indication whether replenishment failed, inventory is missing, or allocation selected stale stock. The RF screens all say the same thing. The dashboard shows the orders progressing. But nobody on the floor knows what's actually happening to those five orders. That gap is what operational UAT is designed to close.

What Every WMS UAT Test Case Should Include

Before running scenarios, the team needs a consistent structure for documenting each test case. A scenario that says "Test short pick, expected result: works as designed" won't support a go-live decision. Each test case should specify:

• The physical starting condition what inventory, order, container, location, and device state exists before the test begins.
• The required test data SKU, UOM, lot, serial, LPN, order type, owner, location, and any integration conditions.
• The role and device executing the test the person running the scenario should match the person who will run it in production.
• The exact transaction steps scans, confirmations, approvals, exception actions, and any manual overrides.
• The expected WMS result inventory balance, task status, order state, container record, and shipment state.
• The expected floor result what the associate sees, what label prints, where the physical unit goes next.
• The expected integration messages what the ERP, OMS, WCS, carrier, or EDI system should receive at each state transition.
• The evidence required to pass screenshot, transaction history, printed label, interface log, or reconciliation file.
• The recovery path when the scenario fails what the operator does, what the supervisor checks, and whether a retry creates a duplicate.

You will discover gaps in this structure during the first test cycle. That's normal. Update the template and re-run the affected scenarios.

WMS UAT Test Cases by Warehouse Workflow

The best test cases start with a physical scenario, not a screen. A transaction can be recorded correctly while the workflow remains impractical. Directed putaway may choose a technically eligible location the pallet won't fit into. A pack station may create a valid carrier label the outbound sorter can't read. The test has to verify both the system result and the floor result.

What follows is organized around how work actually flows through a building. The downloadable WMS UAT test case template expands each area into executable scenarios with priorities, test types, evidence fields, and status controls.

• Environment, configuration, and master data. Teams often spend days diagnosing a failed workflow that's actually running against an outdated configuration, an old interface mapping, or incomplete item data. Validate the foundation first: application version, feature flags, facility settings, calendars, cutoffs, time zones, item attributes, units of measure, case packs, dimensions, weights, lot and serial controls, locations, zones, users, roles, printers, handhelds, carrier accounts, and automation endpoints. Reconcile migrated inventory, open orders, allocations, holds, and task states. A unit-of-measure error can pass unnoticed through receipt and surface during picking when the system receives 12 each but the order interface sends demand in cases.
• Receiving and ASN exceptions. Test overages within tolerance, overages above tolerance, short shipments, partial receipts, unexpected SKUs, duplicate carton IDs, damaged inventory, missing lot or serial data, and ASNs that arrive late or not at all. A red error message isn't an operational process. The associate needs to know whether to retry, relabel, move the unit to problem-solving, or wait for a supervisor. During UAT, a receiver with three unlabeled pallets staged at the dock while IT determines whether the receipt committed is a real scenario. Test it.
• LPN creation and labeling. Label and license plate failures create inventory discrepancies quickly because the physical identifier is what connects the pallet, carton, or tote to its WMS record. Test WMS-generated LPNs, supplier SSCCs, duplicate labels, reprints, splits, merges, nested containers, and parent-child relationships. Disconnect the printer after the WMS commits the transaction, restore it, and retry. The expected behavior should distinguish between reprinting the same identifier and creating a new container record. If the team can't answer that question from the test result, the scenario hasn't passed.
• Directed putaway. Putaway problems often appear only after the team starts using realistic inventory. A location may be technically eligible because the configuration allows the SKU but still be unusable because the pallet won't fit, the aisle is blocked, or the location already contains an incompatible lot. Test the rules, but also test the target location the associate is sent to. Make the suggested location unavailable mid-test. Mark it full, block the aisle, or scan the wrong location. The WMS should provide a controlled alternate path without losing the source inventory or creating duplicate work.
• Inventory, holds, counts, and adjustments. Place inventory on hold at every supported level. Move it, count it, attempt to allocate it, then release part of it. The hold should survive movement and remain visible in inquiry and reporting. Test cycle counts with blind counts, zero variance, recount thresholds, mixed-SKU locations, found inventory, and missing inventory while warehouse movement is active. Confirm whether the WMS freezes the location, snapshots the book quantity, or dynamically accounts for concurrent transactions. Test adjustment permissions through every path: a user who can't adjust inventory on a handheld shouldn't be able to bypass the restriction through a desktop screen or API.
• Allocation, waves, and replenishment. Run concurrent waves against limited inventory to confirm the same units aren't reserved twice. Cancel orders before allocation, after allocation, after picking starts, and after packing begins. An allocated order cancellation crosses multiple states: unpicked inventory may need release, picked inventory may need a return-to-stock, open tasks should disappear, and the OMS should show a status that matches the floor. For replenishment, test that tasks arrive before the picker reaches an empty location. A replenishment task can be technically correct and still fail the operation if it shows up after the forward pick location is already dry.
• Picking and short-pick handling. Scan the wrong location, wrong SKU, wrong LPN, and wrong lot. Enter a partial short and a zero-found short. Disconnect the device before and after quantity confirmation. The picker should be able to recover without restarting the entire route. Follow the short pick through the full exception: does the WMS create a count, deallocate the shortage, search another location, hold the order, or send a shortage upstream? The test isn't finished when the RF task closes. During a live shift, a supervisor watching five short picks accumulate with no explanation is experience, not a test case. UAT should simulate that situation before it becomes experience.
• Packing, shipping, and returns. Compare cartonization recommendations with the physical order. Item dimensions may be missing or inaccurate. A suggested carton may satisfy volume but fail on product orientation, dunnage, weight distribution, or carrier restrictions. For shipping, test carrier timeouts on both sides of the commit so one carton doesn't end up with two active labels and two charges. When pack stations stop because carrier labels are timing out but the dashboard still shows orders as processing, the WMS is reporting a state that doesn't match the floor. Test returns: authorized, unauthorized, wrong items, damaged units, and disposition routing. Returned inventory shouldn't become available before inspection completes. Returns are often tested lightly because launch teams focus on outbound, and that gap surfaces the first week after go-live.

Integration, Permission, and Concurrency Testing

An interface test isn't complete because a message reached the WMS. Send the same order twice. Replay a failed receipt confirmation. Deliver a cancellation after allocation. Send an inventory update out of order. Stop an integration after the downstream system commits but before the source records success. Each scenario should prove that retry behavior is idempotent and state can be reconciled across systems. For automation, validate the full container lifecycle: induction, routing, exception reporting, and completion. A physical container should never disappear between two systems because each side assumes the other owns recovery.

For role permissions, test every workflow with the actual roles that will use it, not as an administrator who bypasses restrictions. Administrators can make weak workflows look functional because they see additional fields and have recovery options floor users won't have. A receiver should be able to receive. The same user shouldn't be able to release a quality hold or reopen a manifested shipment unless that authority is approved. Test handheld behavior under real conditions: scan response, session timeout, invalid-scan messages, battery loss, WiFi interruption, and work resumption.

Single-user testing won't expose contention or integration lag. Run receiving, picking, packing, replenishment, inventory, and interface activity at the same time. Measure response at the handheld, not only at the application server. Test failure recovery for every dependency: application restart, printer outage, zone-level network loss, device failure, and carrier timeout. Reconcile every in-progress order, LPN, carton, task, and shipment afterward. The team should know which transactions committed, which must be retried, and which physical units need inspection.

Go-Live Acceptance Criteria That Mean Something

A test team shouldn't discover its acceptance rules during the go-live meeting. Define thresholds, required evidence, owners, waiver authority, and the decision process before final execution. All critical scenarios executed. No open critical defects. No high-severity defects without an approved workaround and accountable owner. Inventory and open-order migration reconciled within approved tolerances. Peak-volume and recovery tests completed within operational thresholds.

Don't use overall pass rate as the only readiness measure. A project can show a 94% pass rate while the remaining failures affect inventory integrity, shipment confirmation, allocation, or label generation. One unresolved state-control defect carries more launch risk than dozens of passed low-impact scenarios.

Review Your UAT Coverage Before Launch

Before approving UAT, review the test plan against the physical exceptions that could stop work during the first week of go-live. Look for missing scenarios involving partial transactions, duplicate messages, unavailable locations, label failures, short picks, device disconnects, and mismatched order states across systems. If the test plan proves only that the normal transaction works, it isn't ready to support a warehouse launch.

Download the WMS UAT test case workbook to review your current coverage, assign owners, document evidence, and define go-live acceptance criteria.