Test Script: Requirements-Based / UAT (PQ)

This is a ready-to-use requirements-based test script for user acceptance testing, executed as the performance qualification (PQ) of a GxP computerized system. One script runs one whole business scenario, end to end, the way a real user runs it in production, and proves that one user requirement (or a tight group of related requirements) is met in real use. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, run it under an approved PQ/UAT protocol, and route the executed record through your normal review and approval. A worked filled specimen follows the template so you can see how a completed version reads. A UAT script is contemporaneous GxP evidence: write each actual result as you observe it, in ink or in the validated tool, never reconstructed later. Verify each cited regulation against the current source before you rely on it.

What this script is, and how it differs from an OQ script

A requirements-based UAT/PQ script is not a function-by-function check. It follows a complete business process from the trigger a user actually starts with (a sample arrives, a batch is initiated, a complaint is logged) through to the record the process must produce (an approved result, a released batch record, a closed complaint), run by the role that will run it in production, with the real-world data they will use. The protocol or validation plan says which scenarios you will run and why; this script says exactly how, captures what actually happened step by step, and ties back to the specific URS requirement it verifies. OQ asks “does the feature work as built?” PQ/UAT asks “does the system do the user’s job correctly in production conditions?” Keep the two phases distinct; a UAT script that just re-runs OQ steps proves nothing new.

Under a Computer Software Assurance approach the rigor of the script scales with risk. A high-risk scenario that drives a release decision, a calculation, or an electronic signature earns a fully scripted, step-by-step record like the template below; a low-risk, non-record scenario may justify a lighter, unscripted record. Decide that risk before you write the script.

Document control header

1. Requirement traced

State exactly which user requirement this scenario verifies, so the traceability matrix can link the requirement to its evidence in both directions. The scenario must exercise every requirement listed here, and every step below must trace to a requirement.

2. Business scenario and objective

In two or three sentences, state the real-world scenario this script runs and what passing it demonstrates in business terms, not feature terms. Name the trigger, the roles involved, and the final record produced.

<<FILL: scenario and objective, e.g. A sample arrives in the lab; a QC analyst logs it, enters two replicate readings, the system calculates the reportable result per method ASSAY-01, a QC reviewer checks the data and electronically approves it, and the approved result is released. Passing this script demonstrates that the end-to-end result lifecycle meets URS-022 with correct calculation, enforced segregation of duties, a bound electronic signature, and a complete audit trail.>>

3. Prerequisites

List everything that must be true before execution starts. If any prerequisite is not met, do not execute; record the gap as a deviation per section 9 and stop. UAT specifically depends on a production-equivalent build and the real user roles, so verify those, not just that the software is installed.

4. Roles, accounts, and test data used

A requirements-based UAT script is run by real user roles, sometimes more than one in the same scenario. Record exactly who ran which part, with which account, against which data.

5. Execution conventions

Read these before executing, then follow them for every step. They are the rules an inspector expects to see applied consistently.

• Record each actual result contemporaneously, as you observe it, in the actual result cell. Do not pre-fill, do not batch at the end.
• “Meets expected result” is not an actual result. Write what you actually saw: the value, the calculated number, the message text, the screen state, the timestamp, the signature meaning.
• Use one unambiguous mark for pass or fail. A blank cell is incomplete, not a pass.
• For any single-line correction, strike through once, initial, date, and add a brief reason. Never obliterate the original entry.
• Capture objective evidence (screenshot, system report, audit trail export, signed-record printout) for every step whose pass depends on a system output, and give that evidence a unique reference recorded in the step.
• When the scenario hands off between roles, the second tester logs in with their own account and records their own initials; do not let one person execute steps assigned to two roles.
• The moment any step does not meet its expected result, mark it Fail, stop if instructed, and raise a defect per section 9. Do not retest a failed step in place without a documented disposition.

6. Test steps

Run the whole scenario in sequence. For each step give the action, the precise expected result, the actual result as observed, pass or fail, and the evidence reference. The expected result must be written before execution and must be specific enough that two people would agree on whether it was met. The steps below illustrate a result-lifecycle scenario; replace them with your own scenario, keeping the end-to-end flow, the role handoff, the calculation, the signature, and the audit-trail check where they apply.

Add or remove rows so the scenario runs from real trigger to final record and every requirement in section 1 is exercised. Number steps continuously; do not reuse a number after a revision.

7. Acceptance criteria

This script passes only when all of the following are true:

• Every step needed to verify the requirements in section 1 is marked Pass, with a recorded actual result and, where applicable, an evidence reference.
• The scenario ran end to end through the real role handoff, not as disconnected single-screen checks.
• The calculated or reportable value matched the method exactly, including units and rounding.
• Segregation of duties held: the user who created the record could not also be its sole approver.
• The electronic signature bound to the record with name, date/time, and meaning, and the audit trail captured who/what/when/old-new.
• No step is left blank or ambiguous; every defect raised during execution is resolved with a documented disposition, and any retest is recorded under its own step or attachment.
• The completed script is reviewed and approved per section 11.

A script with one or more open Fail steps, or unresolved critical defects, does not pass and cannot support release in the parent report.

8. Evidence index

List every piece of objective evidence captured, so a reviewer can find each one without hunting.

9. Defects raised during execution

