Test a change · 4 pages

Operational go-live test checklist

Prove the new workflow works during normal work, busy periods, mistakes, and outages before accepting it.

Fill it in online · Print or save as PDF · Your entries are not uploadedNot sure about a term? Open the plain-English glossary
How to use this worksheet
  1. Fill it out with workers who do the job.
  2. Use actual observations or system records.
  3. If an answer is uncertain, write what still needs to be checked.

Your answers stay only in this open page. Print or save a PDF before closing or reloading it.

Use this when

Before accepting a vendor solution or scaling a successful test.

See a filled-example scenario

Test T-07 disconnects the network after a command. The tote remains identifiable, no false completion posts, and the task stays pending.

The gray examples inside the fields show the level of detail expected. They are examples only and are not saved as answers.
Warehouse Workflow Lab

Operational go-live test checklist

Published by Voodoo Robotics · workflows.voodoorobotics.com

01

Test control

What to do: Define the exact equipment, software, test area, data, and people approving the result.

02

Normal-flow tests

What to do: Use one row for each normal task that must work.

This section is a list.Use one row for each task, observation, test, person, field, or requirement. Add more rows when needed.
Test IDGive each test a short unique code so failed tests can be tracked through retesting.
PreconditionState what must be true before the test begins.
Input / actionWrite a visible action with a named owner and finish condition.
Expected physical stateDescribe what the worker should see in the warehouse after the action.
Expected system eventDescribe the record or status the software should create.
Pass / fail evidenceRecord both the result and the proof used to judge it.
03

Exception and failure tests

What to do: Use one row for each shortage, wrong item, no-read, delayed or repeated message, outage, power failure, backup method, and record-repair test.

This section is a list.Use one row for each task, observation, test, person, field, or requirement. Add more rows when needed.
Test IDGive each test a short unique code so failed tests can be tracked through retesting.
Failure scenarioDescribe the exact shortage, wrong item, no-read, delay, outage, or other problem being tested.
Expected responseState what the worker, equipment, and software should do when this problem occurs.
Actual responseRecord what really happened during the test, including any delay or workaround.
Pass / fail evidenceRecord both the result and the proof used to judge it.
Owner / next stepName the person responsible for this decision, task, or approval.
04

Performance and usability

What to do: Test a safe pace that workers can repeat, not a short best-case burst.

05

Disposition

What to do: Use one row for each failed test until it is fixed, retested, and accepted.

This section is a list.Use one row for each task, observation, test, person, field, or requirement. Add more rows when needed.
Open defectDescribe what went wrong, where it was noticed, and the practical effect.
SeverityChoose how serious the effect is using the scale agreed for this worksheet.
WorkaroundDescribe the temporary safe method used while this defect remains open.
OwnerName the person responsible for this decision, task, or approval.
Retest dateEnter the exact date, due date, or review frequency.
Final acceptanceChoose the final decision after the failed test is fixed and retested.

Keep related photos, drawings, reports, and system records with the saved PDF. This worksheet does not replace site-specific safety, quality, regulatory, or engineering review.

Reviewed byDate
← All practical worksheets