Computerized System Performance Qualification / UAT Protocol

This is a ready-to-use performance qualification protocol, run as user acceptance testing for a GxP computerized system. PQ and UAT are the same exercise here: real users running the system end to end against the user requirements, in conditions that match production. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, attach your requirements traceability matrix, and route it through your normal document control, review, and approval. A worked filled specimen follows the template so you can see how a completed version reads. Verify each cited regulation against the current source before you rely on it.

Document control header

1. Purpose

This protocol demonstrates that <<FILL: SYSTEM NAME>>, version <<FILL: version>>, performs its intended business processes correctly, reliably, and within performance expectations when operated by trained end users in a production-equivalent environment. PQ/UAT confirms that the system meets the user requirements (URS <<FILL: URS-ID>>) in real workflows, not just that individual functions work in isolation. It is the last test phase before the system is released for GxP use.

2. Scope

This protocol covers end-to-end execution of the business processes the system supports at <<FILL: site / department>>, run by the actual user roles against the URS. It includes the real-world scenarios in section 7, the performance and concurrency checks in section 8, role and access behavior, interfaces to upstream and downstream systems, and the reports and records the process must produce.

It does not repeat installation verification (covered by IQ <<FILL: IQ-ID>>) or function-by-function testing (covered by OQ <<FILL: OQ-ID>>). Where CSA-based assurance reduces scripted testing for lower-risk functions per <<FILL: CSA strategy / test plan ID>>, that rationale is recorded and unscripted or ad hoc testing is captured per section 6.4.

3. Responsibilities

4. Definitions

• Performance Qualification (PQ): documented verification that the system performs as intended in its operating environment, run as end-to-end business process testing.
• User Acceptance Testing (UAT): testing by real users to confirm the system meets the user requirements and is fit for the intended use. In this protocol PQ and UAT are executed as one phase.
• Test case: a defined scenario with preconditions, steps, expected results, and an acceptance criterion, traced to one or more URS requirements.
• Defect: any actual result that does not match the expected result, classified by severity in section 9.
• Objective evidence: the record that proves the result, for example a screenshot, a system-generated report, an exported audit trail, or a printout, with the date and who captured it.
• Production-equivalent environment: a validated or controlled test environment whose configuration, version, interfaces, and data match what will go live, so the result is meaningful.

5. Pre-execution requirements

Execution does not start until all of the following are confirmed and recorded in section 11.

6. Test approach

6.1 Risk-based test design

Depth of testing follows the risk and complexity of each function, in line with ICH Q9 and the GAMP 5 risk-based approach. High-risk, GxP-record-impacting steps (data entry that drives a decision, calculations, electronic signatures, batch or result disposition, interfaces that move GxP data) get fully scripted test cases with predefined expected results. Lower-risk, non-record functions may use unscripted or exploratory testing recorded per section 6.4. Record the risk basis for each requirement in the RTM.

6.2 End-to-end orientation

Test cases follow whole business processes from trigger to final record, not single screens. A scenario starts where a real user starts (a sample arrives, a batch is initiated, an order is received) and ends with the record the process must produce (an approved result, a released batch record, a posted transaction).

6.3 Scripted test cases

Scripted cases use the structure in section 7.2. Each step has a documented expected result and a place to record the actual result, pass/fail, objective evidence reference, and the tester initials and date.

6.4 Unscripted and ad hoc testing

Where CSA-style assurance or exploratory testing is used, record: who tested, what was tested, when, the scenarios attempted, the outcome, and any defects. Unscripted testing is evidence too; it is documented contemporaneously, not reconstructed later.

7. Test cases

7.1 Real-world scenarios to cover

At minimum, cover these scenario types, mapped to the URS. Add the scenarios specific to your process.

7.2 Scripted test case template

Repeat this block for every scripted test case.

Write expected results so a second person, with no other instruction, could judge pass or fail. “System accepts the value” is not testable; “result field shows 12.5 mg/mL, rounded to one decimal per the method, and saves without error” is.

8. Performance, load, and concurrency

Functional correctness is not enough; the system has to hold up under real use. Define and test the performance criteria that matter to the process.

State the load conditions you tested under. A response time measured on an empty database with one user is not evidence the production system will perform.

9. Defect management

Every actual-versus-expected mismatch is recorded as a defect, classified, dispositioned, and (for fixes) retested before closure.

Defect log fields: defect ID, test case ID, description, severity, root cause, fix/change reference, retest result, status, QA disposition. A fix that changes configuration or code re-triggers the change assessment in section 10 and regression of affected cases.

10. Change during execution

If the configuration, version, or environment changes during execution, stop, record it as a deviation per <<FILL: deviation SOP-ID>>, assess impact, and re-run the affected test cases on the new build. Do not splice results from two different builds into one passing record.

