Exploratory Testing: A Practical Guide

Exploratory testing is an experience-based approach in which a tester learns about a system while designing, executing, and evaluating tests. Each observation informs what to investigate next. It is purposeful investigation, not unstructured clicking.

Use a goal to focus a session, adapt your tests as you learn, and record observations and evidence as you go. A charter and a timebox help many teams, but neither is a requirement of exploratory testing itself. The [ISO/IEC/IEEE 29119-1:2022 definition](https://www.iso.org/obp/ui?_escaped_fragment_=iso%3Astd%3Aiso-iec-ieee%3A29119%3A-1%3Aed-2%3Av1%3Aen) describes it as experience-based testing in which the tester designs and executes tests using relevant knowledge, previous exploration, and heuristics.

What exploratory testing means

Exploratory testing combines three activities:

• Learning: finding out how the system behaves and what matters to its users.
• Test design: choosing a useful next probe based on knowledge, risks, and what earlier steps revealed.
• Execution and evaluation: interacting with the software, comparing its behavior with expectations, and interpreting the result.

These activities happen together in a feedback loop. A tester might begin by investigating checkout, notice that changing the delivery address resets a discount, and then probe how that behaves with an expired code, a saved cart, and a slow connection. The next test comes from the finding, rather than from a complete script written in advance.

Exploration can expose unexpected behavior, unclear requirements, usability friction, and risks that a predefined test path did not anticipate. It does not mean testing without discipline: sessions have a purpose, observations are recorded, and findings are assessed.

When to use it

Exploratory testing is especially useful when the team needs to learn about behavior it does not yet understand. Consider it for a new feature, a changed user journey, a complex integration, a system with incomplete requirements, or an area where a risk is not yet well understood. GOV.UK’s [exploratory testing guidance](https://www.gov.uk/service-manual/technology/exploratory-testing) recommends sessions with a goal, documentation of observations, and notes about further testing.

Use it alongside other testing approaches. Scripted checks and automated tests are effective for repeatedly checking known expectations. Exploration helps discover questions and scenarios worth checking. A finding can then become a repeatable manual scenario or automated test. Exploratory work does not by itself provide a complete, repeatable regression suite or prove that all requirements have been met.

A practical exploratory testing session

1. Choose a target and goal. Pick a feature, journey, or risk and phrase a question you want to answer. For example: “Can a returning customer recover from an interrupted payment and complete checkout without losing their cart?”
2. Set up the environment. Note the build or version, browser or device, test account, relevant data, and any conditions that may affect results. Use safe test data and avoid actions that could affect real users or production records.
3. Write a lightweight charter. Define the mission and boundaries, not a sequence of exact clicks. A charter might say: “Explore checkout recovery after payment interruption; focus on cart retention, retry behavior, and clear feedback; use the staging environment and a test account.”
4. Explore, observe, and adapt. Begin with a plausible user action. Observe what the system actually does, ask what could go wrong or vary, and let the result guide the next test. Try relevant variations such as missing, invalid, repeated, or boundary inputs; interruptions; different states; and navigation away and back.
5. Record evidence as you go. Capture concise notes, the steps needed to reach a surprising result, expected and actual behavior, relevant test data, and useful screenshots or logs. Record follow-up questions instead of losing the thread to investigate them immediately.
6. Debrief and report. Summarize the area covered, tests and observations, defects, questions, evidence, and next steps. Separate confirmed defects from unclear behavior that needs a product decision.
7. Make valuable discoveries repeatable. Reproduce a finding, create a defect report, and add a manual scenario or automated check when repeated verification matters.

This structure follows practical GOV.UK recommendations: state a goal for the session, document queries and observations with evidence, and note ideas for further testing. Its [reporting guidance](https://www.gov.uk/service-manual/technology/exploratory-testing) also suggests recording the charter, features explored, how testing proceeded, bugs, concerns, and supporting materials.

What makes a useful charter?

A charter focuses the investigation while leaving room to adapt. Include the mission or question, area in scope, risk or user goal, environment, test data, and—if useful—who will test and when. Keep the mission broad enough that observations can shape the next move. If the charter lists every action and expected result, it is becoming a script.

Does exploratory testing require charters?

No. A charter is a useful focus tool, especially when several testers need to coordinate or report sessions consistently. A tester can also begin with a clear question or risk without a formal charter. GOV.UK recommends charters as a way to give a session a mission without prescribing it.

Does exploratory testing require a timebox?

No. A timebox can help a team manage attention and prevent an open-ended session from drifting. Choose a limit that fits the work and leave time to record findings and debrief. The method remains exploratory if the tester adapts the tests; the clock is a management aid, not a defining rule.

What to investigate

Start from the user journey and the risks rather than trying random inputs. Useful prompts include:

• States and transitions: What happens before, during, and after a key action? Can a user retry, cancel, go back, or resume?
• Boundaries and invalid data: What happens with empty, unusually long, malformed, duplicated, or out-of-range values?
• Timing and interruption: What happens when a request is slow, a page is refreshed, a connection drops, or an action is submitted twice?
• Roles and permissions: Does behavior differ across user types, ownership, or access levels?
• Consistency: Do totals, status messages, saved data, and notifications agree across screens?
• Usability and accessibility: Can users understand errors, find the next action, and complete the journey with different input methods and viewports?
• Integration boundaries: What does the application show when an external service returns an error, an unexpected response, or no response?

These are prompts, not a universal checklist. Pick those that fit the feature, risk, and session goal. For performance or security assurance, use suitable dedicated methods as well; exploratory interaction alone does not establish performance capacity or security.

Capture useful evidence

Good notes make discoveries understandable to someone who was not present. For each finding, capture:

• The environment, build, browser or device, and relevant account or data state.
• The charter or session goal and the area explored.
• The shortest reliable steps to reproduce the behavior.
• Expected behavior, actual behavior, and why the difference matters.
• Evidence such as a screenshot, recording, console output, or application log when available.
• Whether the behavior is repeatable, intermittent, or still uncertain.
• Questions and follow-up ideas that did not fit the session.

Distinguish observations from interpretations. “The confirmation page showed the old delivery address after saving the new one” is an observation; “the cache is broken” is a hypothesis. Keeping them separate helps developers investigate without treating an unverified cause as fact. Protect credentials and personal data in screenshots and logs.

A screenshot can preserve a visible state for a report, but it does not replace interaction, logs, or the steps that produced the state. For repeatable visual evidence of a public page, a screenshot API can capture the rendered page. A screenshot cannot capture a private test session unless the service can access the required state; do not send credentials or sensitive test data to a capture service without an approved workflow.

Capture a page screenshot for a report with cURL

For a public page, a browser-based DIY method is to open the page in a browser and save a screenshot from its developer tools. For scripted capture, use a browser automation library configured for your environment, or call a screenshot API. A screenshot is supporting evidence, not a substitute for reproduction steps.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request can return a PNG, JPEG, WebP, or PDF. Its capture can accept cookie and consent banners like a visitor and remove more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Responses identify page verdict and billing status in headers. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients.

See the ScreenshotNeo API documentation. Keep the API key private; replace YOUR_API_KEY with your key and change the target URL to a public page you are permitted to capture.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer())));

