Computer System Validation

IQ, OQ and PQ Explained — In Depth, With Examples

Updated 2026-11-07

Most people can recite that IQ is installation, OQ is operation and PQ is performance. Fewer can say what actually goes in each, or write a test step that passes or fails on objective evidence rather than on the tester’s opinion. This article goes a level deeper, using an invented example throughout: a fictional laboratory balance data-capture system that records weights and sends them to a LIMS.

If you need the groundwork first, start with what Computer System Validation is.

The principle underneath all three

Each qualification verifies something you specified earlier, at a matching level of detail. IQ confirms the system is installed as designed. OQ confirms it functions as specified. PQ confirms it performs in the real process. Together they walk up the right-hand side of the V-model, meeting the specifications that came down the left.

A test step in any of them has the same anatomy: a clear instruction, the expected result (objective, defined before execution), and the evidence to capture. If a stranger could run the step and reach the same pass/fail conclusion you would, it is written well.

Installation Qualification (IQ)

IQ answers: is it installed correctly, in the right environment, as specified?

Typical contents:

  • Correct software version and build, recorded against the specification
  • Correct server/client hardware and operating environment
  • Required services, databases and connections present
  • Interfaces physically and logically connected
  • Installation performed by authorised personnel, following the procedure

Sample IQ step

Step: Record the installed application version from Help → About. Expected result: Version matches v4.2.1 as stated in the configuration specification CS-003. Evidence: Screenshot of the About dialog attached and referenced.

Note what makes it good: the expected value is specific (v4.2.1) and pre-defined, and the evidence is named up front — not “verify the version is correct”, which leaves the tester to decide what “correct” means.

Operational Qualification (OQ)

OQ answers: does it function as specified, across its operating range? This is usually where the bulk of functional testing sits, and where risk should most visibly drive depth.

Typical contents:

  • Core functions work as specified
  • Security and access control behave correctly (positive and negative)
  • The audit trail captures the right events
  • Alarms, limits and calculations behave at and around their boundaries
  • Error handling and recovery

Sample OQ step — access control (negative test)

Step: Log in as a user with the “Analyst” role and attempt to delete a weight record. Expected result: The system prevents the deletion and displays a permission-denied message. No record is deleted. Evidence: Screenshot of the denial; confirmation the record still exists.

That is a negative test — confirming the system refuses what it should refuse. Critical functions need both positive tests (it does what it should) and negative tests (it blocks what it shouldn’t).

Sample OQ step — boundary on a limit

Step: Enter a target weight of 0.00 g and of the maximum 220.00 g, then 220.01 g. Expected result: 0.00 g and 220.00 g are accepted; 220.01 g is rejected with a range error. Evidence: Screenshots of each outcome.

Testing at and just past the boundary catches the errors that mid-range values never reveal.

Performance Qualification (PQ)

PQ answers: does it do what we actually need, in routine use, with real users and realistic data? It is typically run against the user requirements, with trained users following the real workflow.

Sample PQ step

Step: A trained analyst weighs three control samples and completes the normal workflow, including transfer to the LIMS. Expected result: All three weights appear in the LIMS matching the balance to two decimal places, attributed to the analyst, with audit trail entries for each. Evidence: LIMS records and audit trail export attached.

PQ is where the system meets reality: real users, real process, end to end.

Objective acceptance criteria

The single most common weakness in test scripts is the phrase “works as expected”. Expected by whom, measured how? Replace it every time with a criterion that is defined before execution and that two people would score identically:

  • Not “the report is correct” → “the report total equals 15.00 g, matching the sum of the three entered weights”.
  • Not “access works” → “the Analyst role cannot delete; the Supervisor role can”.

Handling a failed step

A failure during execution is normal and is evidence, not something to quietly fix. The disciplined response: record the result as it happened, raise a deviation, investigate the cause (test-script error, environment, or a genuine system defect), document the resolution with Quality, and only then re-test under a controlled, approved route. Editing the script and re-running until it passes, keeping only the passing run, is a data integrity problem — exactly what ALCOA+ in practice warns against.

Next