Exploratory testing: a practical guide for QA engineers

Exploratory testing is learning about software by using it, designing tests in real time based on what you observe. You don't write steps first and then follow them. You investigate, poke at boundaries, and chase whatever looks suspicious. It's what good testers do naturally when they first touch a new feature.

Michael Bolton defined it clearly: "Testing is the process of evaluating a product by learning about it through exploration and experimentation." That's not a poetic ideal. It's a practical description of what happens when a tester sits down with a build and starts asking "what happens if I..."

The PractiTest State of Testing 2025 report shows that test case maintenance remains the number one challenge for QA teams. Exploratory testing sidesteps this problem entirely for certain situations: you don't maintain what you never wrote down as formal scripts. But that doesn't mean it's unstructured. The best exploratory testing is disciplined and documented. It's just documented differently.

Exploratory vs scripted testing#

Let me be direct about this: it's not a competition. You need both. Scripted testing covers the known scenarios you need to verify every release. Exploratory testing finds the problems nobody thought to write scripts for.

Scripted testing answers: "Does the login page still work the way we expect?" Exploratory testing answers: "What weird things can happen on the login page that we haven't thought about yet?"

James Bach, who formalized much of exploratory testing methodology, puts it this way: "Good testing is a challenging intellectual process." Scripted testing can become mechanical. Follow step 1, check result, follow step 2, check result. Exploratory testing stays intellectual because the tester is constantly making decisions about where to look next.

Here's when each approach works best:

Scripted testing works for: regression suites you run every release, compliance requirements that need documented evidence, handing off execution to someone unfamiliar with the feature, and tracking pass/fail trends over time.

Exploratory testing works for: new features before you know all the edge cases, areas where scripted tests pass but users still report bugs, quick assessment of a build's stability, and complex interactions between features that are hard to script.

Session-based test management#

Running exploratory testing without any structure leads to two problems: you can't tell what was tested, and you can't reproduce what you found. Session-based test management (SBTM) fixes both.

A session has three parts:

Charter: One sentence describing what you're investigating and why. "Explore the checkout flow with expired credit cards to find error handling gaps." The charter keeps you focused. Without it, exploratory testing drifts into casual browsing.

Time box: 60 to 90 minutes is the sweet spot. Shorter sessions don't give you enough depth. Longer sessions lead to fatigue and sloppy testing. When the timer goes off, stop and write up your findings even if you're in the middle of something interesting. You can start a new session to continue.

Notes: Write what you did, what you observed, and what surprised you. Not formal test steps, but enough that someone else could understand your path. "Tried checkout with Visa ending 0002 (expired). Got generic 'payment failed' error. No mention of expiration. Tried again with Mastercard ending 4444 (expired). Same generic error. Expected: specific message about card expiration."

How to write a good charter#

A charter should constrain your testing enough to be useful without being so specific that it becomes a script. Here are a few examples.

Weak charter: "Test the user profile page." This is too broad. You'll spend 90 minutes clicking around without clear purpose.

Strong charter: "Explore what happens when a user changes their email to one that already exists in the system." This gives you a specific scenario to investigate, but leaves room to follow interesting paths you discover along the way.

Strong charter: "Investigate the search feature with inputs containing special characters, Unicode, and SQL-like strings." Specific enough to focus, broad enough to allow discovery.

Documenting findings#

During a session, keep a running log. I prefer a simple text format:

Charter: Explore guest checkout with boundary-value shipping addresses
Time: 60 min
Tester: Alex

10:00 - Started with an address line of exactly 1 character. Accepted. UI looked fine.
10:05 - Address line of 255 characters (field max). Accepted but the confirmation page truncates at 80 chars. The full address IS stored in the DB. Visual bug only.
10:12 - Tried address with emoji (🏠 Main St). API rejected it with a 500 error. No user-facing message. BUG — filed as PROJ-892.
10:20 - Apartment number field: entered "Apt #3/4". The slash caused the address parser to split the line. BUG — filed as PROJ-893.
...

Summary: 2 bugs found, 1 visual issue noted. Shipping address parser needs work with special characters. Recommend adding scripted tests for special char handling.

This kind of log is useful in sprint retros, in conversations with developers, and as a basis for writing scripted test cases later for the bugs you found.

Techniques that actually work#

Over the years, testers have developed specific techniques for exploratory testing. These aren't theories. They're practical moves you can make when you sit down with a feature and wonder "where do I start?"

Boundary value analysis#

Every input has limits. Find them and push past them. If a field accepts 1-100 characters, test 0, 1, 2, 99, 100, and 101. If an API accepts quantities of 1-999, try 0, -1, 1000, and 999999. The bugs live at the edges.

State transition testing#