ScreenshotNeo removes cookie banners, popups, and chat widgets before the shot; bot checks, blank pages, and failed loads are never billed; its MCP server lets AI agents take screenshots; and 1,000 screenshots a month are free with no card. Paid plans start at $5 for 3,000 shots. Every feature is on every plan. Sign up for 1,000 free screenshots a month, with no card required.

Session notes template

Session:
Date / tester:
Build and environment:
Charter / goal:
Test data and account state:

Observation 1
- Area and steps:
- Expected:
- Actual:
- Evidence:
- Repeatable? (yes / no / unclear)
- Follow-up:

Defects raised:
Open questions:
Areas not explored:
Suggested repeatable tests:
Debrief:

Common mistakes and how to correct them

Problem	Why it hurts	Correction
Clicking around with no question	The session can wander and produce little actionable information.	Choose an area and goal; use a short charter or session question.
Writing a script and calling it exploration	Predetermined steps prevent findings from guiding the next test.	Keep the charter at mission level. Record useful steps after discovery.
Recording only “it is broken”	Others cannot tell what happened or reproduce it.	Record environment, steps, expected and actual behavior, and evidence.
Confusing a suspicion with a defect	A possible cause or unclear requirement may be reported as established fact.	State the observed behavior separately from hypotheses; ask for a decision when expected behavior is unclear.
Trying to cover everything in one session	Broad scope encourages shallow checks and weak notes.	Prioritize one journey, risk, or question; log adjacent ideas for later.
Failing to follow up	Discoveries may recur because they never become repeatable checks.	Debrief, file actionable defects, and add valuable scenarios to the regression approach.
Saving screenshots without context	An image may show a symptom but not the state or steps that caused it.	Attach the image to concise reproduction steps, environment details, and relevant logs.

