What Makes User Acceptance Testing Representative for a GxP Process?

User acceptance testing often becomes a final demonstration of configuration already exercised elsewhere. A knowledgeable super-user follows clean scripts with prepared records, every expected result appears, and the process owner signs. That proves the selected scenarios completed in the test environment. It may say little about whether ordinary users can operate the real process under its material conditions.

Representativeness is a coverage argument. It connects intended use and risk to the people, records, decisions and exceptions selected for testing.

Define what UAT is accepting

Technical qualification and UAT answer different questions. Technical testing may establish that configured functions operate as specified. UAT should establish that the configured service supports the intended business process sufficiently for accountable users to accept it.

Start with a concise acceptance boundary:

• regulated processes and decisions included;
• organisational units, products, countries or process variants covered;
• user roles and segregation assumptions;
• upstream and downstream systems relied upon;
• reports, notifications and manual controls needed to complete work;
• exclusions and the control that makes each exclusion acceptable.

EU GMP Annex 11 expects user requirements to describe required functions, be based on documented risk assessment and remain traceable through the lifecycle. It also expects evidence of appropriate test methods and scenarios. It does not mandate a universal UAT structure or sample size. The organisation must justify how its evidence fits intended use and risk.

Select users by role conditions, not availability

The most experienced project user is useful for finding defects and often unrepresentative of normal operation. Representative users should collectively reproduce the material conditions under which the process will run.

Include roles that:

• create or amend the regulated record;
• review evidence rather than only fields;
• approve, reject or return work;
• administer controlled data or configuration where part of the process;
• receive a handoff from another function or location;
• operate with restricted access;
• act when the primary owner is absent.

Participation does not require a statistically representative workforce. It requires a reasoned selection of the roles and differences that can change the result. If one country follows an additional approval, one product uses different master data or one external user sees a reduced record, those conditions matter more than adding several interchangeable users.

Test with the permissions users will actually receive. An administrator proving the workflow works does not show that an assigned investigator can reach the source evidence, that an approver can see attachments, or that an external user is prevented from seeing unrelated records.

Make test data materially representative

Representative does not necessarily mean copied from production. Test data should reproduce the characteristics that drive workflow, calculation, security, reporting and exception behaviour without creating an uncontrolled privacy or confidentiality exposure.

Identify dimensions that matter, such as:

• boundary values and permitted formats;
• optional and missing data;
• long text, attachments and multiple related records;
• active, obsolete and future-effective reference values;
• restricted products, countries or organisations;
• records arriving from interfaces at different times;
• duplicates and conflicting identifiers;
• historical records that follow an older process version.

A small synthetic set can be representative when it deliberately covers these conditions. A large production extract can be unrepresentative when every selected record follows the same common path.

Record the relationship between each data condition and the requirement, risk or business rule it exercises. That makes the selection reviewable rather than anecdotal.

Test the complete operating path

UAT should not stop at the primary application screen. If the live process relies on an interface, scheduled report, email, controlled spreadsheet, support queue or manual reconciliation, the acceptance path should include it or explicitly bound it outside the evidence claim.

For each end-to-end scenario, follow the record through:

1. creation or receipt;
2. classification and assignment;
3. evidence collection;
4. review and decision;
5. rejection, correction or escalation where applicable;
6. downstream transmission or reporting;
7. final state and retained evidence.

Check both the regulated result and the evidence left behind. A notification arriving is not enough if its recipient, timestamp or linked record cannot later be reconstructed. A report rendering is not enough if the filters and data latency differ from the live decision use.

Include exceptions that change the decision

Not every theoretical failure belongs in UAT. Prioritise exceptions that can cause work to continue with missing evidence, wrong authority or a misleading state:

• an approver is unavailable or lacks access;
• required evidence is rejected or replaced;
• an integration is late, duplicated or unavailable;
• a record is returned after partial approval;
• reference data changes while work is open;
• a user attempts an action outside their role;
• a downstream action fails after the source record advances;
• a report excludes a record that should affect a decision.

These scenarios show whether the process stops, becomes conditional or creates a controlled exception. Testing only successful completion establishes that users can agree with the configured path. It does not establish that they can safely disagree with it.

Observe usability as a control condition

UAT is not a general satisfaction survey, but usability can be a control issue. If users cannot distinguish current from superseded content, cannot find the source behind a decision, or routinely choose the wrong action because labels are ambiguous, the process may be technically functional and operationally unsafe.

Capture observations against defined acceptance criteria. Avoid converting every preference into a defect, but do not dismiss repeated confusion where it changes record state, evidence selection or authority.

Training should support execution, not explain away poor design. If a critical step succeeds only because the project expert tells each tester where to click, the evidence reflects coached execution rather than the operating condition after handover.

Make the acceptance conclusion precise

The UAT report should state more than “all scripts passed”. It should identify:

• the intended uses and variants covered;
• participants and the roles they represented;
• material test-data characteristics;
• environment and configuration baseline;
• connected systems and manual controls included;
• deviations, defects, retests and residual limitations;
• exclusions and their treatment;
• the exact operational conclusion supported.

The conclusion might be that the defined process is acceptable for specified sites and roles, subject to a controlled manual reconciliation until an interface is enabled. That is stronger than an unqualified pass because it states the boundary of reliance.

