Computerized System Functional and Control Testing

Computerized system functional and control testing provides documented evidence that the configured system performs its approved functions and that its preventive, detective, and corrective controls operate effectively.

This activity has traditionally been called Operational Qualification (OQ). The term remains useful when it is part of the organization’s validation lifecycle, but the testing objective is more important than the protocol label. Testing should verify configured behavior, challenge credible failure conditions, and establish that the system supports its approved requirements and risk controls.

Purpose of Functional and Control Testing

Functional and control testing should confirm that:

• configured functions operate as specified;
• workflows enforce the approved process;
• business rules and calculations are correct;
• status transitions occur only under permitted conditions;
• security roles allow authorized actions and prevent unauthorized actions;
• audit trails and electronic signatures operate correctly;
• reports contain accurate and complete information;
• interfaces transfer and reconcile data correctly;
• alarms and notifications occur under defined conditions;
• configuration restrictions prevent uncontrolled changes;
• invalid inputs and prohibited actions are rejected;
• failures are detected and handled appropriately;
• recovery controls restore the process to a controlled condition;
• and results are supported by reviewable objective evidence.

The scope and depth of testing should reflect the system’s intended use, risk, complexity, configuration, custom components, supplier evidence, and uncertainty regarding control effectiveness.

Position Within the Validation Lifecycle

Functional testing should be based on approved requirements, specifications, risk assessments, and the installed technical baseline. The principal inputs include:

• the intended use and validation strategy;
• the User Requirements Specification;
• functional, design, and configuration specifications;
• the computerized system risk assessment and test strategy;
• supplier documentation;
• approved configuration records;
• and Computerized System Installation and Environment Qualification.

Installation Qualification establishes that the approved application and technical environment have been installed or provisioned correctly. Functional testing builds upon that baseline by demonstrating that the configured functions and controls perform as intended.

Successful functional testing does not by itself authorize production release. Migration, procedures, training, end-to-end testing, deviations, traceability, backup and recovery, and other release prerequisites may still require completion.

Requirements-Based and Risk-Based Coverage

Each test should address an approved requirement, risk control, specification, or defined verification objective. The test strategy should identify:

• functions requiring scripted testing;
• areas suitable for unscripted or exploratory testing;
• critical calculations and business rules;
• required positive, negative, and boundary challenges;
• interfaces and connected systems;
• security and data-integrity controls;
• failure and recovery scenarios;
• acceptable use of supplier evidence;
• required regression testing;
• and evidence expectations.

Risk-based testing does not mean that lower-risk requirements can be excluded without evaluation. A requirement may still require verification because it supports intended use, enables another critical function, or provides a required control.

Numerical risk scores may support prioritization, but they should not be the sole basis for eliminating testing.

Test Preconditions

Before test execution, the organization should confirm that:

• the approved system version is installed;
• the test environment is identified;
• relevant configuration is complete;
• required interfaces and dependencies are available;
• test accounts and roles are approved;
• test data are prepared;
• expected results are defined;
• unresolved installation discrepancies have been assessed;
• and the test environment is sufficiently representative.

Test preconditions should distinguish between:

• configuration required for the test;
• data created during execution;
• existing reference or master data;
• and conditions established by another approved test.

Uncontrolled changes during execution can invalidate results or make them difficult to reproduce.

Workflow Testing

Workflow testing should verify the configured sequence of activities from initiation through completion. Applicable challenges include:

• creation of a new record;
• assignment to the correct user or group;
• required review and approval;
• permitted and prohibited status changes;
• return for correction;
• rejection or cancellation;
• escalation;
• reopening;
• closure;
• and retention of completed records.

Testing should determine whether users can:

• skip a required step;
• approve their own work when prohibited;
• change a completed record;
• move a record backward without authorization;
• close a record with missing information;
• or perform actions in an incorrect sequence.

Where applicable, workflow testing supports the operational checks described in 21 CFR 11.10(f), which address enforcement of permitted sequencing of steps and events.

Business Rules

Business rules determine how the system responds to defined data, events, conditions, and decisions.

Examples include:

• routing based on record type;
• due-date calculation;
• approval requirements based on risk or value;
• automatic assignment;
• material or product status;
• specification selection;
• escalation logic;
• exception handling;
• and release restrictions.

Testing should verify:

• each applicable rule;
• combinations of conditions;
• rule priority where several rules apply;
• behavior when required information is missing;
• and the result when no rule condition is satisfied.

