Exploratory testing is an approach in which the tester designs, runs and evaluates tests at the same time, learning about the product as they go. It does not replace scripted tests or automation; it fills the gaps they leave: thin specifications, tight deadlines and defects nobody thought to write a scenario for.
Quick Overview
What you will learn:
- How the ISTQB syllabus defines exploratory testing
- How sessions, test charters and debriefings give it structure
- When a test script falls short, and when an automated test is the better tool
- Who on the team plans exploratory testing and who carries it out
Who this article is for:
- Testers and QA engineers
- Test managers and delivery team leads
- Product owners who act on test results
Reading time: 7 minutes
What ISTQB Means by Exploratory Testing
The ISTQB Certified Tester Foundation Level syllabus, published on www.istqb.org as v4.0.1 (an errata release of v4.0), groups exploratory testing with the experience-based techniques, alongside error guessing and checklist-based testing. Its definition is brief: tests are designed, executed and evaluated simultaneously while the tester learns about the test object. The point is to understand the product better, probe selected areas in more depth and create tests for the parts nobody has tested yet.
So exploratory testing is not aimless clicking. The tester has a goal and decides what to try next based on what they have just seen. The syllabus also notes that exploration can draw on formal techniques such as equivalence partitioning.
Where a Test Script Falls Short
A test script checks what someone anticipated when they wrote it. The ISTQB syllabus names three situations where exploration pays off:
- Thin or poor specifications: there is not enough to derive a complete set of test cases from.
- Heavy time pressure: writing a full set of scripts would take longer than the time left before release.
- Complementing more formal test techniques: exploration adds what the formal techniques leave out.
Outside the syllabus, in practice, scripts cover the requirements while exploration hunts for the defects in between.
The syllabus adds that on agile projects most manual testing relies on experience-based techniques, while extensive automation keeps regression testing manageable. That is a sensible division of labour: automated tests make sure nothing that used to work has broken, and an exploring tester looks for what nobody expected.
Brian Marick’s testing quadrants, covered in the syllabus on www.istqb.org, show the same split. Quadrant Q3 (business-facing tests that critique the product) holds exploratory testing, usability testing and user acceptance testing, which are often manual. Quadrant Q1, with component and component integration tests, should be automated and part of the CI process.
Giving Exploration Structure: Session-Based Testing
To make exploratory testing something you can plan and report on, the syllabus describes session-based testing:
- Time box: each session runs for a fixed, agreed length of time.
- Test charter: a short document listing the test objectives that steer the tester. The objectives work as high-level test conditions.
- Test session sheet: where the tester records the steps taken and what they found.
- Debriefing: after the session, the tester talks the results through with the stakeholders who care about them.
In the author’s experience, a good charter says what to explore, with what data and which risk to look for, without spelling out the steps. For example: “Explore importing an order file with unusual character encoding and very long product names, looking for data loss.” The tester keeps their freedom, and after the debriefing everyone knows what was covered and what is still open.
Tooling can take the friction out of capturing evidence. In Azure Test Plans, Microsoft’s Test & Feedback browser extension (documented on learn.microsoft.com) lets team members run exploratory tests, capture screenshots, notes and screen recordings, and file bugs from the same session.
Who Owns Exploratory Testing
The ISTQB syllabus (www.istqb.org) describes two main roles in testing. The test management role owns test planning, monitoring, control and completion. For exploratory testing, that means choosing the areas and risks to cover, handing out charters and time, and pulling together what the debriefings reveal. The testing role owns test analysis, design, implementation and execution, which is the session itself. On an agile team some of the management work moves to the team as a whole, and in the author’s practice it helps to have the product owner or a business analyst in the debriefing, because they decide what to do with the findings.
The syllabus stresses that exploratory testing is only as good as the tester: their experience, domain knowledge and skills such as analytical thinking, curiosity and creativity. Pairing experienced testers with newer ones and giving them time to learn the business domain is time well spent.
Read Also
- A Testing Strategy for Agile Projects: where testing fits into each iteration
- API Testing: Tools and Best Practices: what to automate at the interface level
- Contract Testing in a Microservices Architecture: keeping services compatible
Build Your Skills
Two trainings cover this topic: Effective Test Case Design and Agile Software Testing Overview. The first covers test design techniques, exploratory testing included; the second covers testing on agile projects, including exploratory testing techniques. Get in touch to tailor the scope to your team.
Frequently Asked Questions (FAQ)
What Types of Software Testing Are There?
The ISTQB syllabus splits test techniques into black-box (based on the specification), white-box (based on the code structure) and experience-based. The last group includes error guessing, exploratory testing and checklist-based testing. Separately, tests are grouped into levels, from component tests to acceptance tests, and into types such as functional and non-functional.
What Is ISTQB, and What Does It Say About Exploratory Testing?
ISTQB is the international body that publishes software testing syllabi and runs the tester certification scheme. Its Foundation Level syllabus treats exploratory testing as an experience-based technique, sometimes run as sessions with a charter and a debriefing, and especially useful when specifications are thin and time is short.
Does Test Automation Replace Exploratory Testing?
No. Automation is good at checking what can be described up front, regression above all. Exploratory testing looks for the defects nobody predicted and judges the product from the user’s point of view. In the testing quadrants model the two sit in different quadrants and complement each other.
What Is Manual Testing, and Is Exploratory Testing Part of It?
Manual testing is carried out by a person rather than a tool. It can be scripted, when the tester follows prepared steps, or exploratory, when the tester decides the next step based on what they observe. Exploratory testing is therefore one form of manual testing, and tools can support it, for example by recording sessions and filing bugs.