Computerized System End-to-End and User Acceptance Testing

End-to-end and user acceptance testing confirms that the complete configured computerized system supports its approved intended use within the actual business process.

This testing evaluates more than individual application functions. It brings together representative users, approved procedures, realistic data, connected systems, reports, decisions, exception handling, and operational conditions to demonstrate that the complete process works as intended.

The activity may be called Performance Qualification (PQ), User Acceptance Testing (UAT), end-to-end testing, process verification, or operational acceptance testing. The selected name is less important than the test objective and evidence.

PQ Is Not Mandatory for Every System

A separate PQ protocol is not required for every computerized system.

The validation strategy should determine whether additional end-to-end or user-acceptance evidence is needed after installation, configuration, functional, interface, security, migration, and recovery testing.

A separate PQ or UAT activity is generally appropriate when:

• several user roles participate in one regulated process;
• activities pass between departments;
• connected systems form a complete data flow;
• procedural and technical controls must work together;
• realistic operating data may reveal conditions not addressed during functional testing;
• user decisions depend on reports, calculations, or system status;
• exceptional workflows require coordination;
• intended use depends on operational volume or concurrency;
• or actual users must formally confirm process suitability.

A separate protocol may provide little additional value when:

• the intended use is narrow and simple;
• one function or calculation has already been fully verified;
• no meaningful end-to-end workflow exists;
• the same representative users, data, procedures, and operating conditions were already included in approved functional testing;
• and the existing evidence clearly confirms intended use and operational readiness.

The decision should be documented in Computerized System Validation Planning and Strategy. Omitting a document titled “PQ” is acceptable only when the required intended-use evidence is provided elsewhere.

PQ, UAT, and End-to-End Testing

These terms frequently overlap but may emphasize different objectives.

Performance Qualification generally demonstrates that the configured system performs effectively within its intended operational process and environment.

User Acceptance Testing generally confirms that representative users can perform required activities and that the system supports approved business needs.

End-to-end testing generally follows a complete process and its data across user roles, application functions, interfaces, reports, and decisions.

An organization may combine these objectives within one protocol. Separate documents are not necessary when the combined approach provides clear scope, acceptance criteria, traceability, and approval.

Relationship to Functional Testing

Computerized System Functional and Control Testing demonstrates that configured functions and controls operate according to approved requirements and specifications. It commonly includes focused challenges of workflows, calculations, security, audit trails, electronic signatures, reports, interfaces, invalid inputs, and failure conditions.

End-to-end and user acceptance testing builds upon that evidence. It demonstrates that the verified functions operate together within the complete business process.

For example, functional testing may separately verify:

• deviation initiation;
• workflow routing;
• electronic signatures;
• due-date calculations;
• audit trails;
• email notifications;
• and reports.

End-to-end testing follows a representative deviation from initiation through investigation, review, approval, corrective action, closure, reporting, and record retrieval using the applicable user roles and procedures.

The end-to-end test should not repeat every detailed functional challenge. It should focus on process integration, user interaction, operational suitability, and remaining evidence gaps.

Test Basis and Preconditions

The test basis should include:

• approved intended use;
• business-process description;
• User Requirements Specification;
• approved system configuration;
• completed installation and functional verification;
• system risk assessment;
• interface and migration evidence;
• approved procedures;
• defined user roles;
• representative data;
• and known defects or limitations.

Before execution, the organization should confirm that:

• the tested version and configuration are identified;
• the environment is suitable;
• required connected systems are available;
• representative user accounts are approved;
• procedures are effective;
• training is complete or sufficiently advanced;
• realistic test data are available;
• unresolved defects have been assessed;
• and acceptance criteria are defined.

Testing against an incomplete or changing configuration may provide unreliable acceptance evidence.

Representative Business Processes

End-to-end testing should represent the regulated processes for which the organization relies on the system. Examples include:

• receiving and sampling a material;
• performing laboratory analysis and approving results;
• creating and approving a manufacturing instruction;
• executing and reviewing a batch record;
• processing a deviation and corrective action;
• changing a specification;
• approving a supplier;
• assigning and completing training;
• releasing or rejecting material;
• generating and approving a label;
• or retrieving a retained electronic record.

Each scenario should have a clear starting condition, defined activities, expected outcome, and acceptance criteria.

The test should cover the complete process rather than stopping when one application completes its portion.

Actual User Roles

Representative users should execute activities consistent with their assigned operational responsibilities. Applicable roles may include:

• operator;
• analyst;
• reviewer;
• supervisor;
• Quality approver;
• system administrator;
• business administrator;
• warehouse user;
• process owner;
• or support personnel.

Using actual roles helps confirm:

• role handoffs;
• segregation of duties;
• access to required information;
• restrictions on prohibited actions;
• approval responsibilities;
• procedure clarity;
• and usability within the business process.

A system administrator should not perform all test steps when routine users have different permissions, screens, responsibilities, and process knowledge.

The test may use designated trained representatives rather than every future user. The selected users should adequately represent the applicable roles and operating groups.

Realistic Test Data

Test data should resemble the structure, complexity, and variation expected during routine use without introducing uncontrolled production records or confidential information. Representative data may include:

• materials and products;
• batches and lots;
• samples;
• specifications;
• methods;
• limits;
• units;
• suppliers;
• equipment;
• users;
• locations;
• dates;
• attachments;
• and master-data relationships.

Test data should include enough variation to exercise:

• applicable routing;
• calculations;
• decisions;
• reports;
• interfaces;
• and exception handling.

Highly simplified data may allow a workflow to pass while failing to represent the actual process.

Where copied production data are used, the organization should control confidentiality, record status, traceability, and removal from the test environment.

Approved Procedures

End-to-end testing should use approved or release-ready operating procedures. Procedures may address:

• routine operation;
• record review;
• approval;
• data correction;
• audit-trail review;
• interface monitoring;
• incident response;
• downtime;
• backup and recovery;
• and administrative support.

Testing with procedures helps determine whether the combined system and procedural controls are workable.

The test should identify:

• unclear instructions;
• missing responsibilities;
• steps inconsistent with configured behavior;
• impractical manual controls;
• and required procedure revisions.

A successful system transaction does not demonstrate operational readiness when the supporting procedure is incomplete or incorrect.

Connected Systems and Data Flows

Many regulated processes depend on several computerized systems. An end-to-end data flow may include:

1. creation of data in a source system;
2. transfer through middleware;
3. receipt by another application;
4. calculation or status assignment;
5. review and approval;
6. use in a report or decision;
7. and retention in an authoritative record source.

Testing should identify:

• the authoritative source;
• transferred data and metadata;
• mapping and transformations;
• record identifiers;
• units and precision;
• status values;
• timestamps;
• acknowledgments;
• rejected transactions;
• reconciliation;
• and final record location.

The test should confirm that the meaning and context of the data remain intact throughout the process.

Detailed interface controls are addressed in Computerized System Interfaces and Data-Transfer Controls.

Routine Workflows

Routine scenarios should represent normal, approved operating conditions. A routine scenario may include:

• authorized record creation;
• entry of valid data;
• completion of required fields;
• calculation;
• workflow routing;
• review;
• electronic signature;
• approval;
• report generation;
• interface transfer;
• and record retrieval.

The purpose is to demonstrate that the complete routine process works efficiently and consistently across roles and systems.

Routine scenarios should not merely repeat isolated functional tests. They should demonstrate that the activities work together as an operational process.

Exceptional Workflows

Exceptional scenarios should represent credible conditions outside the standard path. Examples include:

• rejected material;
• failed test result;
• record returned for correction;
• overdue activity;
• changed specification;
• missing information;
• unavailable approver;
• invalid interface transaction;
• duplicate record;
• cancelled process;
• reopened investigation;
• or required escalation.

Testing should confirm that:

• the exception is detected;
• the correct user is informed;
• the record enters the appropriate status;
• required review or investigation occurs;
• unauthorized bypass is prevented;
• and the process can be completed or formally terminated.

Exceptional workflows are often more revealing than routine transactions because they require technical controls and procedures to work together.

Expected Volumes

Testing should consider whether transaction and data volumes could affect the intended process. Applicable conditions include:

• number of records;
• report population;
• attachment size;
• interface-message volume;
• database growth;
• batch size;
• sample volume;
• and duration of data processing.

The test strategy should distinguish between:

• functional verification with representative data;
• volume testing;
• performance testing;
• load testing;
• and capacity qualification.

Not every system requires formal load testing. Additional volume testing is appropriate when response time, processing duration, report generation, interface queues, or storage constraints could affect the regulated process.

Acceptance criteria should be based on operational needs rather than arbitrary technical targets.

Concurrent Users

Concurrent-user testing may be appropriate when simultaneous activity could affect:

• transaction processing;
• record locking;
• calculations;
• workflow status;
• response time;
• data consistency;
• or system availability.

The test should represent credible use rather than an unrealistic maximum unless the objective is stress testing.

Applicable scenarios may include:

• several users editing different records;
• two users attempting to update the same record;
• simultaneous approvals;
• concurrent report generation;
• or peak-period interface processing.

The test should verify that users receive clear information when a record is locked, changed, or no longer available for the attempted action.

Reports and Operational Outputs

User acceptance should include reports and outputs relied upon during the business process. Testing should confirm:

• appropriate access;
• correct selection criteria;
• complete record population;
• calculations and totals;
• status and date filters;
• sorting and grouping;
• readable formatting;
• record identifiers;
• and suitability for the intended decision.

Reports should be evaluated using realistic data and conditions.

A report may pass detailed functional testing but remain operationally unsuitable because users cannot interpret it, required information is difficult to locate, or output timing does not support the process.

Approval and Disposition Decisions

Where the system supports regulated decisions, testing should confirm that authorized users receive complete and accurate information. Applicable decisions include:

• approving a record;
• accepting or rejecting a result;
• releasing or rejecting material;
• approving a batch;
• closing an investigation;
• approving a change;
• assigning product status;
• or accepting a residual risk.

Testing should confirm:

• required information is available;
• incomplete records cannot proceed when prohibited;
• the correct role performs the decision;
• the decision is recorded;
• the electronic signature is correctly applied where used;
• downstream status changes occur;
• and connected systems receive the correct result.

