This is a ready-to-use record for an unscripted or exploratory GxP test session. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control, review, and approval. A worked filled specimen follows the template. This is general guidance to adapt, not regulatory advice; verify each cited regulation against the current source before you rely on it.
What this record is, and is not
An unscripted or exploratory test session is not testing without documentation. A tester with real expertise exercises a feature against a stated objective, working from judgment rather than a predefined script, and records what was tried, what was found, and the conclusion, contemporaneously. GAMP 5 Second Edition and FDA’s Computer Software Assurance guidance both accept this method for lower-risk features precisely because a purposeful written record substitutes for predefined steps, not for a record at all. A one-line note reading “feature worked fine” is not this record; it is the absence of one wearing this record’s name.
This record is the execution counterpart to a CSA-aligned test plan. The plan decides which features get this treatment and why; this record is what the tester actually produces when they run the session. It sits next to scripted test scripts as an equally real, equally reviewable artifact, just lighter in structure because the risk it covers is lighter.
Document control header
| Field | Entry |
|---|---|
| Record title | Unscripted / Exploratory Test Session |
| Record number | <<FILL: e.g. ETS-LIMS-014>> |
| Parent test plan | <<FILL: TP-ID>> |
| Linked risk assessment (feature risk basis) | <<FILL: RA-ID>> |
| System name / ID | <<FILL: SYSTEM NAME / ID>> |
| Software version / build tested | <<FILL>> |
| Test environment | <<FILL: validation / staging environment, not production>> |
| Session date(s) | <<FILL>> |
| Tester | <<FILL: name, role>> |
1. Session charter
State the objective before the session starts, not afterward. A charter with no stated objective cannot be distinguished from casual use of the system, and a reviewer cannot tell whether the tester was looking for anything in particular.
| Field | Entry |
|---|---|
| Feature(s) in scope | <<FILL>> |
| Intended use of the feature | <<FILL>> |
| Risk classification and basis | <<FILL: Low / Low-Medium, per linked risk assessment>> |
| Charter (what the tester is looking for) | <<FILL: one or two sentences, for example "confirm the sample list filter and column sort behave correctly across the range of test data in use, and note anything that looks wrong even if not explicitly specified">> |
| Time box | <<FILL: planned duration>> |
| Data used | <<FILL: test data set / record IDs>> |
2. Session log
Record what was actually exercised, in the order it happened, as the session runs, not reconstructed afterward. Note any idea that led to a further check, not only the checks themselves; exploratory testing is allowed to follow a lead the charter did not anticipate, and that is where it earns its keep over a fixed script.
| Time | What was tried | What was observed | Follow-up idea (if any) |
|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
3. Findings
Every finding carries a severity and a disposition, exactly as a scripted test failure would. Exploratory testing is a lighter execution method, not a lighter finding-management standard.
| Finding ID | What was found | Severity | Requirement or expectation affected | Disposition | Closed |
|---|---|---|---|---|---|
<<FILL>> | <<FILL>> | Critical / Major / Minor / Observation | <<FILL>> | <<FILL: defect raised, accepted with rationale, requirement clarified>> | <<FILL>> |
Severity follows the same scale as scripted testing on this site: a Critical or Major finding blocks the session’s conclusion until it is dispositioned; a Minor finding can be scheduled with an owner; an Observation needs no action but stays on record.
4. Evidence captured
Capture evidence for every finding, and for enough of the session that a reviewer can reconstruct what was covered without re-running it themselves.
| Evidence ref | Description | Linked to (time entry or finding ID) | Storage location |
|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
5. Tester conclusion
Select one, and support it with a written statement. A checkbox alone is not a conclusion.
| Conclusion | Selected |
|---|---|
| Feature met expectations for its intended use; no findings raised | <<FILL>> |
| Feature met expectations; findings raised and dispositioned per section 3 | <<FILL>> |
| Feature did not meet expectations; session paused pending correction | <<FILL>> |
Tester statement: <<FILL: two to three sentences stating what was explored, what was found, and the basis for the conclusion>>
6. Review
Exploratory sessions on genuinely low-risk features do not require the independent, did-not-execute review that a scripted test on a direct-impact function requires; that level of oversight would be effort spent where the risk does not justify it. Quality Assurance still confirms that the session record is complete, that the charter matches the risk classification in the linked risk assessment, and that any Critical or Major finding was actually dispositioned, not left open under a passing conclusion.
| Role | Name | Signature | Date |
|---|---|---|---|
| Tester | <<FILL>> | ||
| QA reviewer (record completeness, not re-execution) | <<FILL>> |
7. Acceptance criteria
A session record is acceptable when all of the following are true:
- The charter states an objective before execution, and the objective is consistent with the risk classification in the linked risk assessment.
- The session log shows what was actually exercised, not a restatement of the charter.
- Every finding carries a severity and a disposition; no finding is left open with the session marked complete.
- Evidence is captured for any finding and for enough of the session to reconstruct what was tested.
- The tester’s conclusion is one of the three defined outcomes, supported by a written statement.
- Quality Assurance has reviewed the record for completeness and consistency with the risk basis.
8. References
FDA Guidance, Computer Software Assurance for Production and Quality Management System Software (issued 3 February 2026, superseding the 24 September 2025 final version). ISPE GAMP 5, Second Edition, A Risk-Based Approach to Compliant GxP Computerized Systems. 21 CFR Part 11 (electronic records and signatures), for features that are Part 11 in scope. EU GMP Annex 11 (Computerised Systems). ICH Q9(R1), Quality Risk Management, for the risk basis that justifies unscripted testing.
Confirm the current version of each reference before issue.
9. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
Filled specimen
The following shows the record completed for an exploratory session on a low-risk feature of a configured LIMS: the sample list filter, column sort, and column layout used by analysts to find and arrange their own work queue. The system, tester, and findings are illustrative; replace them with your own.
Header (extract)
| Field | Entry |
|---|---|
| Record number | ETS-LIMS-014 |
| Parent test plan | TP-CSV-021 |
| Linked risk assessment | RA-LIMS-006, feature rated Low: no GxP decision, record integrity, or release outcome depends on filter, sort, or layout state |
| System | LIMS-PROD, build 8.2.1 |
| Test environment | LIMS-VAL (validation instance), not production |
| Session date | 11 June 2026, 0900 to 1015 |
| Tester | A. Patel, Validation Analyst |
Session charter
Feature in scope: sample list filter, column sort, and column layout on the analyst work queue screen. Intended use: lets an analyst find and order the samples assigned to them; does not change any result, specification, or approval state. Charter: confirm filtering by status, method, and date range returns the correct sample set against the loaded test data, confirm sort behaves correctly ascending and descending on each sortable column, and note anything that looks wrong even outside those specific checks. Time box: 75 minutes. Data used: test data set TD-LIMS-014 (42 samples across five statuses, three methods, a two-month date spread).
Session log (excerpt)
| Time | What was tried | What was observed | Follow-up idea |
|---|---|---|---|
| 0902 | Filtered by status “In Progress” | Returned 11 samples; manually counted 11 in TD-LIMS-014 with that status. Correct. | |
| 0911 | Filtered by date range spanning the full two months | Returned all 42 samples. Correct. | |
| 0919 | Filtered by date range covering only the first two weeks | Returned 9 samples; the source data has 11 samples logged in that window. | Check whether the filter uses login date or received date; the two differ for 2 samples in the set. |
| 0927 | Followed up: compared the 2 missing samples’ received date vs login date | Both missing samples were received in the window but logged two days later, outside it. Filter uses login date silently, with no field label indicating which date it filters on. | Raise as a finding: not wrong behavior, but unlabeled and could mislead an analyst searching by receipt date. |
| 0941 | Sorted the result column descending | Sorted correctly by numeric magnitude, including values with different decimal places. Correct. | |
| 0954 | Sorted the sample ID column ascending with a mixed alphanumeric ID set | IDs sorted as plain text (S-2 appeared after S-19), not in the numeric-aware order an analyst would expect. | Raise as a finding. |
| 1005 | Added and removed columns from the layout, saved, logged out and back in | Layout preference persisted correctly across the session restart. Correct. |
Findings
| Finding ID | What was found | Severity | Expectation affected | Disposition | Closed |
|---|---|---|---|---|---|
| F-01 | Date-range filter uses login date with no field label distinguishing it from received date, which can silently exclude samples an analyst expects to see | Minor | Usability, not a GxP decision or data-integrity control | Configuration change requested to label the field “Login date range”; scheduled with system owner, no impact to prior data | Target 25 June 2026 |
| F-02 | Sample ID column sorts as plain text rather than numeric-aware, so IDs do not sort in the order an analyst expects | Observation | No requirement specified sort order beyond “correct sort”; behavior is consistent, just not intuitive | Logged for the next configuration review; not a defect against any written requirement | N/A |
Evidence
| Evidence ref | Description | Linked to | Storage location |
|---|---|---|---|
| SES-014-01 | Screenshot, date-range filter result set with the two out-of-window samples highlighted | 0919 to 0927 entries, F-01 | Validation evidence share, ETS-LIMS-014 folder |
| SES-014-02 | Screenshot, sample ID column sorted ascending showing text-order result | 0954 entry, F-02 | Validation evidence share, ETS-LIMS-014 folder |
Tester conclusion
Selected: feature met expectations; findings raised and dispositioned per section 3.
Tester statement: I exercised the filter, sort, and column layout functions of the analyst work queue against test data set TD-LIMS-014 for 75 minutes, following the charter and one lead that emerged during the session. Filtering and sorting returned correct results in every case except the two noted findings, neither of which affects a GxP decision, a record, or a release outcome. F-01 is a usability gap worth fixing; F-02 is a design choice worth noting but not a defect against a written requirement. The feature is fit for its intended use as a work-queue aid.
Review
QA reviewer confirmed the charter matched RA-LIMS-006’s Low risk classification, the session log showed genuine exploration rather than a restated charter, and both findings were dispositioned with an owner. QA did not re-execute the session.
| Role | Name | Date |
|---|---|---|
| Tester | A. Patel, signed | 11 June 2026 |
| QA reviewer | S. Lin, signed | 12 June 2026 |
The line worth noticing is F-01. Nothing in the charter asked the tester to compare login date against received date; that check came from following a discrepancy the tester noticed while doing the planned filter check. That is exploratory testing doing what a fixed script cannot: finding the thing nobody thought to write a step for, in a feature genuinely too low-risk to justify the cost of writing one.
Common inspection findings this record prevents
- “Exploratory testing was performed” claimed with nothing on file showing what was actually tried or found.
- A session record that restates the charter as the outcome, with no evidence the tester actually exercised the feature.
- A finding discovered during exploratory testing that is never logged, disposition, or fixed, because there was no structured place to put it.
- Unscripted testing applied to a feature that should have carried scripted rigor, audit trail, e-signature, or access control, because “unscripted” was read as “less oversight” rather than “different method matched to lower risk.”
- A session record with no reviewer signature, so nobody outside the tester ever confirmed the record was complete.
- A charter written after the session, reverse-engineered to match whatever was found, rather than stated in advance.
How to adapt this record
- Set your record number, parent test plan, and linked risk assessment reference in the header. This record only stands up when it is clearly tied to a documented risk classification that justified the lighter method.
- Reserve this record for features the linked risk assessment actually scored Low or Low-to-Medium. Reject the temptation to use it for a High-severity function because a scripted script would take longer to write; see the GAMP 5 framework article for the severity-and-detectability override that keeps audit trail, e-signature, and access control on scripted rigor regardless of overall system risk.
- Keep the session log genuinely chronological. A log written from memory after the session reads differently from one written as the session happens, and a reviewer can usually tell.
- Do not skip section 6 review because the method is lighter. QA still confirms the record is complete and the findings were closed; that confirmation is what makes the record usable evidence rather than a personal note.
- Where your test plan already defines a written record type for exploratory sessions, point this record at that definition so the two stay consistent; see the CSA-aligned test plan this record is built to execute.