Software has states, and bugs hide in the transitions between them. An order goes from "draft" to "submitted" to "processing" to "shipped." What happens if you try to cancel during "processing"? What if the payment fails after the order moves to "submitted"? Map the states, then test each transition and the impossible transitions too.

Persona-based testing#

Think like different users. A new user who doesn't know the shortcuts. A power user who moves fast and skips steps. An impatient user who double-clicks everything. A malicious user who tries SQL injection in every field. Each persona finds different bugs because they use the software differently.

Tour-based testing#

Pick a "tour" and follow it. The money tour covers the most commercially important paths. The bad neighborhood tour revisits areas where bugs were found before (they tend to cluster). The garbage collector tour tries to find leftover artifacts: orphaned data, stale cache, UI elements that should have disappeared.

Interruption testing#

Start an action and interrupt it. Begin filling out a form and navigate away. Start a file upload and kill the connection. Open two tabs and submit the same form in both. Modern web apps handle the happy path fine. Interruptions reveal how well they handle reality.

Running exploratory testing on your team#

Here's a practical setup that works for most teams.

Allocate 20% of test time to exploration. If you spend 10 hours per sprint on testing, dedicate 2 hours to exploratory sessions. This isn't extra time; it's a reallocation from scripted testing to investigation. Teams that do this consistently find more edge-case bugs than teams that only run scripted tests.

Focus exploration on new code. Regression testing is for the scripted suite. Exploratory testing shines when applied to features where you don't yet know all the failure modes. Ask your developers: "What are you most worried about in this PR?" Then explore that area.

Rotate testers. Fresh eyes find fresh bugs. The person who wrote the scripted tests for a feature has mental models of how it works. Someone who hasn't seen the feature will try things the original tester wouldn't think of.

Debrief after sessions. A five-minute conversation after an exploratory session often surfaces insights that don't make it into the notes. "I noticed the API is slow when I filter by date range" might not be a bug worth filing, but it's useful context for performance testing later.

Combining exploratory and scripted testing#

The best QA workflows use both. Here's a pattern that works:

Sprint day 1-2: Feature is in development. Write scripted test cases based on requirements (how to write effective test cases).

Sprint day 3-4: Build is on staging. Run your scripted tests. Track results in your test management tool.

Sprint day 4-5: Run one or two exploratory sessions focused on the new features. Use the scripted test results to guide your exploration — if all scripted tests pass, dig deeper into areas the scripts don't cover.

After the sprint: Turn any bugs found during exploration into scripted test cases. Add them to the regression suite. This way, your scripted suite grows organically based on real findings rather than theoretical coverage.

Common mistakes#

1. Calling random clicking "exploratory testing." Without a charter, a time box, and notes, you're just messing around. That's fine for getting familiar with the product, but it's not testing. Write a charter before you start, even if it's one sentence.

2. Not documenting anything. "I tested it and it looked fine" gives zero information. What did you test? What did "fine" mean? If you can't point to your notes a week later, the session was wasted. At minimum, log what areas you covered and what you found.

3. Only doing exploratory testing. Exploration finds new bugs. Scripted testing prevents old ones from coming back. A team that only does exploratory testing will miss regressions because nobody is checking the same things systematically across releases. Use test prioritization to decide what gets scripted and what stays exploratory.

4. Skipping debriefs. The most useful output of an exploratory session isn't always the bugs filed. It's the tester's understanding of how the feature actually behaves. Share that understanding with the team. A two-minute summary in standup can prevent developers from introducing the same type of bug again.

FAQ#

How many exploratory sessions should I run per sprint?#

Two to four sessions of 60-90 minutes each is a good starting point. Adjust based on how much new code is in the sprint. A sprint with three new features needs more exploration than one with mostly bug fixes. Quality of sessions matters more than quantity.

Can junior testers do exploratory testing?#

Yes, and they should. Junior testers bring fresh perspective because they don't have assumptions about how things "should" work. Pair them with a senior tester for the first few sessions. The senior tester models how to think about edge cases, and the junior tester asks "what happens if..." questions that the senior tester stopped asking years ago.

How does exploratory testing fit with AI test generation?#

They complement each other well. AI tools can generate scripted test cases from requirements, covering the predictable scenarios. Exploratory testing covers everything the AI didn't think of — the weird interactions, the unusual user behaviors, the "nobody would ever do that" scenarios that users absolutely will do.

Should I track exploratory testing sessions in my test management tool?#

Yes. Create a script called "Exploratory: [Feature Name]" with your charter as the description. Add items for areas you want to investigate. After the session, add any bugs found as child items. This way, your exploratory work is visible alongside your scripted testing in the same workflow.

Want to track both scripted and exploratory testing in one place? Start free with TestRush or try the live demo.