WMS acceptance testing checklist

Direct answer

WMS acceptance testing means running a written list of real warehouse scenarios through the system, using the people who will use it, and recording pass or fail for each. Concentrate on the cases that hurt today: the short-shipped delivery, the pallet with two SKUs, the pick that finds an empty location, the return with no paperwork. A demo shows the system working on clean orders. Acceptance shows it coping with yours.

This page is about scenario testing before you accept the build. Counting stock and running the go-live day are covered in the WMS go-live checklist; this page comes earlier and answers whether the system is ready to be counted into at all. If you are unsure how ready the warehouse itself is, the WMS readiness assessment is a quick way to see the gaps.

Scenarios

Write the scenarios before testing starts, and write them with the floor, not for it. Ask each shift lead for the five situations that cause the most rework, and add the ordinary flows around them. Each scenario needs a starting state, the steps a person takes, and the result you expect in stock, locations and documents.

Keep the list finite and numbered. Acceptance criteria that stay vague become arguments at sign-off. If a scenario cannot be described as a starting state, steps and an expected result, it is not ready to be a test.

• Ordinary flows: receive, put away, pick, pack, dispatch.
• The five costliest recurring problems, named by the people who live with them.
• Rare but expensive events: recalled stock, a mis-labelled pallet, a customer cancellation after picking.
• Anything the old process handled through a workaround, since the workaround must have a new home.

Roles

Test each scenario as the person who will do it, with the permissions that person will have. A supervisor account that can override everything hides problems that a picker will meet on day one. For every role, check what they can see, what they can change and what they are stopped from doing.

Include the negative tests: a picker should not be able to adjust stock quantities, and someone receiving should not be able to release a hold unless your process says they may. Confirm that overrides leave a record showing who did what and when.

Test data

Load a realistic slice of your master data: real SKU descriptions, real units of measure, real location naming, and the odd items that break rules, such as products sold in more than one pack size or items with batch or expiry tracking. A test built on five tidy products proves very little.

Prepare inbound and outbound documents that reflect real variety: partial deliveries, over-deliveries, orders with mixed stock, orders for the same item split across locations. Keep the test data set so it can be reloaded, and note its state before each run so results are comparable.

Receiving and putaway

Receive a delivery that matches its paperwork, then one that does not: a shortage, an overage, an unexpected item and a damaged carton. Check that each is recorded as you would want it, that stock on hold is not available to pick, and that labels produced are readable with the scanning equipment you actually use.

For putaway, confirm the system suggests or accepts sensible locations, rejects impossible ones, and handles a full location, a mixed-SKU pallet and an override by the operator. Then check that the stock now shows where it physically is, and that a second person can find it from the system alone. Verify with your own scanners and labels, in your own building; this test is about your setup working, not a general statement about any equipment.

Picking and short picks

Pick a normal order, then the difficult ones: a large multi-line order, an urgent order arriving mid-wave, an item in several locations, and a pick where the location is empty or holds less than expected. The short pick is the most important test in this section. Check what the picker sees, what the system does with the shortfall, who is told, and what happens to the order.

Follow each pick through to dispatch and check the stock movement is correct at every step, including when an order is amended or cancelled after picking has begun.

Adjustments

Adjustments are where accuracy is kept or lost. Test a stock correction, a cycle count with a difference, a move between locations, a write-off and a change of status such as quarantine. For each, confirm that a reason is recorded, that the right role can do it, and that the history shows the before and after.

Then look at the reports. A manager should be able to see recent adjustments by reason and by person without exporting anything, since patterns in adjustments are how process problems are found.

Returns

Test a return with an order reference, one without, a return of damaged goods and a return that should go back to stock. Check the item lands in the right status, is not pickable until released, and that the customer-facing side of the return can be traced. The full process design is in warehouse returns workflow; here you are confirming the built version follows it.

Sign-off

Sign-off is a record, not a mood. List every scenario with its result, the defects found and their status, and the people who ran the tests. Agree in advance which defects block acceptance and which can be scheduled after go-live, and write down who decides. Anything accepted with a known defect should have an owner and a target.

Keep the scenario list and results with the handover documents. They become the regression set for every later change and help train new staff on what the system is meant to do.