Version 2.0 · Updated 2026-09-21 · Testing
Define the purpose, scope, risks, and evidence to capture during exploratory testing.
Adapt this template to your intended use, applicable requirements, and approved procedures.
When to use it
Exploratory testing is suitable but needs a clear purpose and record.
- Approved intended use and functional-risk assessment
- Available supplier and local evidence
- Test environment, representative data and competent reviewers
Field instructions
- Charter: State the exploratory objective, important risk and questions the session should investigate. Define the session boundary.
- Configuration: Record the tested application, tenant, version and local rule/configuration identifiers so observations can be reproduced.
- Scope: List included functions, users and record states, and identify the paths outside this session.
- Risks: Identify credible failures that the session should challenge, with their potential effects on the process or record.
- Starting conditions: Record the initial data, user roles, system state and setup required before exploration begins.
- Activities: Describe the planned interactions and challenges. During execution, record what was actually explored and any changes to the plan.
- Evidence: Identify attributable observations, data and record IDs, logs and relevant captures needed for another reviewer to understand the results.
- Findings: Record observed behavior, important coverage and anomalies contemporaneously. Distinguish observations from interpretations and link defect records.
- Follow-up: Assign each unresolved finding or additional check to an owner and due date; state the completion evidence required.
- Conclusion: Record the supported decision, restrictions, unresolved issues and rationale. Identify the accountable reviewer/approver and dated evidence under your procedure.
Could a reviewer understand the coverage and findings without watching the session? Do not invent a pass/fail history after the fact.
Completed fictional example
Fictional teaching example; replace its values with your own assessed facts and evidence.
Blank template
System / record ID: ____________________
Prepared by / date: ____________________
Required review / approval under local procedure: ____________________
Relevant regulations and guidance
These sources apply within their stated scope. The suggested worksheet fields, test designs and fictional decisions are practitioner recommendations, unless a source requirement is expressly identified. Completing a template does not establish compliance.
Regulatory guidance / GMP guideline · United States · February 2026
Scope: Medical-device manufacturers assuring software used in production or their quality management system.
Relevance: For medical-device production or QMS software, supports selecting assurance activities from intended use, risk and available evidence. It is nonbinding guidance and does not determine other sectors’ obligations.
Status: Final / published · Checked 2026-09-21
Publication identity, scope and status checked against the linked official source. This is not an independent audit of every retained guide statement.
Read source details and applicability →Regulatory guidance / GMP guideline · European Union · January 2011 revision
Scope: Computerised systems supporting activities in the applicable EU pharmaceutical GMP context.
Relevance: For computerised systems used in EU GMP activities, informs lifecycle, supplier and record controls. Confirm applicability to the actual activity; the example does not establish it.
Status: Final / published · Checked 2026-09-21
The Commission index confirms the January 2011 operative revision. The linked PDF could not be retrieved in this check; retained detailed section mappings need review against an authorized copy.
Read source details and applicability →