Your UAT Plan Is Just a List of Things to Click Through

Every script in the UAT plan passed. Log in. Navigate to the claim screen. Click New Claim. Enter data. Click submit. Confirm the confirmation page appears. Tick the box. Sign off.

Two weeks after go-live, a claim comes in just above the auto-approval threshold. It should route to manual review. It doesn’t. Nobody scripted that. Nobody scripted the opposite case either, or the one where required documentation is missing, or the one where two business rules collide and someone has to decide which one wins.

The UAT plan didn’t fail. It never tested any of that. It tested that the screens respond when you click things in order.

Project clinic summary

Symptom:
Every UAT script passes, but the plan only tests that screens respond, not that the business logic behind them is correct.

Likely causes:
Scripts written from a screen walkthrough instead of business scenarios or acceptance criteria. Thin or missing acceptance criteria at story level. UAT plan built for screen coverage, not scenario coverage. Scripts assembled fast under go-live pressure with no one owning the link between business rule and expected result.

BA move:
Rewrite scripts scenario-first, naming the business condition and expected outcome before attaching the click path.

Why this hurts the project

UAT is the last checkpoint before go-live. That makes a false pass here the most expensive kind of false pass on the project. Everyone downstream reads “UAT complete, all scripts passed” as a business guarantee. It isn’t one. It’s a navigation guarantee.

So the project ships. The defect that should have been caught in a test environment shows up in production instead, in front of a real customer, with no rollback and no test data to shrug at. The team that signed off feels blindsided. The business owner who trusted the sign-off feels misled. Nobody did anything dishonest. The plan just never asked the question that mattered.

There’s a second cost. Once a project has been burned this way, people stop trusting UAT sign-off. The next release gets extra scrutiny and extra “are you sure” conversations, because the checkpoint meant to remove doubt just added it instead.

What this usually looks like in practice

Open any script in a plan like this and it reads like a tour guide. Step one, step two, step three, arrive at the confirmation page. The expected result column says things like “page loads” or “success message displayed.” It rarely says what the business was supposed to achieve.

Coverage looks thorough because every screen and every button has a line. What’s missing is scenario variation. One script per feature, always the happy path, always the same input values. No script asks what happens at the threshold, when a mandatory field is blank, or when two rules point in different directions.

Testers execute exactly what’s written. If the script says click Submit and confirm the page loads, that’s what gets tested, and that’s all that gets tested.

Likely causes

Scripts were written by narrating the screen, not by tracing a business scenario through to an outcome. Someone sat with the workflow and wrote down what they saw happen, step by step. That produces a script. It doesn’t produce a test.

Acceptance criteria upstream were thin. If a story’s acceptance criteria said “the user can submit the request” and nothing more, there was nothing solid to build a real UAT scenario from. The script inherited the vagueness. See requirements are too vague for how this starts even earlier.

The UAT plan was built for screen coverage, not scenario coverage. Someone counted screens and made sure each had a line item. Nobody counted business rules.

Scripts got assembled fast, close to go-live, by copying the navigation path from a walkthrough or a training deck. Under that pressure, “does this look complete” quietly replaces “does this actually test something.”

No one owns the join between business rule and expected result. It sits in the gap between the BA who knows the rule and the test lead who writes the script, and if nobody owns that handoff, it doesn’t happen.

Diagnostic questions

1. If I pick any script and ask “what business outcome does passing this confirm?”, can I answer in one sentence?
2. Does the expected result name a business outcome, or just a UI event like “page loads” or “confirmation shown”?
3. Where did this script actually come from, a screen walkthrough or the acceptance criteria and business rules?
4. Does this scenario have more than one data variation scripted, including edge cases and threshold values?
5. Could someone who has never seen the requirements run this script and still tell you if the business outcome was wrong?
6. Are there scripts for what should not happen, or only for the happy path?
7. Who reviewed this plan for business rule coverage, as opposed to screen coverage?
8. If this script passes, does that confirm the calculation, routing, or decision was correct, or only that no error appeared?
9. Can this script be traced back to a specific acceptance criterion or business rule?
10. Has a business user named the scenario that actually worries them, and is it in the plan?
11. When did anyone last write a script specifically to try to break something, rather than confirm it works?
12. If this script fails, will the tester know which business rule broke, or just that a step didn’t match?

The IT Project Problem Diagnostic Checklist includes a UAT Readiness section. Use it to check whether your acceptance scenarios, test data, and business user preparation actually connect to your acceptance criteria before UAT begins.

Practical BA moves

Rebuild scripts scenario-first. Write the business scenario and expected outcome before touching the click path. Attach the navigation steps last, as the how, not the what.

Trace every script to a source. Match each one to an acceptance criterion or business rule. Anything with no source line gets flagged and rewritten before UAT starts, not during it.

Replace UI-event expected results with business-outcome expected results. “Confirmation screen appears” becomes “claim routes to manual review because the amount exceeds the auto-approval threshold.” That single change forces the script to test something real.

Script at least one negative or edge case per major business rule. Invalid input, a boundary value, an exception path. If a rule has a boundary, someone needs to stand on it during UAT, not just walk past it.

Run a fifteen-minute scenario audit with the test lead before execution starts. Pull five scripts at random and ask what business question each one answers. If the answer is “it confirms the screen works,” rewrite it.

Ask business users which scenario worries them most. Not which feature, which situation. Then check it has a script. If it doesn’t, that’s the gap UAT was supposed to catch.

What a rewritten script actually looks like

The click path barely changes. What changes is what the script is checking.

Same feature. Same number of steps. One of these tells you the screen works. The other tells you the business rule works.

Common mistakes

Treating a passed script as proof the business logic was correct. A pass only proves what the script checked, and most of these scripts check very little.

Scripting only the happy path, then calling that full coverage because every feature has a line item.

Letting scripts get written by copying a workflow document instead of the acceptance criteria and business rules. See acceptance criteria that actually work for what a script should trace back to.

Assuming business users will “test properly” during execution even when the script never asks them to check anything beyond whether the screen behaved.

Skipping a scenario because “we already covered that in SIT,” without checking whether SIT tested the business rule or just the same happy path, one environment earlier.

FAQ

Isn’t UAT supposed to be simple, so business users can run it without training?
Simple wording is fine. Simple thinking is not. A scenario-based script can still be written in plain language. “Submit a claim above the threshold, confirm it goes to manual review” is not harder to read than “click Submit, confirm the page loads.” It’s just testing something.

Who should write UAT scripts, the BA or QA?
Shared ownership works better than either alone. The BA supplies the scenario and the rule. QA turns it into an executable script. Written alone, either side’s scripts drift toward whichever expertise is missing.

How many scripts is enough?
Enough to cover the scenarios and rules that matter, not a target number. Ten scripts that each test a real business condition beat forty that test the same happy path with different screen names.

Is this the same problem as UAT finding requirement gaps too late?
Related, not the same. Your UAT keeps finding basic requirement gaps too late is about timing. This is about the scripts themselves. A UAT plan built this way wouldn’t catch the gap even on day one, because it was never built to test a business outcome in the first place.

What to do next

Pick three scripts from the current UAT plan. Run the one-sentence test on each: what business outcome does passing this confirm? If the honest answer is “it confirms the screen loaded,” that script needs a rewrite before it needs a tester.

The thinner the acceptance criteria upstream, the more likely this is happening across the whole plan, not just three scripts. Definition of ready and definition of done is worth a look if scripts keep coming back this way story after story.

The IT Project Problem Diagnostic Checklist can help you check whether scope drift, weak decisions, and requirement gaps are already building up elsewhere on your project.