Acceptance Testing Before Go-Live: Testing Without Wasting Time
Testing done by clicking buttons at random always passes. Testing that imitates a real working day always finds something.
Test with scenarios, not feature lists
Write five to ten scenarios that represent real work, for example: a lead arrives from the website, is assigned to sales, gets a quote, is approved by a manager, becomes an order, then is invoiced. Run them end to end, not screen by screen.
Users test, not the project team
The people who will use the system daily find problems its designers never imagined. Give them dedicated time rather than squeezing it between tasks.
Use data that resembles reality
Real customer names with details masked, plausible numbers, and the odd cases that genuinely happened, such as a customer with two billing addresses. Those odd cases are what usually break the configuration.
Record findings in three levels
- Blocker: cannot go live until fixed.
- Irritation: can be fixed in the first week.
- New request: goes on the next phase list, not patched in just before launch.
This separation stops a project being delayed by requests that are not actually problems.
Do not test alone at the end
Test each part as it is completed. Stacking all testing into the last week turns every finding into an emergency.
Close with written sign-off
One page stating which scenarios passed and which findings are deferred. It protects both sides. See the first 90 days after go-live.