At a glance
- CSV testing is not “run every prewritten IQ/OQ/PQ script.” It is a risk-based decision about what to test, how rigorously, and where vendor evidence or lighter testing can replace exhaustive scripting.
- The work starts before you write a single script, with a validation (risk) assessment that scopes testing to where the risk to product quality and patient safety actually is.
- A test script has a definite anatomy: steps, inputs, expected versus actual results, pass/fail, captured evidence, deviation handling, and reviewer sign-off.
- Scripted, unscripted (exploratory), and automated testing each have a place; choose per risk rather than scripting everything by reflex.
- The CSA mindset reinforces this: scale test effort to intended use and impact. Least-burdensome means proportionate, not minimal.
If you have to actually execute validation testing on a system, you have probably hit the gap the explainer pages leave: they define IQ/OQ/PQ and hand you a generic script template, but they do not tell you how to decide what to test, how to run and evidence a test, or when scripted testing is overkill. For a small team without a dedicated CSV department, that gap produces one of two failures: over-testing everything, or skipping testing and hoping.
This guide closes the gap on execution. It covers the validation assessment that scopes testing, the anatomy of a test script and its evidence, and the choice between scripted, unscripted, and automated testing, all through a risk-based lens. It stays out of the lifecycle theory (see the CSV hub), the document/protocol structure (see the CSV deliverables guide), and the FDA’s CSA guidance interpretation (see the CSV/CSA guidance guide); it touches CSA only as it changes test effort.
Where testing sits in CSV
Testing is the verification half of validation: the activity that produces objective evidence the system does what it is specified to do. It is executed through the IQ, OQ, and PQ stages. For the full lifecycle and where these sit in the V-model, see the CSV overview; here we go a level deeper into execution.
The validation assessment: deciding what to test before you write a single script
The most important CSV testing work happens before any script exists. A validation (risk) assessment decides what to test and how hard, so effort lands where it matters.
Risk-based scoping
Not all functions deserve equal testing. Both the EU and FDA frameworks make this explicit. EU Annex 11 ties the extent of validation, and therefore testing, to a justified and documented risk assessment of the computerised system (§ 1). The practical method: identify the system’s functions, assess each function’s risk to product quality, data integrity, and patient safety, and assign test rigor accordingly. High-risk functions (a calculation that affects a safety decision, an audit trail, access control) get rigorous, scripted testing. Low-risk functions (cosmetic features, rarely-used conveniences) get light testing or none, with the rationale documented. The output is a test plan that is defensible precisely because it is proportionate.
Leveraging vendor/supplier testing evidence instead of re-testing
You do not have to re-test what the vendor has already tested and evidenced. For standard commercial software, supplier qualification and the vendor’s own testing can provide assurance you would otherwise duplicate. The discipline is to assess the supplier (is their testing credible and documented?) and then focus your testing on your configuration and your intended use, rather than re-proving core functionality the supplier already validated. This is a major source of right-sized effort for a small team.
IQ / OQ / PQ as test-execution stages
Seen as execution rather than definitions, each stage proves something different:
- IQ proves the system is installed and configured as specified, you are verifying the environment is correct before testing behavior.
- OQ proves the system functions as specified across its operating range, this is where most functional test scripts run.
- PQ proves the system performs correctly in real intended use, often with real or representative workflows and data.
The risk assessment determines how much testing each stage gets for each function.
Anatomy of a test script and its executed evidence
A test script is the unit of CSV testing. Whether for OQ or PQ, it has a consistent structure.
Steps, inputs, expected vs. actual results, pass/fail, reviewer sign-off
A usable test-script skeleton:
| Element | What it holds |
|---|---|
| Test ID | Unique identifier, traceable to a requirement |
| Objective | What this test verifies |
| Prerequisites | System state, test data, accounts needed |
| Step | The action to perform |
| Input | The data or value entered |
| Expected result | What should happen (the acceptance criterion) |
| Actual result | What did happen (recorded during execution) |
| Pass / Fail | The verdict for that step |
| Evidence ref | Pointer to the screenshot or objective evidence |
| Executed by / date | Who ran it and when |
| Reviewed by / date | Independent review and sign-off |
The expected result must be defined before execution; deciding “what counts as pass” after seeing the actual result is a finding waiting to happen.
Handling deviations and objective evidence
Two execution disciplines matter most:
- Objective evidence. A “pass” is not credible on its own; capture evidence (a screenshot, a system printout, a report) that shows the actual result. The audit trail and system outputs are common evidence sources.
- Deviation handling. When actual does not match expected, that is a deviation, and it must be documented, assessed, and resolved (fix and re-test, or justify and accept), with sign-off. Unsigned or undocumented deviations are among the most common validation findings. A failed test honestly recorded and resolved is fine; a failure quietly overwritten is not.
Scripted vs. unscripted vs. automated testing, choosing per risk
You have three modes, and the right answer is usually a mix:
- Scripted testing follows pre-written steps with pre-defined expected results. It is rigorous, repeatable, and well-evidenced, the right choice for high-risk functions where you need a defensible, reproducible record.
- Unscripted (exploratory/ad hoc) testing lets a knowledgeable tester probe the system without a fixed script, recording what they did and found. It is efficient for lower-risk areas and for surfacing issues scripts would miss, and it is increasingly accepted for appropriate-risk functions. It still requires recorded evidence of what was tested.
- Automated testing runs tests by tool, valuable for repetitive, stable, or regression testing where the up-front automation cost pays off over many runs.
Choose per risk: scripted for the high-risk core, unscripted for lower-risk exploration, automated where repetition justifies it. Forcing exhaustive scripting onto everything is exactly the over-testing CSA pushes back on.
Computer system validation tools that support test execution and traceability
Tooling can carry the execution and evidence burden:
- Validation lifecycle / test-management tools manage test scripts, execution records, and evidence, and maintain the requirements-to-test traceability automatically.
- Automated testing tools execute and log repetitive tests.
- Electronic evidence capture records results and screenshots with attribution.
These tools support execution and traceability; they do not decide your risk-based scope, and no tool makes a team compliant. The assessment and the judgment remain yours.
How a risk-based / CSA mindset changes how much testing you do
The FDA’s Computer Software Assurance approach is, at its core, a testing-effort philosophy: a risk-based approach that establishes confidence in the software’s intended use, identifying where additional rigor is appropriate and describing methods and testing that provide objective evidence, scaled to risk (Computer Software Assurance). The effect on testing is direct: spend serious, scripted effort on high-impact functions, use lighter or unscripted approaches for low-impact ones, and lean on supplier evidence where credible. “Least-burdensome” is proportionate, not minimal, the goal is genuine assurance with effort matched to risk, not paperwork for its own sake. For the full CSA framing, see the CSV/CSA guidance guide; for testing, the takeaway is permission, and expectation, to stop testing everything equally.
Frequently asked questions
What is testing in CSV, and how does it relate to IQ/OQ/PQ? Testing is the verification activity that produces objective evidence a system meets its specifications, executed through the IQ (installation), OQ (function), and PQ (intended-use) stages.
What does a CSV test script contain? A test ID traceable to a requirement, objective, prerequisites, steps and inputs, pre-defined expected results, actual results, pass/fail, evidence references, and executor and reviewer sign-off.
How do you decide what to test? Through a validation (risk) assessment: assess each function’s risk to quality, data integrity, and patient safety, and assign test rigor accordingly, leveraging supplier evidence where credible.
Scripted, unscripted, or automated, when is each appropriate? Scripted for high-risk functions needing a defensible record, unscripted for lower-risk exploration, automated for repetitive or regression testing. Usually a mix, chosen by risk.
How does CSA change how much testing you do? It directs you to scale test effort to intended use and impact, spending rigor on high-risk functions and using lighter approaches elsewhere. Least-burdensome means proportionate, not minimal.
The bottom line
CSV testing is a risk-based execution decision, not a mandate to run every script. Start with a validation assessment that scopes testing to where the real risk is, leverage credible supplier evidence, then execute well-structured scripts with pre-defined acceptance criteria, captured evidence, and signed deviation handling. Choose scripted, unscripted, or automated testing per risk, and let the CSA mindset free you from testing everything equally, so your limited effort lands where it actually protects quality and patients.
Sources
Dejan Murko
Dejan is the co-founder of Mayet, building software for biotech and pharma teams.