Testing

Writing Test Scripts That Don't Fail for the Wrong Reasons

Updated 2026-11-07

A surprising share of validation deviations are not caused by the system failing. They are caused by the test script: an ambiguous instruction, a vague expected result, missing evidence, a step a tester cannot follow the same way twice. Those deviations cost time to investigate and prove nothing about the software. This article is about writing scripts so that when a step fails, it fails because the system did something wrong — not because the script was poorly written.

It builds on IQ, OQ and PQ in depth; read that for the structure, this for the craft.

The anatomy of a good step

Every test step needs three things, defined before execution:

  1. A clear instruction — one action, unambiguous, that any trained tester performs identically.
  2. An objective expected result — a specific outcome you could score pass/fail without judgement.
  3. The evidence to capture — stated up front, so the record is consistent and complete.

If a tester has to interpret what you meant, or decide for themselves what “correct” looks like, the script is not finished.

Kill the phrase “works as expected”

“Verify the system works as expected” is the single most common weakness in test scripts. Expected by whom? Measured how? Replace it, every time, with a concrete criterion:

  • Not “verify the calculation is correct” → “verify the displayed total equals 15.00 g (the sum of 5.00, 5.00 and 5.00 g)”.
  • Not “confirm access works” → “confirm the Analyst role receives a permission-denied message and no record is deleted”.
  • Not “check the report looks right” → “confirm the report shows all three samples, each with analyst name, date and result to two decimal places”.

The test: could two different people run your step and reach the same verdict? If not, tighten it.

State the evidence before you run

Deciding what evidence to capture after execution leads to inconsistent, incomplete records. Name it in the script: “screenshot of the About dialog”, “export of the audit trail entries”, “printout of the report”. The person executing then knows exactly what to attach, and the record holds up on review.

Design the data in advance

Many “failures” come from vague or unsuitable test data. Define the inputs in the script, including the awkward ones — the boundary values, the invalid entries, the empty field — so you test at the edges where real defects hide, not just comfortable mid-range values. For a limit of 0–220 g, test 0, 220 and 221, not just 100.

Separate a defect from a script error

When a step fails, the first question is why. A genuine system defect is a real finding and goes through the deviation and resolution process. A script error — a typo in the expected value, an instruction that does not match the configured system — is fixed in the script under control, with the correction documented. Either way you do not quietly edit and silently re-run; see the discipline around failed steps in IQ, OQ and PQ in depth.

Plan for fallbacks

Risk-proportionate testing also means thinking ahead about the step that might not go cleanly and deciding, in advance, what an acceptable outcome and fallback looks like — rather than discovering mid-execution that the expected result was unachievable and raising a deviation that fixes nothing. Effort during execution should go into catching real quality issues, not into paperwork caused by a script that was never executable as written.

A quick checklist

Before a script is approved, ask of every step:

  • One clear action?
  • An objective, pre-defined expected result — no “as expected”?
  • Evidence named?
  • Test data defined, including boundaries and invalid cases?
  • Could a stranger execute it and reach the same verdict?

If every step passes that, your execution will test the system, not the script.

Next