Test planning and UAT

Why it matters

A system can pass every technical test and still fail on its first morning, because it does not fit how people actually work. User acceptance testingTesting in which business users confirm, with realistic scenarios, that a system supports their work before go-live. (UAT) is where the business confirms that the system meets its needs, using realistic scenarios, before it goes live. The analyst usually plans UAT, writes or reviews the scripts and runs the triageA regular meeting that reviews new defects, agrees their severity and assigns them. meetings, because the analyst knows the requirements best.

Where UAT sits

Unit tests          developers test small pieces of code
Integration tests   interfaces between systems work (APIs, files)
System tests        the whole system against the specification (QA team)
UAT                 business users confirm it supports their work

UAT is not a hunt for every bug; earlier test levels do that. It answers one question: can we run the business on this? It needs a stable test environment, realistic (but anonymised) data, and real users from each affected group.

The UAT plan

A short plan covers:

• Scope: which processes and requirements are tested, and which are out of scope.
• Entry criteriaConditions that must be true before UAT starts, such as system test passed and test data loaded.: what must be true before UAT starts (for example: system test passed, no open critical defects, test data loaded, users trained).
• Testers and schedule: named people from each group (store staff, customer service, marketing, finance) with time released from their normal work.
• Defect process: how to log a defect, severity levels, and who decides what is fixed before go-live.
• Exit criteriaThe agreed definition of accepted, such as no open severity 1 or 2 defects, and who signs it off.: what "accepted" means (for example: all critical scenarios passed, no open severity 1 or 2 defects, workarounds agreed for the rest) and who signs.

Writing UAT scripts

Each script tests one business scenario, traced back to a requirement or user story, in steps a non-technical user can follow:

ID:            UAT-LOY-03
Requirement:   US-12 "As a store associate I can look up a customer's points at checkout"
Preconditions: Test customer Ana Rivera (HO-1001) exists with 1,250 points.
               Tester is logged into the POS test till as a store associate.

Step  Action                                       Expected result
1     Scan a test item and choose Find customer    Search box appears
2     Search by phone number 555-0101              Ana Rivera is shown as the only match
3     Select Ana Rivera                            Points balance shows 1,250
4     Complete the sale of 49.99 with card         Receipt shows points earned: 49
5     Look up Ana Rivera again                     Balance shows 1,299

Actual result / Pass or Fail / Defect ID / Tester / Date

Good scripts have specific data ("1,250 points", not "some points"), one clear expected result per step, and cover more than the happy path. For each important requirement add negative and edge cases: a customer with no loyalty account, a refund that must remove points, the API being unavailable (the sale must still complete), a name with an apostrophe or accent.

Acceptance criteria written as Given/When/Then in the Business & Systems Analysis course convert almost directly into UAT scripts; that is one reason to write them well.

Running UAT

• Start with a short kick-off: how to use the scripts, how to log defects.
• Hold a daily triage meeting to review new defects, agree severity and assign them.
• Track progress visibly: scripts passed, failed, blocked; defects open by severity.
• Re-test fixes with the original script, and run a small regressionRe-running a set of tests to check that a fix did not break anything else. set to check nothing else broke.
• End with formal sign-off by the business owner against the exit criteria.

Common mistakes

• Using IT staff as UAT testers; they test what was built, not how the work is done.
• Vague expected results ("works correctly").
• Production customer data in a test environment without anonymisation.
• Starting UAT on an unstable build, so testers lose confidence.
• No exit criteria, so UAT ends when the calendar says so.

Quick recap

• UAT confirms the business can operate on the system; it comes after system testing.
• Plan scope, entry and exit criteria, testers, schedule and the defect process.
• Scripts trace to requirements, use specific data and expected results, and include negative cases.

Try it

In the Do tab you write a UAT plan outline and three scripts.