A successful routine transaction may not adequately challenge branching or conditional logic.

Calculations

Calculations should be verified against independently established expected results. Testing should consider:

• formula logic;
• units of measure;
• conversions;
• constants;
• rounding;
• decimal precision;
• significant figures;
• date and time calculations;
• intermediate results;
• lookup values;
• and treatment of blank, zero, negative, or invalid inputs.

Where calculations depend on configuration or master data, the test should identify the applicable:

• formula version;
• lookup table;
• specification;
• conversion factor;
• and effective date.

Testing only one typical value is generally inadequate for a critical calculation. Suitable challenges should include normal values, boundary values, and values capable of exposing rounding, precision, or conditional-logic errors.

Status Transitions

Status controls can affect material disposition, product release, record approval, workflow completion, or downstream processing. Testing should confirm:

• permitted starting and ending states;
• authorized roles;
• required preceding activities;
• mandatory information;
• approval requirements;
• electronic signatures;
• effective date and time;
• downstream effects;
• and audit-trail entries.

Negative testing should attempt prohibited transitions, such as:

• draft directly to approved;
• rejected to released;
• closed to editable;
• or approved to deleted.

The test should verify that the prohibited transition is prevented and that the user receives an appropriate response.

Security Roles and Permissions

Security testing should demonstrate that authorized users can perform their assigned functions and that unauthorized users cannot. Testing should address applicable permissions for:

• viewing;
• creating;
• editing;
• reviewing;
• approving;
• deleting;
• invalidating;
• exporting;
• printing;
• configuring;
• administering;
• and changing master data.

The role matrix should be compared with the implemented permissions.

Testing should include representative user roles and, where applicable:

• system administrators;
• business administrators;
• reviewers;
• approvers;
• read-only users;
• service accounts;
• and temporary or restricted users.

Testing only authorized actions is incomplete. Negative tests should attempt access to restricted records, functions, menus, reports, configuration, and administrative tools.

Part 11 closed-system controls include authority checks intended to ensure that only authorized individuals can use the system, electronically sign records, access input or output devices, alter records, or perform the applicable operation. These controls are described in 21 CFR 11.10(g).

Audit-Trail Testing

Audit-trail testing should be based on the system’s intended use and the types of changes that must remain attributable and reviewable. Applicable tests may confirm capture of:

• record creation;
• data modification;
• previous and new values;
• deletion or invalidation;
• status changes;
• approval actions;
• reasons for change;
• configuration changes;
• master-data changes;
• user identity;
• date and time;
• and system-generated events.

Testing should also determine whether:

• users can disable or modify the audit trail;
• entries remain linked to the affected record;
• audit-trail timestamps are correct;
• filtering and searching work as intended;
• entries can be reviewed;
• and exported audit-trail information remains understandable.

Audit-trail testing should not be limited to confirming that an audit-trail screen exists. The test should demonstrate that relevant actions generate complete, accurate, protected, and usable entries.

Electronic-Signature Testing

Where electronic signatures are used, testing should confirm:

• signer authentication;
• authorized signature use;
• signature meaning;
• signer name;
• date and time;
• permanent linkage to the signed record;
• prevention of unauthorized signature use;
• and system response to failed authentication.

Applicable signature meanings may include:

• reviewed;
• approved;
• verified;
• performed;
• or released.

Testing should challenge situations such as:

• incorrect credentials;
• unauthorized signer;
• expired session;
• attempted signature reuse;
• record change after signing;
• and attempted removal or reassignment of the signature.

The signature should remain associated with the correct record and the state of that record at the time of signing.

Reports and Record Outputs

Reports should be tested for content, selection logic, calculations, formatting, and completeness. Testing should consider:

• report parameters;
• included and excluded records;
• date ranges;
• status filters;
• sorting;
• grouping;
• totals;
• calculations;
• units;
• pagination;
• headers and footers;
• record identifiers;
• signatures;
• and audit information.

Negative and boundary tests should address:

• no matching records;
• one record;
• maximum expected volume;
• long text;
• missing optional data;
• date boundaries;
• cancelled or invalidated records;
• and users without report permission.

For printed output, testing should verify that the correct report reaches the intended printer and remains readable and complete.

Interface Testing

Interface testing should demonstrate correct end-to-end transfer rather than only technical connectivity. Testing should address applicable:

