Risk-Based Testing

Scripted testing

Use a controlled sequence when exact preconditions, input values, expected results, and comparison are important. Examples include expiry at a defined time boundary, an acceptance calculation, or a signature remaining connected to an approved revision.

Completed test example — fictional: Input a result of 10.004 where the approved rule specifies comparison using the unrounded result against an upper limit of 10.000. Expected: unacceptable. A display rounded to 10.00 must not change the underlying decision. The approved specification must define this behavior; a tester must not invent a rounding rule during execution.

Exploratory testing

The tester learns about the system while designing and executing checks within a defined purpose. A useful charter states the scope, risks, starting conditions, and evidence to retain. Record what was explored and what was discovered.

Example charter: “Explore the CAPA reassignment workflow with active, inactive, and unauthorized users. Look for ways an item can lose ownership or bypass escalation. Record tested role combinations, relevant state transitions, findings, and evidence references.”

Exploratory testing is not an undocumented browsing session. It can expose combinations a rigid script did not anticipate. It may be combined with precise follow-up scripts for discovered failures.

Ad hoc checks

A focused check may answer an immediate narrow question, such as whether a corrected label is visible in the affected view. Capture its purpose, version, activity, result, and conclusion as appropriate to the decision. Use your organization’s terminology consistently; do not relabel a weak test to make it appear more rigorous.

Automated testing

Automation helps repeat checks and examine larger input sets. Its usefulness depends on the expected result, coverage, environment, and failure reporting. A test that only checks whether an API returns HTTP 200 may pass even when the wrong lot status is returned.

Example: For a LIMS interface, compare sample ID, analyte, value, units, specification version, status, and transaction identity. Challenge duplicate messages, reordered messages, and invalid values. Retain enough output to explain individual failures.

Negative and boundary testing

Negative tests challenge what should be rejected or prevented. Boundary tests examine where behavior changes. Examples include an unauthorized approval, a missing required field, an exact specification limit, an expired certificate, or the transition from one effective procedure revision to the next.

Evidence that helps another reviewer

Record the system/configuration, tested use, test conditions, expected outcome, actual outcome, relevant observations, exceptions, and conclusion. Reference machine logs, data comparisons, or screenshots where they help substantiate the result. A screenshot is useful when it shows something important; it is not a substitute for a meaningful test.

Handle failures without rewriting history

Preserve the observed failure. Assess the cause and impact. Record the correction, required retesting, and any broader regression need. If the expected result was wrong, explain and approve its correction through the applicable process. Do not silently convert a failure to a pass.

Exercise: All 400 automated checks passed, but none evaluates whether the correct approver received the task. Is CAPA routing supported?

Answer: The pass count does not answer that question. Add or identify evidence that tests routing against the approved rules, including exception paths.

Map the test strategy to IQ, OQ, PQ, and UAT

Traditional labels can still be useful. IQ confirms that the approved environment, version, components, and configuration are installed or provisioned as intended. OQ challenges functional controls and defined operating ranges. PQ or UAT demonstrates that trained users can perform the approved process with representative data and procedures. A protocol may combine these activities when that is clearer. Record prerequisites, test data, expected and actual results, objective evidence, tester, date, deviations, retest, and approval. Link critical tests to the URS, FRA, and RTM.

Choose testing by asking what you still need to learn. This method considers failure consequence, complexity and variability, existing evidence, and the need for precise reproducibility.

Worked selection

These activities can be combined. Exploratory work can discover a failure that becomes a scripted regression test. Automation can execute a precise test repeatedly but still use a poor expected result.

Completed rationale — fictional

Routing rules require controlled comparisons for each approved decision branch and relevant invalid inputs. Exploratory testing will examine reassignment and cancellation interactions. Existing engine tests support standard transition mechanics. Local evidence will address configured roles and rules. The approach will be revised if new dependencies emerge.

Reusable worksheet

State the uncertainty, failure, consequence, existing evidence, proposed activity, expected-result basis, coverage, retained evidence, limitations, and acceptance decision.

Common mistake: “The function is lower risk, so no record is needed.” Even a narrow validation decision needs an appropriate basis. The record may be concise, but it should explain what supports the conclusion.