Tools, reliability, and cost

You do not need dedicated software to begin. A notebook or plain text document can capture a charter and observations. Depending on the work, browser developer tools, screen recording, logs, a shared issue tracker, or a test management tool can make evidence easier to preserve and hand off. GOV.UK notes that tools can capture video or logs and organize work, but pen and paper are enough to start.

Choose tools based on the task: can they preserve evidence, connect results to a session goal, export or share findings, and fit the team’s defect and regression workflow? A vendor example such as [Tricentis Tosca’s session-based exploratory testing documentation](https://docs.tricentis.com/tosca/2026.1/en/content/tosca_commander/exploratory_testing.htm) illustrates a workflow with charters, scenarios, screenshots or video, and manual test-case generation; it is an example, not a comparative recommendation.

Plan for reliability in the session itself: use a known build, note environmental differences, preserve test data where appropriate, and repeat a surprising result before treating it as stable. A timebox should include setup and debrief time, not only clicking time. There is no universal session duration or quantified defect-discovery rate established by the sources used here; decide based on scope and team needs.

Cost depends on the people’s time and any optional tooling. Do not buy a test management product as a prerequisite. Add tools when they address a real handoff, evidence, or organization need. If using screenshots for public-page evidence, ScreenshotNeo offers 1,000 shots per month free without a card; paid plans are Starter $5 for 3,000, Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000. Yearly billing gives two months free. Check the [product site](https://screenshotneo.com) for the current plan details.

FAQ

Is exploratory testing the same as ad hoc testing?

No. It can be flexible, but it is goal-directed and evidence-based. Unfocused clicking without a question, observation, or useful report lacks that discipline.

Who can do exploratory testing?

Testers, developers, product managers, business analysts, and subject matter experts can contribute when they understand the product or can investigate it carefully. Different experience may reveal different risks.

Can exploratory testing be automated?

Exploration involves human judgment and adaptation, so it is not simply a fixed automated script. Automate repeatable checks that emerge from findings, and use automation to support setup or evidence capture where appropriate.

Should every discovery become a regression test?

No. Add a repeatable check when the behavior matters and future verification is valuable. Some observations instead call for a product decision, further investigation, or no action.

Sources

• ISO/IEC/IEEE 29119-1:2022, general concepts and definition.
• GOV.UK Service Manual: Exploratory testing, session goals, charters, evidence, reporting, and tools.
• ISTQB Foundation Level syllabus topic: Experience-based test techniques, learning, design, and execution while learning about the test object.
• Martin Fowler: Exploratory Testing, practical discussion of adaptive sessions, focus, charters, and timeboxes.