• source and destination systems;
• field mapping;
• record identifiers;
• units;
• precision;
• status values;
• timestamps;
• metadata;
• transformations;
• acknowledgments;
• rejected transactions;
• duplicate messages;
• retries;
• interrupted transfers;
• reconciliation;
• and recovery.

The receiving record should be compared with the authoritative source and expected transformation.

Interface errors should be visible to the responsible user or support group. Technical logs alone may be insufficient when no controlled process exists for monitoring and resolving failed transactions.

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

Alarms and Notifications

Alarms and notifications may support timely intervention, escalation, review, or process control. Testing should confirm:

• triggering conditions;
• setpoints or business conditions;
• intended recipients;
• delivery method;
• message content;
• priority;
• delay;
• escalation;
• acknowledgment;
• reset;
• suppression;
• and event recording.

Testing should include conditions just below, at, and above applicable alarm limits.

Where notifications depend on external email, messaging, or paging services, testing should verify the complete route to the intended recipient.

Failure of a notification service should be detectable and governed by an approved response.

Configuration Restrictions

Configuration controls should prevent unauthorized or uncontrolled changes to functions that affect regulated processes or records. Testing may address restrictions over:

• workflows;
• calculations;
• specifications;
• code tables;
• master data;
• reports;
• interfaces;
• security roles;
• audit-trail settings;
• electronic-signature settings;
• and system parameters.

Testing should verify:

• who can view the configuration;
• who can change it;
• whether approval is required;
• whether the change is recorded;
• when the change becomes effective;
• and whether prior records remain interpretable.

The presence of an administrator role does not demonstrate that configuration is adequately controlled. The test should verify the implemented permissions and change-recording behavior.

Data Creation and Changes

Testing should evaluate the complete data lifecycle within the application. Applicable challenges include:

• record creation;
• required and optional fields;
• default values;
• edits before approval;
• corrections after review;
• reasons for change;
• copying or duplicating records;
• deletion or invalidation;
• reprocessing;
• and retained metadata.

The test should determine whether:

• required fields can be bypassed;
• invalid data can be entered;
• previous information remains available where required;
• changes are attributable;
• the correct record status is maintained;
• and data remain complete after processing.

FDA’s Data Integrity and Compliance With Drug CGMP guidance addresses controls supporting complete, consistent, and accurate CGMP data. Testing should translate applicable data-integrity expectations into system-specific challenges.

Error Handling

The system should respond to invalid or unexpected conditions in a controlled manner.

Testing may include:

• missing required data;
• invalid formats;
• duplicate records;
• invalid status combinations;
• unavailable dependent services;
• rejected interface messages;
• failed authentication;
• calculation errors;
• unavailable printers;
• storage constraints;
• and interrupted processing.

An effective error response should:

• prevent an incorrect transaction where necessary;
• provide an understandable message;
• preserve entered information where appropriate;
• avoid exposing confidential technical details;
• create the required log or audit entry;
• and support controlled correction or recovery.

Generic messages such as “an error occurred” may be inadequate when the user cannot determine whether the transaction was completed, rejected, or partially processed.

Failure Conditions and Recovery

Testing should address credible failures identified through risk assessment. Applicable conditions may include:

• application-service interruption;
• database disconnection;
• interface interruption;
• network loss;
• browser or client termination;
• failed scheduled job;
• duplicate submission;
• interrupted approval;
• notification failure;
• and unavailable downstream system.

The test should determine:

• whether the failure is detected;
• what information is presented to the user;
• whether partial processing occurred;
• whether data remain complete;
• whether a retry creates duplicates;
• whether rollback is effective;
• whether reconciliation is required;
• and how normal operation is restored.

Failure testing should be planned carefully to avoid damage to shared environments or uncontrolled interruption of other testing.

Boundary-Value Testing

Boundary testing evaluates system behavior at and around defined limits. Applicable boundaries include:

• minimum and maximum numeric values;
• values immediately inside and outside a limit;
• field length;
• decimal precision;
• date range;
• expiry date;
• capacity;
• number of records;
• concurrent users;
• file size;
• and transaction volume.

For a field accepting values from 1.0 through 10.0, a useful test set may include:

• 1.0;
• 10.0;
• a value below 1.0;
• a value above 10.0;
• the maximum permitted decimal precision;
• an invalid format;
• and a blank value.

