UAT Test Plan by Business Workflow

UAT comes last, after the vendor or your IT team has finished system testing. ISTQB, the international board behind the Certified Tester qualification, says acceptance testing focuses on demonstrating readiness for deployment and should ideally be performed by the intended users¹. Your testers are the clerks, accountants and warehouse leads who will do the work.

List the workflows the business runs, end to end, in the words of the people who run them: quote, order, ship, invoice, return, credit. Note which configuration items each one touches. A tax setting or an invoice layout isn't a test case on its own; it's a step inside one.

Write down the variations that change the outcome, because each one becomes a case: a backorder shipped in two parts, a tax-exempt customer, an order over its credit limit. In Microsoft's guide to implementing Dynamics 365, its business software, UAT testers test all the processes and variations that are in scope for their roles and tasks².

If a workflow lives only in one person's head, record them walking through it and turn the transcript into a step-by-step SOP first.

You can't test everything equally deeply, so decide where the depth goes first. ISTQB measures a risk by two factors, its likelihood and its impact¹, and uses that analysis to focus test effort so it leaves the least risk behind.

Monthly volume stands in for likelihood: a defect on a path that runs 5,000 times a month will be hit in the first week. Dollars at stake and compliance exposure (tax, credit, regulatory or contract terms) stand in for impact. Give depth to whatever scores high on any of the three, however few screens it touches.

A good case reads like the work itself: who does it, the record they use, the steps, and a result anyone can check. "Invoice prints correctly" can't fail. "Invoice shows no sales tax and prints the exemption certificate number" can. If your requirements were written as user stories, their acceptance criteria give you ready-made expected results.

Add negative cases for the high scorers, checking that the system refuses what it should: an override by someone without approval rights, an order past its credit limit.

Where two conditions can meet, test them together. NIST research found that most software bugs and failures are caused by one or two parameters³, with progressively fewer caused by three or more. So test each condition alone, then each pair that can really occur in the same transaction, starting with the high scorers.

Run at least one round on records moved from the old system, not just demo data. Microsoft's guide says UAT requires customer data, including migrated data², and calls it the closest test to running live operations. Migrated records carry the old system's quirks: blank fields, retired codes and customers set up a decade ago.

Load that data the way go-live will load it, following your technical migration plan, so UAT tests the move too.

Before testing begins, agree on what must be true to start and to finish. ISTQB defines entry criteria as the preconditions for an activity and exit criteria as what must be achieved to declare it completed¹. Make each one checkable: "no open critical defects" works, while "testing substantially complete" doesn't.

Don't quietly loosen the criteria when the schedule slips. The UK's Financial Conduct Authority fined TSB £29.75 million in 2022 over failings in its 2018 IT migration. Among them, its final notice found that late testing phases ran in parallel or changed in scope, and testing only concluded the day before the decision to migrate was taken⁵.

When time does run out, ISTQB says ending testing can be acceptable if the stakeholders have reviewed and accepted the risk to go live without further testing¹. Get that acceptance in writing, from the people who own the risk.

One named person signs off each workflow: whoever answers for it if it breaks, such as the controller for sales tax. Microsoft's guide notes that signing off doesn't mean that your solution is perfect or bug-free⁶, only that it is good enough to run the business safely. Log every case as pass, fail or blocked, and retest each fix before anyone signs.

After go-live, a post-implementation review checks whether the system delivered what was promised. For a faster start, the tool at the top of this page turns your workflow notes and the vendor's checklist into a scored plan and tracker.