UAT Scenarios

Why it matters

Business users usually join UAT for a limited time, next to their normal work. If the scenarios are written in tester language, with field names and click paths, users either need a tester beside them or follow the clicks without thinking about their work: the screens get checked, the process does not. If the scenarios cover only the ordinary case, the rules the business runs on, such as approval limits and price tolerances, reach production without the people who own them ever seeing them applied.

For the tester, good scenarios turn a UAT session into evidence. Each scenario traces to a process step and to the rules it shows, so the results can support an acceptance decision instead of a general impression that "it seemed fine".

Writing scenarios from business processes

Start from how the business works, not from the screens or the list of requirements. Take each business process in the UAT scope, for example procure to pay (from ordering goods to paying the supplier) or hire to retire (from hiring an employee to their departure), and walk through it with the process owner or a key user, an experienced user who represents colleagues in the same role. Write down each activity in order, the role that performs it, what triggers it, what it produces and where the work goes next, including hand-offs to other teams and systems.

Then write one end-to-end main scenario for the ordinary path: the work as it happens on a normal day, with normal data. It shows that the process holds together across roles. Next, add variant scenarios for the other situations the business must handle. The ISTQB Acceptance Testing syllabus calls this business process-based testing: acceptance tests are derived from models of the business processes and their rules, covering the paths through a process and the decisions in its rules.

• Roles: the same step done by a manager, a deputy covering an absence, or a new joiner with fewer permissions.
• Business data: a local and a foreign supplier, a new and an existing customer, a small and a large order.
• Exceptions the business handles: rejection, correction, cancellation, a return, a partial delivery.
• Calendar events: month end, year end, a public holiday, a price change that takes effect on a set date.
• Where to find all this: process maps, work instructions, user stories and acceptance criteria, the reports users rely on, and the workarounds and complaints of the current system.

Try it: Requirements → Test Scenarios Try it: User Story → Test Scenarios

Language business users can work with

A business user should be able to read a scenario and say "yes, this is my work" before running it. Write in the users’ own vocabulary and, where they work in Arabic or Hindi, in their language. Ask a key user to review the wording before the session: a scenario that confuses its reader wastes the scarcest time in UAT.

• Put the business goal in the title: "Pay a supplier invoice that matches its order", not "TC_AP_014 save invoice".
• Write intent, not clicks: "Faisal approves the invoice", not "click btnApprove in the right panel". Click paths hide the business question and break when a screen changes. If users are new to the system, give them a short how-to guide separately.
• Use the business’s terms: supplier, goods receipt, payment run, not vendor_id or "GRN record", unless the users themselves talk that way.
• Give realistic data the users recognise: a named supplier, amounts, dates, and the role and test account to use.
• State the expected business outcome the user can check: what they see, what reaches the next person in the process, which document or amount is produced.
• Keep one business goal per scenario and a handful of steps, and leave room for the user’s verdict and comments.

Covering the business rules

A main scenario shows that the process works for an ordinary case. Many acceptance problems, however, sit in the business rules attached to the steps: approval limits, tolerances, deadlines, eligibility, calculations and who may do what. The lesson on business rules showed how to cover their combinations with decision tables, work that usually belongs to system testing. UAT has a different purpose: the people who own the rules confirm that they are the right rules and that they give the right outcome in situations they recognise.

List the rules of every process step from the requirements, the policies and the process owner. Where a rule can change the outcome, add a variant scenario on the side that changes, with realistic values close to the limit. A rule with a single outcome can be shown by the main scenario. Then keep a rule-to-scenario map: every rule is shown by at least one scenario, and every scenario names the rules it shows. A rule with no scenario is either a gap to fill or a question for the process owner.

• Choose the situations users actually meet and those with the highest business impact; exhaustive combinations are usually covered in system testing.
• For a rule that blocks or diverts work, show both sides: the case it lets through and the case it stops.

Try it: Decision Table Generator Try it: Requirements → Test Cases

Worked example: paying a supplier invoice

A company is accepting a new finance system. The part of its procure to pay process covered here has four steps: the accounts payable clerk registers the supplier invoice, the system matches it with the purchase order and the goods receipt (the record that the goods arrived), the finance manager approves it, and it is paid in the weekly payment run. The process owner confirmed four rules.

UAT-01, the main scenario written out below, runs all four steps with an invoice that passes every rule. Each rule that can change the outcome adds one variant scenario on the side that changes:

• BR-1: an invoice can be registered only against an open purchase order of the same supplier. Variant UAT-02: an invoice that quotes a closed order is refused, and the clerk sees why.
• BR-2: an invoice more than 2% above its purchase order goes on hold until the buyer resolves it. Variant UAT-03: an invoice of 18,952.00 SAR against an order of 18,400.00 SAR, 3% above.
• BR-3: the finance manager approves invoices up to 50,000.00 SAR; above that, the CFO approves as well. Variant UAT-04: an invoice of 50,400.00 SAR.
• BR-4: approved invoices are paid in the next Thursday payment run. It has one outcome only, so it needs no variant: UAT-01 shows it.

UAT-01  Pay a supplier invoice that matches its purchase order
Process: procure to pay, steps 1 to 4    Rules shown: BR-1, BR-2, BR-3, BR-4
Who:     Huda, accounts payable clerk; Faisal, finance manager
Start:   Purchase order PO-5521 to Al-Noor Supplies: 40 office chairs,
         18,400.00 SAR, open; all 40 chairs received

Steps
1. Huda registers Al-Noor’s invoice INV-7730 for 18,400.00 SAR against PO-5521.
2. Huda checks the matching result shown for the invoice.
3. Faisal approves the invoice from his list of invoices waiting for approval.
4. Huda opens the next Thursday payment run.

Expected business outcome
- The invoice is matched to the order and the goods receipt, with no hold.
- Faisal’s approval is enough: the invoice is not sent to the CFO.
- The payment run pays Al-Noor Supplies 18,400.00 SAR for INV-7730.

Business user’s verdict: works as we work / works with remarks / does not work
Comments:

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• Certified Tester Acceptance Testing (CT-AcT)ISTQB · 2019ISTQB's specialist syllabus on acceptance testing: user, contractual and regulatory acceptance testing, alpha and beta testing, and how testers work with product owners and business analysts.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.