LUMINAR // EXECUTION LAYERFIELD NOTESYSTEM LIVE · --:--:-- AEST
Luminar/Field notes/Testing a first WMS
Field note · 20

Testing a first WMS.

On a greenfield site the people who will run the warehouse have often never held a scanner. That changes what testing is for. It is not only proof the system works. It is the first time the floor meets the system, and the first impression decides whether they trust it on Monday.

A test bay inside a new warehouse, a pallet of mixed cartons on a floor scale beside a label printer on a steel bench, an RF scanner resting on the cartons and a printed test script clipped to the racking upright.
Field note Real product, real bins, real people

The standard test plan comes from the specification. Every function in the design document gets a script, every script gets a tester, every tester gets a pass or fail column, and at the end there is a percentage that looks like confidence. On a brownfield site that approach is merely incomplete. On a greenfield site with a first WMS it is close to useless, because it tests whether the system does what the document says and not whether a person who has never used a scanner can run a shift with it.

What a passing test proves.

A UAT that passes on the integrator's data, with the integrator's consultants at the keyboard, in a training client that does not match the racking, proves that the configuration is internally consistent. That is worth knowing. It is not what you need to know. What you need to know is whether the receiver can book in a mixed delivery when the ASN is wrong, whether the picker can finish a wave when a bin is empty, whether the supervisor can find out where a pallet went without calling the project team. None of that is in the specification, and all of it is what the first week live is made of.

Write the scripts from a shift.

Start with a day. Not a function list, a day: the first truck arrives at six, the receiving team books it in, putaway runs, the morning wave releases, picking starts, a customer rings to change an order, a pallet is found damaged, the afternoon dispatch is built, the last truck leaves, the shift closes. Write the test as that sequence, in that order, with the exceptions where they actually happen. Then run it, end to end, with the people who will do each job, on the floor if the floor exists and on the closest thing to it if not.

This does two things. It finds the gaps between functions, which is where most greenfield defects live, because each function was tested alone and passed alone. And it puts the system in the operators' hands for a full day before it counts, which is the first step of readiness and not, as most plans have it, a separate phase that starts after test is signed off.

Second opinionWant the test plan read against a real shift?

Real product, real bins, real people.

Real product.

Test with the product that will be in the warehouse, physically, on pallets, with the labels it will arrive with. Sample data proves nothing about whether the carton quantity is right or the pallet fits the bin. On a greenfield site this is also the first time the master data meets the physical goods, and it will find errors that no desk check could.

Real bins.

As soon as the racking is in, test in it. Scan the actual bin labels, drive the actual aisles, find out that the RF signal drops in the back corner and that the label on the top beam cannot be read from the forklift. Every one of those is a defect, and none of them is in the system.

Real people.

The receiver tests receiving. The picker tests picking. The supervisor tests the exceptions and the reporting. The consultants watch and write down every place the operator hesitates, because a hesitation in test is a workaround in production. If the people who will run the floor are not available for test, the programme has a problem that is bigger than testing, and it is worth naming it to the sponsor as such.

What to do with what you find.

A shift-based test on a greenfield site finds three kinds of things. System defects, which go to the integrator. Data defects, which go to the data owner and are usually the largest group. And process gaps, where the design assumed something the floor cannot do, which go back to the process owner and are the ones worth finding most, because they are the ones that would otherwise have become a decade of habit. Track all three separately. A defect log that mixes them hides the fact that the system is fine and the process is not.

A test pass rate tells you the system matches the document. A supervisor who takes a shift end to end without calling the project team tells you the warehouse will open.

How Luminar approaches testing.

We write the acceptance test as a shift, with the operations team, before the integrator writes theirs, so the two can be compared. We insist it runs on real product in real bins with the people who will do the job, and we stand beside them while it does. And we treat the first full-day test as the start of readiness rather than the end of test, because on a first WMS the two were never really separate. We have written about what readiness actually means in Readiness is not training.

Part of the greenfield build seriesTest · 14 of 20
Before UAT starts

Test the shift, not the spec.

A day with the test plan, the floor and the people who will run it, and a plain-language memo on what the plan will prove and what it will miss.