For applicable closed systems, 21 CFR 11.10 addresses validation supporting accuracy, reliability, consistent intended performance, and the ability to identify invalid or altered records.

Interface Failures

End-to-end testing should include representative interface failures when they could affect the business process. Applicable conditions include:

• destination unavailable;
• source unavailable;
• rejected message;
• invalid format;
• missing required field;
• duplicate transaction;
• delayed transfer;
• partial processing;
• failed acknowledgment;
• and unsuccessful retry.

The test should confirm:

• detection;
• notification;
• transaction status;
• data preservation;
• prevention of duplicate processing;
• reconciliation;
• correction;
• retransmission;
• and documented closure.

An interface failure is not adequately controlled when it remains visible only in a technical log that is not routinely monitored.

Downtime and Manual Operation

Downtime testing may be required when the business process must continue during planned or unplanned system unavailability. The test should address:

• downtime declaration;
• responsible roles;
• access to required forms or information;
• manual record creation;
• temporary identifiers;
• approval during downtime;
• protection of records;
• restoration of service;
• delayed data entry;
• reconciliation;
• duplicate prevention;
• and closure of downtime records.

A manual workaround should be realistic and executable. Merely stating that the process will be performed manually does not demonstrate that users have the required information, forms, instructions, and controls.

Testing should also confirm how the organization handles transactions started before the outage and completed after restoration.

Restart and Recovery

End-to-end recovery testing should determine whether the business process can resume in a controlled manner. Testing may include:

• restarting interrupted work;
• identifying incomplete transactions;
• confirming record status;
• reconciling delayed interfaces;
• recovering queued messages;
• reissuing notifications;
• resolving duplicate entries;
• and confirming that required records remain available.

Restoration of technical services is addressed separately through backup and recovery testing. End-to-end recovery confirms that the business process and its records remain controlled after those services are restored.

User Acceptance

User acceptance should be documented by individuals with appropriate process knowledge and authority. Acceptance should confirm that:

• representative workflows support the intended process;
• users can complete assigned activities;
• required information is available;
• procedures align with system behavior;
• reports and outputs support decisions;
• exceptional conditions can be managed;
• and identified limitations are understood.

Acceptance should not be reduced to a signature without defined criteria.

User preference alone should not determine acceptance. The conclusion should be based on approved requirements, intended use, objective evidence, deviations, and residual risk.

Observations, Deviations, and Defects

Testing may identify:

• functional failures;
• configuration errors;
• unclear procedures;
• missing training;
• usability concerns;
• performance limitations;
• interface failures;
• data-quality problems;
• or operational restrictions.

Each significant issue should be classified and assessed.

The record should identify:

• the observed condition;
• affected process and requirement;
• potential product, patient, data, or regulatory impact;
• corrective action;
• required retesting;
• regression scope;
• procedure or training updates;
• and final disposition.

Minor user observations may be managed separately from validation deviations when they do not affect requirements, controls, data, or intended use. The classification method should be defined.

Retesting

Retesting should confirm that corrections resolve the identified issue. The retest scope should consider whether the correction affected:

• other workflow steps;
• user roles;
• reports;
• procedures;
• interfaces;
• master data;
• or connected systems.

When the correction changes the approved configuration, affected functional tests may also require regression.

Results should remain connected through Requirements Traceability and Validation Evidence.

Intended-Use Confirmation

The final conclusion should determine whether the configured system supports its approved intended use.

The conclusion should consider:

• representative business-process results;
• actual user-role participation;
• realistic data;
• procedures;
• connected systems;
• data-flow integrity;
• routine and exceptional workflows;
• operational volumes;
• concurrency;
• reports;
• approval decisions;
• interface failures;
• downtime and recovery;
• deviations and defects;
• and user acceptance.

For drug-manufacturing computerized systems, 21 CFR 211.68 requires appropriate controls over computer or related systems and accuracy checks for input and output based on system complexity and reliability.

FDA’s Part 11 Scope and Application guidance recommends that validation extent reflect a documented risk assessment and potential effects on product quality, safety, and record integrity. This supports selecting appropriate intended-use evidence rather than imposing the same PQ format on every system.

Completion and Approval

End-to-end or user acceptance testing may be considered complete when:

• required scenarios were executed;
• actual users and roles were represented;
• acceptance criteria were met;
• objective evidence is complete;
• procedures and training are acceptable;
• interface and downtime scenarios were resolved;
• deviations and defects were closed or accepted;
• required retesting was completed;
• residual risks were approved;
• and the intended-use conclusion is documented.

Completion supports the system-release decision but does not replace it. Release should consider the complete validation and operational-readiness evidence.

Practical Outcome

Effective end-to-end and user acceptance testing demonstrates that the configured system works within the complete regulated business process—not merely that its individual functions operate.

The evidence should confirm that users, procedures, data, interfaces, reports, decisions, exceptions, and recovery arrangements work together to support the approved intended use.

A separate PQ protocol should be created only when it provides necessary evidence. The validation conclusion depends on the completeness and quality of that evidence, not on the presence of a document titled “PQ.”