Any step that does not meet its expected result, any departure from the written steps, and any prerequisite not met is recorded here and managed per the parent protocol and <<FILL: deviation / test-incident SOP-ID>>. Cross-reference the defect number on the failing step. Classify by impact on the GxP record or release decision.

A failed step is not a finding against the tester. It is data. The discipline an inspector looks for is that the failure was captured honestly, classified, dispositioned, and that any retest traces to the original failure, not quietly overwritten. A critical defect (wrong result, signature or audit trail failure, segregation-of-duties gap) must be fixed and the affected steps re-executed and passed before release; if the fix changes configuration or code, re-trigger the change assessment and regression of affected steps.

10. Execution summary

11. Sign-off

The tester(s) who executed the scenario sign; the business process owner accepts the result for their process; an independent reviewer who did not execute the test confirms the record is complete, the evidence supports each pass, and defects are resolved. The reviewer should not be a person who executed the script.

12. References

21 CFR Part 11 (electronic records and electronic signatures), where the system is Part 11 in scope. 21 CFR 211.68 (automatic, mechanical, and electronic equipment). EU GMP Annex 11 (Computerised Systems), section 4 (validation) and section 14 (electronic signatures). EU GMP Annex 15 (Qualification and Validation), 2015 revision, for the PQ stage. GAMP 5, Second Edition (a risk-based approach to compliant GxP computerized systems). FDA Computer Software Assurance for Production and Quality Management System Software, final guidance issued 3 February 2026 (superseding the 24 September 2025 version) (risk-based scaling of test rigor). ICH Q9 (Quality Risk Management), for the risk basis of test depth. For medical device software: 21 CFR Part 820 (QMSR, effective 2 February 2026, incorporating ISO 13485:2016) and IEC 62304.

Confirm the current version and clause numbers of each reference before issue.

13. Revision history

Filled specimen

The following shows the script executed for an example laboratory information management system (LIMS) PQ, running the end-to-end result lifecycle as a real analyst and a real reviewer, traced to one URS requirement. The company, system, accounts, and numbers are illustrative; replace them with your own.

Header (extract)

Requirement traced

Scenario and objective (extract): A sample arrives, analyst1 logs it and enters two absorbance readings, the system calculates the reportable result, reviewer1 checks and electronically approves it, and the approved result is released. Passing demonstrates correct calculation, enforced segregation of duties, a bound electronic signature, and a complete audit trail in real use.

Test steps (executed)

Execution summary

Defect (extract): DEF-2026-031 (Minor), step 6.7. The approval printout showed local time without a time zone label, though the on-screen entry and audit trail both showed “EDT”. No GxP-record or decision impact. Deferred with QA disposition; corrective action LIMS-CR-2026-067 to add the time zone label to the printout, tracked to closure.

Sign-off

In this example two real roles ran the whole workflow, the analyst could not approve their own result, the calculated value and rounding matched the method exactly, the electronic signature carried meaning and bound to the record, and the audit trail captured who/what/when/old-new and resisted edit. The one defect found was a printout label issue with no record impact, so it was classified minor, dispositioned by QA, and tracked to closure rather than waved away. Had step 6.4 instead let the analyst approve their own result, the tester would have marked it Fail, raised a critical defect, and held release, which is the behavior section 9 is built to capture.

Common inspection findings this script prevents

• A UAT/PQ script that only re-runs single-screen OQ checks, so no one ever proved the real end-to-end business process works.
• Steps marked Pass with the actual-result column filled in only as “meets expected result”, giving no evidence of what was actually observed.
• Expected results written or amended after execution, so the test cannot fail.
• A URS requirement with no executed scenario that exercises it, or a step that tests something the requirement never asked for, leaving traceability with gaps in one or both directions.
• Segregation of duties never tested in UAT, so the same user can create and approve a GxP record.
• A calculation accepted without checking units and rounding against the defined method.
• An electronic signature that does not bind to the record or does not capture its meaning.
• One person executing steps assigned to two different roles, defeating the point of the role handoff.
• A failed step quietly retested and overwritten, with no defect record, no disposition, and no link between the failure and the eventual pass.
• The same person executing and reviewing the script, with no independent check that the evidence supports the conclusion.
• Testing run in production, or against a different build than the one being released, with no record of the actual version tested.
• Objective evidence referenced but not retained, so the executed scenario cannot be reconstructed later.

How to adapt this script

1. Set your test script ID, parent PQ/UAT protocol, system version, and effective date in the header, and confirm you are testing a production-equivalent, release-candidate build in a non-production environment.
2. Replace the illustrative result-lifecycle scenario in section 6 with your own end-to-end business process, keeping the real trigger, the role handoff, any calculation, any electronic signature, and the audit-trail check where they apply.
3. List the real URS requirement IDs in section 1 and confirm the scenario exercises each one; keep the script and your traceability matrix in agreement in both directions.
4. Write every expected result before execution, specific enough that two people would agree on the outcome, especially for calculated values, signature meaning, and access behavior.
5. Run each role’s steps under that role’s own account and initials; do not collapse two roles into one tester.
6. Point the cross-references in sections 3, 9, and 11 to your real IQ/OQ, deviation or test-incident procedure, and review and approval process.
7. Decide the scenario’s risk first; reserve this full scripted level for higher-risk processes and record a lighter, contemporaneous record where CSA justifies less scripting.
8. Confirm every regulation in section 12 against the current published version before issue.