SAP UAT Checklist: Entry, Execution, and Exit

Decision context

UAT fails for procedural reasons far more often than for functional ones. It starts before the environment is ready, business users are asked to test with data they do not recognise, defects and change requests share a queue, and the exit criteria are written after the results are known.

The distinction that matters is that UAT is not another round of system testing. It is the business confirming that the process they own works with their data. If testers are executing scripts written by the implementation team against synthetic data, that is system testing with different people in the chairs.

Adranum's role here is scope and traceability: which processes the change actually touches, which scripts intersect that set, what has no coverage, and what each result was recorded against.

Entry criteria before UAT starts

Every one of these is a yes or no. Starting UAT with any of them unresolved is the most reliable way to lose a week and the business users' goodwill at the same time.

• System integration testing complete, with the open defect list reviewed and no critical defects on the processes in UAT scope.
• The UAT environment is built from the same package that will go to production, not from a later development build.
• Test data is realistic and recognisable to the business: their customers, their materials, their organisational units, their volumes for anything that involves a list or a report.
• Authorizations reflect the real roles. Testing with wide authorizations proves nothing about whether the business can do the work on Monday.
• Scripts are written or reviewed by the process owners, in business language, with the expected result stated before execution.
• Interfaces in scope are connected to something, and the substitute is documented where a partner cannot participate.
• Testers are trained, named, and have time allocated. A tester who is doing UAT between their day job tasks will pass everything.
• Defect severity definitions and the triage owner are agreed before the first defect is raised.

What a usable UAT script contains

Scripts fail when they describe navigation instead of business outcomes. A tester who is following clicks cannot tell you whether the result is right.

• The business process and the process owner, so a failure has an owner immediately.
• Preconditions: the master data, the open documents, and the system state the step assumes.
• The business action in business language rather than a click path, because the click path changes and the business intent does not.
• The expected business result, written before execution: the document that should exist, the value it should carry, the status it should reach.
• The actual result and the evidence, which for anything financial means the number and not a tick.
• Pass, fail, or blocked, with blocked as a first-class outcome rather than a fail.
• The tester and the date, because a result nobody can attribute cannot be questioned or defended.

Running it: the three rules that decide the outcome

Most of the value in running UAT well comes from three decisions that are easy to state and easy to abandon under pressure.

• Separate defects from change requests on the day they arrive. A change request in the defect queue makes the defect trend meaningless, and the trend is what the exit decision uses.
• One triage owner sets severity. Severity assigned by the person who raised the ticket produces a queue sorted by frustration.
• Retest failures against a real fix in the UAT environment, not against a developer's confirmation. A defect closed on assurance reopens in production.

Exit criteria to agree before execution

Write these into the test plan. Exit criteria agreed after the results are in describe the results.

• Every in-scope script executed, with blocked scripts explicitly accounted for rather than counted as not run.
• No open critical or high defects on processes required at go-live.
• Every remaining defect has a severity, a workaround, an owner, and a target date.
• Each business process owner signs for their own process, not one signature for the whole scope.
• Coverage gaps are named. A process that was in scope and never tested is a stated risk, not an omission.
• Results are recorded against the exact package that will be transported to production.

What the workflow must cover

• Scope from impact. Select the processes and scripts whose components, data, and interfaces intersect the change rather than re-running the full catalogue by default.
• Named coverage gaps. Report impacted paths with no script at all, so an untested area is a decision rather than an assumption.
• Package-bound results. Bind every result to the package it ran against, so a later build does not inherit the acceptance.
• Owner-level sign-off. Record acceptance per business process owner rather than as a single aggregate approval.

Implementation workflow

Start with a bounded customer scenario and explicit acceptance criteria. Preserve native SAP permissions and accountable review while the software creates a repeatable evidence chain.

1. Agree entry criteria, severity definitions, and exit criteria before scheduling.
2. Select scripts from the impacted processes and name the coverage gaps.
3. Prepare recognisable data and real role authorizations in the UAT environment.
4. Execute with one triage owner and separate change requests from defects.
5. Exit against the written criteria with sign-off per process owner.

Evidence to require

A transformation claim should resolve to observable artifacts, decisions, and execution receipts. Ask for the following evidence in a representative evaluation:

• Entry criteria confirmation
• Script list and coverage gaps
• Test data provenance
• Role and authorization set used
• Execution results with evidence
• Defect list with severity and owner
• Retest results
• Per-process sign-off

Boundaries and non-claims

Adranum separates analysis, proposal, human review, package creation, customer-local validation, and production execution. A later state never rewrites the evidence that supported an earlier decision.

• Acceptance is a business judgement. No tool decides whether a process is acceptable.
• Scripts written entirely by the implementation team test the implementation's understanding of the process rather than the process.
• UAT cannot recover scope that system integration testing never covered. It only reveals it later and more expensively.

Buyer checklist

• Is the UAT build the same package that goes to production?
• Do testers recognise the data as their own?
• Are the authorizations the real roles?
• Are change requests in the defect queue?
• Does each process owner sign for their own process?