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.