Exploratory Testing¶
Automated tests are essential — but they can only catch what you tell them to look for. Exploratory testing is how we find what we did not think to specify: the unexpected behaviour, the usability issue, the edge case that only becomes obvious when a real person navigates through the application with intent.
At CDS, exploratory testing is a disciplined, structured activity — not a synonym for clicking around. It complements the automated suite rather than substituting for it.
What exploratory testing is¶
Exploratory testing means simultaneously designing and executing tests based on what you discover as you go. Unlike scripted testing — where test cases are defined upfront and followed step by step — exploratory testing uses the tester's skill, curiosity, and experience to investigate the system.
It is most effective at finding:
- Edge cases that scripted tests were never designed to reach
- Usability and UX issues that automation cannot assess
- Inconsistent behaviour across flows that look unrelated on paper
- Failures that only emerge from realistic, non-linear user journeys
- Risks in areas that are under-specified or recently changed
How we run exploratory testing sessions¶
Charter-based¶
Every exploratory testing session at CDS is charter-based. A charter defines the focus and goal of the session before it starts — for example:
"Explore the checkout flow under different payment methods to identify edge cases and error handling gaps."
A good charter is specific enough to focus the session but broad enough to allow discovery. It prevents sessions drifting into unfocused clicking while still leaving room for the tester to follow their instincts.
Time-boxed¶
Sessions are time-boxed — typically 60 to 90 minutes. This keeps exploratory testing a regular, manageable practice rather than an open-ended activity that expands to fill available time. Multiple shorter sessions across a sprint are more effective than one long session before release.
Documented findings¶
Findings from each session are categorised and documented:
- Bug — a confirmed defect, raised as a bug work item in Azure DevOps and linked to the session
- Observation — something worth noting that may not be a defect: a usability concern, an inconsistency, or unexpected behaviour that warrants team discussion
- Risk — an area that could not be fully explored in this session but warrants further investigation
The session itself — including the charter, areas covered, findings, and areas not covered — is recorded as a task in Azure DevOps, linked to the relevant story and any bugs raised. This creates a traceable record of exploratory testing activity alongside the rest of the delivery work.
The relationship with automation¶
Exploratory testing and automation are complementary, not competing:
- Automation handles the repetitive, the predictable, and the high-volume — regression checks, pipeline validation, known risk areas
- Exploratory testing handles the novel, the ambiguous, and the human — what the application feels like to use, where the unexpected corners are, what scripted tests would never reach
A strong testing strategy uses both. Automation gives the team continuous, fast feedback on what is known. Exploratory testing gives skilled testers the space to find what is not yet known. Neither replaces the other.
Cadence¶
Exploratory testing sessions are agreed with the team at the start of an engagement and scheduled throughout delivery — not saved for a pre-release testing phase. The appropriate frequency depends on the pace of change and the risk profile of the work in each sprint.
Where a sprint introduces significant new functionality or changes to high-risk areas, exploratory testing should be prioritised accordingly.