11. Acceptance criteria

The PQ/UAT is acceptable, and the system can be recommended for GxP release, only when all of the following are true.

• Every URS requirement is verified by a passing PQ test case, or by traced OQ/CSA evidence with a recorded rationale (full traceability, no gaps).
• All scripted test cases are executed; every step has an actual result, a pass/fail, and objective evidence where the result is not self-evident.
• No critical defects are open. Any open major or minor defect has a QA-approved disposition and a tracked corrective action.
• Performance and concurrency criteria in section 8 are met under stated production-like load.
• Each business process owner has accepted the result for their process.
• Deviations are documented and resolved, and no test result was reconstructed or back-dated.
• All testers were trained and the configuration baseline held for the test period.

12. Deviations and handling

Any test failure, unexpected behavior, or departure from this protocol is recorded as a deviation per <<FILL: deviation SOP-ID>>, assessed for impact, and resolved before the summary report is approved. A failed step is investigated, not edited to pass. Where the expected result, not the system, was wrong, correct the test case under change control and re-execute; record why.

13. Summary report

On completion, the validation lead issues report <<FILL: report number>> summarizing scenarios and test cases executed, pass/fail counts, the full defect log and dispositions, performance results against targets, all deviations and their resolution, the traceability conclusion (every URS requirement met), and the recommendation on release for GxP use. QA approves the report; release follows the system release procedure <<FILL: SOP-ID>>.

14. Attachments

15. References

21 CFR Part 11 (electronic records and electronic signatures). 21 CFR 211.68 (automatic, mechanical, and electronic equipment). EU GMP Annex 11 (Computerised Systems), including section 4 (validation) and section 5 (data/accuracy checks). EU GMP Annex 15 (Qualification and Validation), 2015 revision, for the PQ stage. GAMP 5 (A Risk-Based Approach to Compliant GxP Computerized Systems), Second Edition. FDA Computer Software Assurance for Production and Quality Management System Software, final guidance issued 3 February 2026 (superseding the 24 September 2025 version). FDA General Principles of Software Validation (for the validation lifecycle). ICH Q9 (Quality Risk Management), for risk-based test depth. PIC/S PI 011, Good Practices for Computerised Systems in Regulated GxP Environments.

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

16. Revision history

17. Approvals

Filled specimen

The following shows one scripted test case and the acceptance summary completed for an example laboratory information management system (LIMS) PQ, so you can see the level of detail an inspector expects. The company, system, and numbers are illustrative; replace them with your own.

Test case (executed)

Acceptance summary (executed)

In this example the testers ran whole workflows as the real roles, proved that the analyst could not approve their own result (segregation of duties), checked the calculation and rounding against the method, confirmed the e-signature carried meaning and bound to the record, read the audit trail to confirm it captured who/what/when/old-new, and measured performance under realistic concurrent load. The one critical defect was fixed and the case re-executed, not waved through. That sequence is exactly what a reviewer is expected to demonstrate.

Common inspection findings this protocol prevents

• Test cases written as single-screen checks with no end-to-end business process, so the system “passed” without anyone proving the real workflow works.
• Expected results so vague (“works as expected”) that pass/fail is the tester’s opinion, not a verifiable judgment.
• A URS requirement with no traced test case, or test cases with no traced requirement, leaving coverage unproven.
• Test data that mimics live records but is not labeled as test data, contaminating production.
• Segregation of duties never tested; the same role can create and approve a GxP record.
• A failed step quietly edited to pass, with no deviation and no investigation.
• Critical or major defects open at go-live with no QA disposition or interim control.
• Performance “tested” with one user on an empty database, then deployed to many users at production data volume.
• Configuration or version changed mid-execution and results from two builds combined into one passing record.
• Objective evidence missing, so the executed record cannot be reconstructed or relied on later.

How to adapt this protocol

1. Set your document number, owner, summary report number, and effective date in the header, and name your real system, version, and GAMP category.
2. Replace the scenario list in section 7.1 with the actual business processes your system supports, and write one or more scripted test cases per high-risk requirement using the section 7.2 block.
3. Point the cross-references in sections 2, 5, 10, 12, and 13 to your real URS, IQ, OQ, CSA strategy, deviation, and system release procedures.
4. Set real performance and concurrency targets in section 8 from the production load you expect, and state the conditions you will test under.
5. Build or attach the requirements traceability matrix so every URS requirement maps to PQ test cases or to traced OQ/CSA evidence with a rationale.
6. Where you apply CSA to reduce scripted testing on lower-risk functions, record the risk basis and capture unscripted testing per section 6.4.
7. Confirm every regulation in section 15 against the current published version before issue.