IQ, OQ, PQ Protocol Structure: When to Use Each

IQ, OQ, and PQ each answer a different question about a system. Confusing them, or collapsing them into one generic test pass, removes the diagnostic value of knowing exactly where a later failure belongs.

Shortcut: OQ proves a function works as designed. PQ proves it keeps working at real scale, with real data, under real conditions.

At a glance

Installation qualification: confirming the foundation

IQ establishes that hardware, software, and configuration match the approved design before any functional testing begins. Skipping IQ or blending it into OQ removes the ability to isolate an installation problem from a functional one later.

• Verifies software version, configuration files, and environment settings
• Confirms infrastructure specifications match the approved design
• Produces a documented baseline that later change control references

Operational qualification: proving the function

OQ tests every specified function under controlled conditions using scripted test cases, confirming the system behaves as designed when everything is set up exactly as intended.

• Tests boundary conditions, not just the expected path
• Uses controlled, often synthetic test data to isolate function behavior
• Documents pass/fail against explicit, pre-approved acceptance criteria

Performance qualification: proving it holds up in reality

PQ is where real users, real data volumes, and real workflows meet the system. A function that passed OQ cleanly can still fail PQ if it was never tested under realistic load or genuine use patterns.

• Uses production-representative data volume and complexity
• Involves actual end users executing actual business processes
• Surfaces issues OQ's controlled conditions could never reveal

A worked failure pattern

A system passing OQ with perfect scores but failing badly during PQ is not a validation failure, it is validation working exactly as intended, catching a gap between designed behavior and real operating conditions before go-live rather than after.

• Investigate whether the gap is a defect, a configuration issue, or a genuine requirement gap
• Route the fix through change control before re-testing
• Re-execute PQ against the corrected configuration, not just a partial retest

Keeping the three phases genuinely distinct

The value of the three-phase structure disappears the moment OQ and PQ scripts become interchangeable copies of each other with different headers.

• Write PQ scenarios directly from real business processes, not from OQ scripts
• Involve actual end users in PQ scenario design
• Require each phase to close with its own documented acceptance criteria met

Why this matters at review time

Inspectors reviewing a validation package look specifically for evidence that IQ, OQ, and PQ tested different things rather than the same checklist run three times under different headings. A validation package where all three protocols contain near-identical test steps signals that the team did not think through what each qualification stage is actually meant to prove.

Who owns what

Common mistakes to avoid

• Running OQ tests inside the IQ protocol. Installation qualification confirms the system was installed as specified; mixing in functional checks blurs the record and makes it harder to isolate an installation problem from a configuration problem later.
• Skipping PQ because OQ passed. Operational qualification proves the system works to specification under controlled conditions; performance qualification proves it works reliably under real operating conditions and load, which is a separate question.
• Reusing OQ scripts unchanged as PQ scripts. PQ needs to reflect actual users, actual data volumes, and actual workflows, not a repeat of the same synthetic test cases used in OQ.
• Treating the three phases as a formality rather than a decision tool. IQ, OQ, and PQ each answer a different question; skipping the distinction to save time removes the diagnostic value of knowing which layer a failure belongs to.

Putting this into practice

Plan IQ, OQ, and PQ as three separate protocols with distinct acceptance criteria before writing a single test script. Confirm IQ closes cleanly, including verified installation records, before OQ scripts execute against the system. Design PQ scenarios directly from real business processes and real user roles, ideally with input from the people who will actually use the system daily.

Quick checklist

• IQ protocol confirms hardware, software, and configuration match the approved design
• OQ protocol tests every specified function under controlled test conditions
• PQ protocol tests real workflows with real user roles and realistic data volumes
• Each phase has its own acceptance criteria, not a shared pass/fail line
• PQ scenarios were reviewed or authored with input from actual end users
• A failure in any phase is documented before the next phase begins

Where this shows up in practice

This distinction matters most when something fails after go-live and the team needs to know where to look first. A failure traceable to installation configuration points back to IQ records. A failure traceable to a specific function not working as designed points to OQ. A failure that only appears under real load or with real data patterns points to a PQ gap. Without the three-phase separation, every production issue turns into an open-ended investigation instead of a targeted one.

A worked example

A pharmacy inventory system passes OQ with every scripted function working exactly as specified. During PQ, real pharmacists report the system becomes unresponsive when running a month-end reconciliation report against the full production-scale dataset, something OQ never tested because its scripts used a small sample dataset. This is exactly the gap PQ exists to catch: OQ proved the function works, PQ proved it does not work reliably at real scale. The fix belongs in a change control ticket referencing the PQ deviation, not a quiet adjustment to the reconciliation report outside the validation record.

For related control detail, see test script design and acceptance criteria elsewhere in this archive.

Frequently asked questions

Can PQ be skipped if OQ passes with zero deviations?

No. OQ and PQ answer different questions; a clean OQ result says nothing about how the system behaves under real data volume and genuine user workflows, which is precisely what PQ exists to test.

Does IQ need to be repeated after every software patch?

Not necessarily a full IQ repeat, but any patch changing installed configuration should trigger a documented review of whether the IQ baseline still holds, handled through change control.

Who should design PQ test scenarios?

Actual end users and process owners, not only the validation team, since PQ's entire value depends on testing real workflows rather than synthetic scripts dressed up as realistic ones.

What is the biggest sign that IQ, OQ, and PQ were not genuinely separated?

Nearly identical test scripts appearing across all three protocols with only the heading changed; each phase should have visibly distinct scope and test design.

How much data volume does PQ actually need to be meaningful?

Enough to represent real production scale and complexity for the specific system; a PQ using a small synthetic dataset provides little more diagnostic value than OQ did.