Boundary testing should focus on conditions that could reveal an incorrect calculation, comparison, truncation, overflow, or control response.

Positive and Negative Testing

Positive testing demonstrates that valid data, authorized users, and approved sequences produce the expected result.

Negative testing demonstrates that the system prevents, rejects, detects, or safely handles prohibited or invalid conditions.

Negative testing may include attempts to:

• omit required data;
• enter invalid values;
• bypass an approval;
• perform an unauthorized action;
• change a protected record;
• use an invalid electronic signature;
• force an incorrect status transition;
• submit a duplicate transaction;
• access restricted configuration;
• or process information while a dependency is unavailable.

The expected outcome should be defined. “The test should fail” is insufficient because the required system response may include prevention, an error message, an audit entry, notification, or controlled recovery.

Test Scripts and Objective Evidence

A scripted test should contain enough information to demonstrate what was tested and whether the acceptance criteria were met.

The test record should identify:

• test objective;
• associated requirement or risk;
• preconditions;
• system and environment;
• configuration or version;
• user role;
• test data;
• execution steps;
• expected results;
• actual results;
• objective evidence;
• tester;
• execution date;
• and final status.

Evidence may include:

• completed test records;
• screenshots;
• system-generated reports;
• audit-trail entries;
• interface messages;
• transaction records;
• database or log evidence;
• automated-test results;
• calculations;
• and configuration exports.

Screenshots should be used selectively. They should show the relevant result, sufficient context, and system identity where needed. Screenshots should not replace a clear actual-result statement.

Unscripted and Exploratory Testing

Unscripted testing may supplement formal scripts when experienced users or testers need to explore system behavior beyond predetermined steps.

A controlled exploratory test should define:

• the test charter;
• area or function examined;
• tester;
• time or session;
• data used;
• observations;
• unexpected behavior;
• and retained evidence.

Exploratory testing can be useful for:

• complex workflows;
• unusual data combinations;
• user-interface behavior;
• error handling;
• configuration interactions;
• and functions where unexpected behavior is difficult to predict.

It should not automatically replace scripted testing when repeatable execution, precise acceptance criteria, or formal evidence are necessary.

Deviations and Defects

An unexpected result should be documented when the observed behavior differs from the approved expected result. The evaluation should determine whether the cause is:

• a system defect;
• an incorrect configuration;
• a test-script error;
• inappropriate test data;
• an environment problem;
• a requirement or specification issue;
• or an execution error.

The deviation record should identify:

• affected test and requirement;
• observed result;
• immediate assessment;
• investigation;
• root cause where appropriate;
• corrective action;
• effect on other tests;
• retest requirements;
• regression scope;
• and final disposition.

The original result should remain visible. A failed test should not be overwritten or replaced by a successful rerun without retaining the failure and its resolution.

Retesting and Regression Testing

Retesting confirms that the specific correction resolved the failed condition. Regression testing evaluates whether the correction affected other functions or controls.

The scope should consider:

• connected requirements;
• shared workflows;
• calculations;
• configuration dependencies;
• reports;
• interfaces;
• security roles;
• audit trails;
• electronic signatures;
• master data;
• and previously completed tests.

A successful retest does not automatically demonstrate that related functions remain unaffected.

The correction, resulting configuration, retest, regression evidence, and final disposition should remain traceable through Requirements Traceability and Validation Evidence.

Test Completion and Approval

Functional and control testing may be considered complete when:

• required tests were executed;
• acceptance criteria were evaluated;
• objective evidence is complete;
• deviations and defects were resolved or accepted;
• required retesting and regression testing were completed;
• requirements and risk controls are traceable;
• the tested configuration matches the intended baseline;
• and residual risks were formally accepted.

The completion record should identify any:

• open defect;
• operational restriction;
• compensating control;
• deferred function;
• monitoring requirement;
• or follow-up action.

Approval indicates that the functional-testing objectives were met. It does not replace the complete system-release assessment.

Practical Outcome

Effective functional and control testing demonstrates that the configured system:

• performs its specified functions;
• enforces required business and security controls;
• creates and changes data appropriately;
• records regulated actions;
• rejects prohibited or invalid activities;
• handles exceptions and failures predictably;
• supports recovery;
• and produces reliable, traceable evidence.

The purpose is not to execute the largest possible number of test steps. It is to provide sufficient evidence that the configured functions and controls operate reliably for their approved GxP use.