Testing and user acceptance

“Try the system and tell us what you think” is not a test plan. It is an invitation to chaos.

A user left without a scenario tries only what they already know, writes cosmetic notes about the colours, and never touches the exceptional case that will break the system in its first week.

UAT is not an opinion survey. It is proof that a process works end to end.

Two layers, not one

Layer	Who runs it	What it proves
System integration testing	The implementation team	The cycle works technically across modules and integrations
User acceptance testing	The users themselves	The process works the way the business works

Conflating the two is the common error. Invite users to test a system that has not passed integration testing and they spend their time reporting faults that should have been caught before them, lose confidence, and never reach what they came for.

So UAT does not start before integration testing passes on every major scenario. That is an entry condition to be written, not assumed.

The written scenario

Every scenario has three columns, and nothing less is accepted.

Step	What you do	Expected result
1	Raise a requisition for item X, quantity 10	Saved and routed to the department manager for approval
2	Approve as the manager	Becomes a purchase order with a sequential number
3	Receive 8 units	Journal: inventory 8 × cost debit, accrual credit

The third column is the entire test. Without an expected result written in advance there is no test — there is a person looking at a screen deciding whether it seems right.

Who writes the expected result? The key user with the consultant, during design rather than during testing. Writing it at design exposes misunderstanding early, which is the cheapest way to find it.

The scenarios that get skipped

Most test plans cover the happy path. Faults come from everything else.

• Cancellation and returns: an order cancelled after partial receipt, a return after invoicing.
• Approval in the approver’s absence — and delegation, the most forgotten of all.
• Period close and an attempt to post into a closed period.
• Permissions: every role tested under its own account, verifying what it cannot do.
• Volume: a two-hundred-line document, and a full-year report.
• Printing: the actual invoice on paper, in Arabic, with its code.

The fourth is the most dangerous omission. Testing permissions by testing what a role can do is half a test; the other half is proving what it cannot. Skip it and you find after go-live that the storekeeper can change prices.

Grading defects

Three grades, defined before testing and published.

Grade	Definition	The rule
1 — blocker	A business process cannot be completed	Blocks go-live
2 — significant	The process completes with an acceptable workaround	Go-live with a written remediation plan
3 — cosmetic	Does not prevent work	Post-go-live list

Grading is against the work rather than against feelings. The argument “this is a blocker” is settled by one question: “can you finish your day’s work with this defect?” If yes — even with difficulty — it is grade two.

A daily triage meeting, fifteen minutes, during testing. A defect waiting two days to be graded stops a tester for two days, and tester capacity is the scarce resource, as in station four.

Environments — how many, and why

A one-environment project halts testing every time somebody needs to configure something.

Environment	For whom	What defines it
Development and configuration	The implementation team	Changes daily, and nothing is tested in it
Test and acceptance	The users	Stable, on real migrated data
Training	Trainees	A copy reset after each cohort
Production	—	Opened on cutover night

Conflating the second and third is the common error. A trainee creates test documents with arbitrary figures, then a tester opens a report and finds numbers they cannot source and raises them as a defect. Two hours are lost diagnosing training.

And the data in the acceptance environment must be real migrated data, not invented. Testing a sales cycle against a customer called “Test Customer 1” does not reveal that half your real customers have no payment terms.

The working rule: the acceptance environment is frozen. No configuration during testing except under an approved change, or the testers are testing a moving target and their results mean nothing.

The exit criterion

Written and approved before testing begins, not after.

Zero grade-one defects, no more than five grade-two defects each with a written remediation plan, and 100% of written scenarios executed successfully.

The reason for writing it in advance is psychological rather than procedural. A criterion written at the end of testing is written under deadline pressure, and becomes a description of reality rather than a condition on it.

Who signs acceptance? The key users, by name, each for their own cycle. Not the sponsor and not the IT manager. Signing off what you did not try yourself is not acceptance.

What you actually do in this station

• Write the scenarios in three columns during design, not a week before testing.
• Add the six skipped scenarios to your plan.
• Define and approve the defect grades before the first test day.
• Hold a daily triage for fifteen minutes.
• Write and approve the exit criterion in advance, and have each cycle signed by its user.

The three commonest mistakes

One: UAT with no scenarios. Opinions get collected instead of evidence.

Two: starting UAT before integration testing passes. Users’ time goes into faults that are not their concern, and their confidence is lost.

Three: writing the exit criterion at the end. It gets tailored to whatever was achieved.

The acceptance test for this station

1. Show three scenarios in their three columns.
2. Name the six skipped scenarios and their status with you.
3. Show the defect grade definitions and who approved them.
4. Show the exit criterion and its approval date against the testing start date.
5. Name who will sign acceptance per cycle.

What comes next

The system works. The next station is about the people who will use it: training and adoption — and why good training alone is not enough.