This guidelines are part of the Test Writing Guidelines.
Exploratory tests are a form of manual test driven by a charter with a clear mission, enabling simultaneous learning, test design, and execution by an expert tester.
The charter consists of sections that guide the charter. Currently, coordinators can fill in these sections: Instructions, Focus On, and Out of Scope. During execution, testers fill in a paragraph text field with coverage notes and observations.
When To Use Exploratory Tests
Use exploratory tests in scenarios where flexibility and creativity are essential. Exploratory testing allows testers to investigate and learn the system under test, uncover unexpected issues, and adapt their approach based on observation. Such scenarios include:
Early development stages, when requirements and test cases are incomplete or evolving
Complex features where it’s too expensive to cover edge cases with predefined scripts
Testing non-deterministic (AI-powered) systems
More broadly, exploratory tests are a good fit for:
Evolving requirements – when project requirements are unclear, incomplete, or frequently changing, exploratory testing allows testers to adapt dynamically and uncover issues that scripted tests might miss.
Time-constrained scenarios where test case writing would become an overhead.
Expanding coverage on new features (a set of a scripted, structured exploratory, and exploratory tests provides a layered approach for additional confidence in coverage).
When Not To Use Exploratory Tests
When creating tests that could potentially be automated.
When we need a detailed track record of coverage with a pass/fail outcome.
Creating Exploratory Tests
Use metadata as with other tests, for example by starting the name with [Exploratory].
Mission Statement
Each exploratory test should start with an info step that describes the test’s mission statement. The mission statement defines the goal with the following pattern:
Explore [what] (in order) to [achieve the outcome]
Example mission statements:
Explore the purchase flow to identify any data inconsistency issues
Explore all IVR features to ensure that each menu option triggers the correct prompt and routes calls
Explore the sign-up feature to validate that new users can complete registration and receive account access without errors
Explore the guest user experience to confirm that all available features function properly without errors or restrictions
Explore the new Assets enhancement to confirm that recent updates correctly display asset information, preserve existing data, and allow interaction with previous asset-related features
Exploratory Steps
Each action that happens within an exploratory test should be timeboxed to 15–30 minutes. Not less than 15 minutes, because testers need time to read the instructions, understand the feature, and explore the key flows. Not more than 30 minutes, because longer steps can lead to information overload, increasing the risk that testers may lose focus or miss important flows.
Note: The constraint for 30 minutes comes from realities of test execution with freelancers. You can change it when tests are executed by Dedicated Temporary Contractors rather than the freelance community.
If you expect the exploratory testing to take longer than 30 minutes, break it into smaller, manageable steps, where each test step is designed to be completed in 15–30 minutes. In general, a test case should not contain more than 2–3 steps. If it does, it is a sign that the scope is too big and you should split it into separate tests. Remember that all steps must remain aligned with the test’s mission statement.
This approach helps testers stay focused and ensures that all areas are covered.
Example: "Explore purchase flow to discover data inconsistency issues"
Break this into separate test steps based on different entry points into the purchase flow:
Explore the “Buy Now” flow
Search → Add to Cart → Checkout
Modify or update an existing order
This structure ensures that each case is focused, manageable, and fully aligned with the mission, while avoiding overly long or complex test cases.
Exploratory Step Name
Name each exploratory step with this pattern:
Description of the test step/Short summary of the focus areas/feature (X minutes)
Example: Character creation from 'Create' flow (20 minutes)
Add the test duration so testers know how much time to dedicate to exploration.
Exploratory Step Structure
Each exploratory step should be structured in the same way, with three sections.
Instructions (Prerequisites)
If the test must start from a specific state or page within the application, clearly describe how to reach the necessary state in the Instructions section of the exploratory step.
Include any actions needed to access the feature under test. Specify any required login details, user roles, or special permissions needed to perform the test.
Keep in mind that the test case specifies net testing time, so any extensive setup effort should be accounted for and reflected appropriately when estimating or planning the exploratory testing duration.
Focus on (In scope)
Clearly outline the testing scope and highlight where testers should direct their testing efforts. Use this section to outline:
Key features to test
Relevant scenarios or workflows
High risk areas that need attention
This section should help testers understand the intent of the test, maintain focus, and explore the expected areas effectively within the set timeframe.
Highlight key testing areas/scope, up to 4 main points.
Avoid listing too many testing areas; prioritize key areas that can be realistically explored in the given time.
If you feel the need to list more than 4 points, consider splitting into separate steps.
Out of scope
Mention any features, functionalities, or parts of the application that should not be tested, including any specific account/user types that are excluded from the current testing scope.
Include already-known issues that you don’t want testers to spend time on.
Do not repeat general testing limitations already documented elsewhere (such as the run instructions), to keep the test easy to follow and reduce maintenance overhead.
If there are no limitations (including limitations provided in the run instructions), explicitly state: “Everything is in scope.”
Additional Guidelines
Consider using video instructions with visual aids (such as screen recordings) when giving an introduction of the feature under test.
If not provided in the workspace, guide testers to the Support Center article on capturing exploratory test results.
In order to review Exploratory Testing Results, follow this guide: Review Exploratory Testing Results