FDA's *General Principles of Software Validation*, within its medical-device software and medical-device design, development and manufacturing scope, describes validation in terms of objective evidence that software specifications conform to user needs and intended uses. The principle is useful here, but it does not prescribe a general pharmaceutical UAT methodology. ICH Q9(R1) supports science-based and proportionate quality-risk decisions. Neither source supplies a mechanical UAT recipe. The coverage rationale remains the regulated organisation's decision.

Derive scenarios systematically

Build the UAT set from three inputs rather than beginning with existing scripts.

1. Intended use: list the regulated decisions, outputs and process endpoints the service must support.
2. Process risk: identify where wrong state, missing evidence, inappropriate authority, late action or misleading reporting could affect the decision.
3. Business variation: identify roles, sites, products, data conditions, interfaces and local rules capable of changing behaviour.

For each intended use, write a nominal end-to-end scenario. Add a scenario when a risk needs a distinct challenge or a business variant changes configuration, permission, data, handoff, control or expected evidence. Do not add cases merely because labels differ.

Trace every selected scenario to its intended use and material condition. Trace every excluded high-risk condition to an equivalence rationale, another test level or a compensating control. This produces a coverage argument rather than a large collection of plausible scripts.

Use a coverage matrix

A compact matrix makes gaps and unnecessary repetition visible. For example:

The final matrix should demonstrate coverage of each material role, condition, variant, interface and exception or record a defensible reason for its exclusion. Coverage is not a checkbox count. One scenario can cover several dimensions when the combination is credible. Some combinations deserve separate cases because their interaction creates risk—for example restricted access during a rejection handoff.

Decide when local variants need execution

Separate execution is normally warranted when a local variant changes:

• configured workflow or lifecycle;
• required role or segregation;
• decision criteria or approval authority;
• controlled reference data;
• interface, report or manual handoff;
• evidence retained at completion;
• failure or escalation behaviour.

Documented equivalence may be sufficient when the difference is cosmetic or organisational and the underlying configuration, permissions, data behaviour, control and expected evidence are demonstrably the same. The equivalence record should identify the compared variants, attributes reviewed, evidence supporting sameness and accountable approver.

Avoid declaring equivalence solely because sites use the same global template. Local security assignments, integrations, language, reference values or operating procedures may still create a materially different path.

Test handoffs as controlled transitions

At each handoff, identify what transfers, who becomes responsible, what evidence the receiver can see and what must happen if the transfer is incomplete. Include system-to-system, role-to-role, site-to-global and external-party handoffs.

A useful handoff case verifies the sending state, receiving task, identity and timing, access to supporting evidence, rejection route, overdue escalation and final audit record. Where an interface carries the handoff, introduce late, duplicate and failed delivery. Where a person carries it, remove the named owner or restrict access. The test should show whether the process stops or creates a visible exception rather than allowing each side to assume the other completed it.

Distinguish UAT from adjacent test activities

For practical assurance design, it is useful to separate the questions these activities are intended to answer; this is a Navata practitioner distinction rather than a regulatory classification.

Evidence may be reused where purposes and conditions genuinely align, but relabelling one successful test does not make it answer all four questions. For example, a qualified workflow may still fail UAT because ordinary approvers cannot see necessary evidence, and accepted business processing may still be operationally unready because support cannot reconcile a failed interface.

Assess environment representativeness

Record material differences between the UAT environment and planned production: configuration baseline, integrations, identity provider, roles, reference data, scheduled jobs, volumes, devices, performance and external services. For each difference, decide whether it changes the scenario or evidence claim.

Exact production equivalence is rarely possible. A stubbed interface may be acceptable for a business decision that does not depend on timing or error behaviour, while it is inadequate for accepting a handoff whose control relies on acknowledgements and retries. Masked or synthetic data may be suitable when its structure and boundary conditions remain representative.

The UAT report should state which differences were accepted, why, and what separate evidence covers them. A generic declaration that the environment is “production-like” is not a coverage rationale.

Worked example: deviation approval

Suppose the intended use is to create, investigate and approve deviations across global and local sites. The principal risks are missing evidence, inappropriate approval, failure to escalate overdue work and incorrect closure after a rejected conclusion.

The nominal scenario covers creation through approval using standard data. Additional cases use an investigator with ordinary permissions, a restricted attachment, a returned root-cause conclusion, an unavailable approver, an overdue escalation and a late laboratory interface result. A local site requires an additional Quality approval, so it receives separate execution. Another site differs only in the displayed department label; documented equivalence is reasonable after confirming the same configuration, roles and evidence.

The UAT conclusion can then state exactly which roles, data conditions, sites, handoffs and exceptions were represented. It does not claim every possible deviation was tested.

Justify exclusions with evidence

For every excluded material role, variant or scenario, retain:

• the excluded condition;
• why it does not change behaviour or reliance;
• configuration, comparison or prior evidence supporting that conclusion;
• where any residual risk is tested or controlled;
• the process owner accepting the exclusion;
• the trigger that would invalidate equivalence.

This record prevents a later reviewer from interpreting absence as accidental. It also permits targeted reuse when another site or process variant is introduced.

Sources

• European Commission, EudraLex Volume 4, Annex 11: Computerised Systems.
• US Food and Drug Administration, General Principles of Software Validation.
• International Council for Harmonisation, ICH Q9(R1): Quality Risk Management.