This is a ready-to-use test protocol for a single GxP RPA bot. Approve it before execution, record actual results and evidence at execution, and handle any test failure as a documented deviation. Replace every <<FILL: ...>> placeholder. Worked test cases and a filled specimen follow. This content is educational reference, not legal or regulatory advice; verify each cited regulation against the current source.
Approval page (pre-execution)
| Role | Name | Signature | Date |
|---|---|---|---|
| Author (Validation / CSV) | <<FILL>> | ||
| RPA developer | <<FILL>> | ||
| Quality Assurance | <<FILL>> |
| Field | Entry |
|---|---|
| Protocol number | <<FILL: PROT-ID, e.g. VAL-RPA-012-T1>> |
| Automation / version | <<FILL: bot name and version>> |
| Parent plan | <<FILL: assurance plan ID>> |
| Risk level (from plan) | <<FILL: Low / Medium / High>> |
1. Objective and scope
Verify that the named bot meets its requirements and does not break the integrity of the records it touches, at a test depth proportionate to its risk level. Scope covers the intended-use boundary in the parent plan and the RPA-specific failure modes below.
2. Prerequisites
- Approved requirements (URS) and configuration specification are available.
- Test environment mirrors production selectors and the target-system versions.
- Test data and test accounts are prepared, including records that force each exception.
- The bot’s service account, credential vault entry, and least-privilege permissions are configured.
- Traceability matrix (requirement to test case) is drafted.
3. Acceptance criteria
- Every requirement traces to at least one executed test with a recorded result.
- Happy-path accuracy is 100 percent on the representative dataset.
- The read-back verification control was proven to fire on a deliberate mismatch.
- Every exception path stops the bot and routes to a human; the bot never guesses or skips silently.
- The target-system audit trail attributes actions to the bot identity, not a person.
- No test failure remains open; any failure is investigated and closed with rationale.
4. Test cases
Execute the cases applicable to the risk level. Boundary, exception, read-back, attributability, and negative cases are mandatory regardless of risk band.
| Test ID | Type | Requirement(s) | Steps (summary) | Expected result | Actual | P/F | Tester / date | Evidence |
|---|---|---|---|---|---|---|---|---|
<<FILL: TC-01>> | Happy-path accuracy | <<FILL>> | Run representative records end to end; compare every written value to source | All written values equal source; 100 percent match | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL: TC-02>> | Boundary / format | <<FILL>> | Feed blank, max length, special chars, unexpected decimals, leading zeros, boundary dates | Bot handles or halts as specified; no silent reformat | <<FILL>> | |||
<<FILL: TC-03>> | Exception handling | <<FILL>> | Force source down, target locked, missing field, unexpected pop-up, login expiry | Bot stops, logs exception with context, routes to human | <<FILL>> | |||
<<FILL: TC-04>> | Read-back verification | <<FILL>> | Seed a deliberate mismatch between written and source value | Built-in check fails and the bot halts / flags | <<FILL>> | |||
<<FILL: TC-05>> | Concurrency / volume | <<FILL>> | Run at production volume and parallelism | No dropped, duplicated, or mis-timed transactions | <<FILL>> | |||
<<FILL: TC-06>> | Attributability | <<FILL>> | Inspect target audit trail after a run | Actions attributed to the bot service account, complete and timestamped | <<FILL>> | |||
<<FILL: TC-07>> | Negative / must-not | <<FILL>> | Attempt to make the bot modify a source record | Bot cannot and does not modify the source | <<FILL>> |
5. Deviation handling
Any Fail or unexpected result during execution is recorded as a test deviation with the observed behavior, an impact assessment, disposition (retest after fix, or accept with rationale), and QA approval. Do not overwrite the original recorded actual result.
6. Summary and conclusion (post-execution)
| Field | Entry |
|---|---|
| Tests executed / passed | <<FILL>> |
| Deviations raised / closed | <<FILL>> |
| Requirements coverage | <<FILL: all traced and executed? Y/N>> |
| Conclusion | <<FILL: bot meets requirements and acceptance criteria / does not>> |
| Residual risk and conditions of use | <<FILL>> |
| Role | Name | Signature | Date |
|---|---|---|---|
| Executed by | <<FILL>> | ||
| Reviewed by (CSV) | <<FILL>> | ||
| Approved by (QA) | <<FILL>> |
Worked test case (the level of detail an auditor expects)
Test ID: RPA-TC-04, Read-back verification Requirement traced: REQ-021 (bot shall read back the written value and halt on mismatch) Pre-condition: A LIMS sample with a known result; the bot configured with read-back enabled; a seeded fault that forces the written value to differ from source by one digit. Steps: 1) Trigger the bot against the sample. 2) Allow it to write to the register. 3) Observe the read-back comparison. 4) Inspect the exception queue and the register row. Expected result: The read-back detects the mismatch; the bot halts before the row is committed for use, or flags and quarantines the row; an exception is logged with sample ID, timestamp, and reason “read-back mismatch”; item routed to the analyst queue; no unverified value left usable. Actual result: [recorded at execution] Pass/Fail: [recorded] Evidence: screenshot of the exception entry; export of the register showing the row quarantined.
A control you have never watched fail is not a proven control. RPA-TC-04 exists precisely to make the read-back check fire once, on purpose.
Filled specimen (execution summary)
| Field | Entry |
|---|---|
| Automation | LIMS-to-stability-register transcription bot v1.0 |
| Risk level | Medium |
| Tests executed / passed | 7 / 7 |
| Deviations | 1 raised (TC-02 mis-handled a leading zero), fixed, retested, closed |
| Requirements coverage | All 14 requirements traced and executed |
| Conclusion | Bot meets requirements and acceptance criteria |
| Conditions of use | Valid only while an analyst 100 percent-verifies written rows before the register is used |
The single deviation is the useful part of the record: a leading-zero mis-format is exactly the silent RPA failure boundary testing is meant to catch, and catching it in test rather than in a released record is the point.
Common inspection findings this protocol prevents
- Validation evidence that is all happy path, with no boundary, exception, or read-back-failure tests.
- A read-back control claimed but never demonstrated to fire.
- Exceptions that the bot swallows silently, producing wrong records with no trail.
- Bot actions in the target audit trail attributed to a named person.
- Test failures closed with no documented investigation.
How to adapt this protocol
- Fill the requirement references so every test traces back to the URS.
- Prepare test data that forces each exception; you cannot test exception handling without records that trigger it.
- Keep the mandatory RPA-specific cases even for a low-risk bot; they target the failure modes RPA is prone to.
- Record actual results at execution and never overwrite them; corrections go through the deviation mechanism.
- Carry the conditions of use into the summary report and the bot register.