Exploratory testing is practice of simultaneously learning about an application, designing tests, and executing them, all at once, guided by tester's experience and curiosity rather than a pre-written script. Cem Kaner coined term in 1984, and James Bach's one-line definition still holds: "simultaneous learning, test design, and test execution."
In practice, it means a tester opens app, starts using it like a real person would, and follows their instincts when something feels off. They aren't following a test case. They're hunting for bugs that test cases can't predict.
This matters more on mobile than anywhere else. Scripted test cases cover flows you anticipated. Exploratory testing covers ones you didn't, like gesture that confuses app or OEM dialog that blocks first screen. On mobile, surface area of "things nobody predicted" is far larger than on web because of device fragmentation and manufacturer skins that change how OS behaves.
BBST (Black Box Software Testing) research found that exploratory sessions guided by written charters find 40-60% more actionable bugs than equally-timed unguided exploration. Yet according to State of Testing 2024 survey, fewer than 35% of teams consistently write charters before exploratory sessions. The gap between knowing what exploratory testing is and doing it well is where most QA teams leave bugs on table.
Exploratory vs scripted: same login flow, two approaches
The difference is easier to see on a concrete example.
Scripted test (login flow): The test case says: 1. Open app. 2. Enter valid email. 3. Enter valid password. 4. Tap "Log in." 5. Verify home screen loads. The tester follows these 5 steps. The test passes. The tester moves to next test case.
Exploratory test (same login flow): The tester opens app and starts with happy path: valid credentials, tap Login, home screen loads. Then they think: "What if I tap Login with an empty email?" Error message appears. Good. "What if I paste a 500-character string into email field?" The field accepts it, keyboard freezes for 2 seconds, and app sends a malformed API request that returns a 500 error with a raw stack trace visible on screen. That's a bug and a security issue. No scripted test would have covered "paste 500 characters into email field" because nobody anticipated it.
The tester continues. "What if I start typing password, get a phone call, return to app, and password field is now empty but cursor is in email field?" That's a state restoration bug. "What if I rotate the device to landscape while the keyboard is open?" The Login button slides behind the keyboard and becomes untappable. Another bug.
The scripted test found zero bugs. The exploratory session found three in five minutes. Both approaches tested the same screen. One followed a script. The other followed curiosity.
Running a mobile exploratory session: a walkthrough
Here's what an actual 20-minute exploratory session looks like on a food delivery app. This isn't hypothetical. It's kind of session a QA lead would run after a new checkout feature ships.
Minutes 0-2: Orient. Open app on a Samsung Galaxy A14 (budget device, Android 13, One UI 5). Why this device? Because budget phones are where most real-world bugs surface. Slower processors expose timing issues, smaller screens expose layout problems, and One UI's battery optimization and font scaling create conditions dev team didn't test on.
Minutes 2-5: Happy path first. Browse restaurants, pick one, add an item to cart, go to checkout. Everything works. The new "Express Checkout" button is there. Tap it. Payment goes through. Order confirmation loads. So far, so good.
Minutes 5-10: Start breaking things. Go back to restaurant, add a second item. The cart now shows two items. Apply promo code "FIRST50." Discount shows correctly. Now remove first item. The promo code disappears. Is that intentional? The minimum order for "FIRST50" is $20 and remaining item is $12. So promo removal might be correct. But app doesn't tell user why promo was removed. The discount just silently vanishes with zero feedback. That's a UX bug. The user will think app is broken.
Minutes 10-15: Device-specific behavior. The Samsung has system font size set to "Large" (which is default for this device in many markets). The Express Checkout button label now reads "Express Che..." because larger font truncates it. The button still works, but it looks broken. On a Pixel with default font scaling, it reads "Express Checkout" fine. This is a device-specific visual bug invisible on any emulator or non-Samsung device.
Still on Samsung: tap delivery address field. The keyboard appears and covers "Place Order" button. Try to scroll down. The page doesn't scroll because checkout form isn't inside a ScrollView. The user literally can't reach button without dismissing keyboard first. On Pixel, screen scrolls. On Samsung, it doesn't, because One UI's keyboard inset behavior differs from stock Android.
Minutes 15-20: Edge cases. Kill app mid-payment (swipe it out of recents while payment loading spinner is showing). Reopen it. The app shows home screen, not checkout. The payment actually went through (order exists in backend), but user doesn't see a confirmation. They might try to order again and get double-charged. That's a critical bug.
Session result: 4 bugs in 20 minutes. One UX issue (silent promo removal), one visual regression (font truncation on Samsung), one layout bug (non-scrollable checkout on Samsung), and one critical state restoration bug (payment completes but confirmation lost after app kill). No scripted test would have found Samsung-specific issues or mid-payment app kill scenario.
The session charter template
A charter keeps session focused and findings documented. Here's one filled in for session above.
8 mobile-specific patterns to explore
These are areas that produce highest bug yield during mobile exploratory sessions. If you're running a 20-minute session, pick 3-4 of these and go deep.
1. Touch targets near screen edges. Buttons placed in bottom 60 pixels of screen compete with Android's gesture navigation bar and iOS's home indicator. Tap bottom-most button on 3 different devices. On at least one, system gesture will intercept your tap.
2. Device rotation during form input. Start filling out a multi-field form (name, email, address). Rotate device to landscape mid-entry. Does form preserve your input? Does keyboard reappear? Does layout still make sense, or does form become a single-column layout where you can't see field labels?
3. Notification interrupts during checkout. Start a payment flow. While loading spinner is showing, trigger a push notification from another app (or ask a colleague to send you a message). Tap notification. Return to app. Is payment state preserved? Or did app reset to home screen?
4. Slow network on image-heavy screens. Switch to a throttled network (3G or slower). Open restaurant listing screen. Do images load progressively, or does screen show a wall of empty placeholders for 10 seconds? Do restaurant names and prices appear before images, or does entire card wait for image?
5. System font scaling at 1.3x and 1.5x. Go to device Settings, increase font size to maximum. Return to your app. Check every screen. Button labels truncate. Error messages overflow their containers. Two-line navigation labels overlap with icons. This is where 30%+ of accessibility bugs hide.
6. Deep link from a push notification. Send a push notification with a deep link to order tracking screen. Tap it when app is closed (cold start). Does app open directly to tracking screen, or does it open to home screen and ignore deep link? Now try same when app is in background (warm start). Different code paths handle these two cases, and they're often tested only for warm starts.
7. App behavior after device restart. Restart phone. Open app. Is user still logged in? Are cached screens stale (showing yesterday's data)? Does app re-request location permission even though it was granted before restart? On some OEM skins, a device restart clears runtime permissions for apps that aren't "protected."
8. Location permission denial mid-flow. Open app, grant location permission, start browsing restaurants (which are sorted by distance). Now go to device Settings and revoke location permission while app is in background. Return to app. Does it handle revoked permission gracefully (show a message, fallback to a manual address entry)? Or does it crash, show a blank list, or keep showing stale location-based results?
How exploratory and automated testing work together
There's a common misconception that exploratory testing and test automation are competing approaches, that you either explore or you automate. On mobile, they're complementary layers that feed each other.
Exploratory testing finds bugs. The session above found 4. One of them (app kill during payment loses confirmation) is a critical bug that no scripted test anticipated because nobody wrote a test case for "kill app mid-payment."
Automated regression prevents those bugs from returning. Once payment state bug is fixed, you write an automated test that replicates scenario: start payment, kill app, reopen, verify order confirmation is recoverable. That test runs on every build going forward. The bug never comes back.
The cycle repeats. Every sprint, exploratory sessions find new bugs in new features. The bugs get fixed. Automated tests get written for each fix. The regression suite grows with tests that are grounded in real bugs, not hypothetical scenarios. Those are tests that actually prevent production failures.
Drizz is built for automation side of this cycle. When an exploratory session uncovers a bug on a Samsung Galaxy A14, you write regression test in plain English: "Tap 'Express Checkout,' validate 'Order Confirmed' is visible." Vision AI runs it on real devices including that exact Samsung model.
The app-kill-during-payment bug from session above is a good example. In Drizz, you'd write that test using KILL_APP system command mid-flow, then OPEN_APP to relaunch and validate order confirmation recovers. That's something traditional tools can't automate easily because they don't have native device control built in.
The popup agent handles OEM dialogs automatically. During session above, Samsung battery optimization prompt and Xiaomi's Security popup would block an automated test. With Drizz, popup agent detects and dismisses them without extra commands in test script. Self-healing adapts when UI changes across devices and builds.
One QA engineering lead, Morgan Ellis, described shift: "We started catching noticeably more issues after switching, easily 5x compared to our earlier setup." Another team shipped 20 automated tests in a single day because plain-English format meant whole team could contribute, not just automation engineers.
The numbers from teams using Drizz: test authoring goes from roughly 15 tests per month to 200 per QA engineer. Sprint time spent on testing and triage drops from 30% to about 10%. Flakiness drops from ~15% to ~5%. The exploratory sessions keep finding new bugs. The automated suite keeps growing with real, battle-tested regression tests. That's cycle that makes both approaches stronger.
FAQ
What is exploratory testing?
It's an unscripted testing approach where tester simultaneously learns about app, designs tests on fly, and executes them, guided by experience and curiosity rather than a pre-written test case.
How is exploratory testing different from ad hoc testing?
Ad hoc testing is random with no documentation. Exploratory testing uses session charters, time-boxes, and structured note-taking. The tester has a mission and records findings. It's disciplined, just not scripted.
When should you use exploratory testing?
After new features ship (to find what scripted tests missed), on new devices (to surface OEM-specific bugs), under time pressure (when writing full test cases isn't feasible), and as a complement to automated regression suites.
Can exploratory testing be automated?
The exploration itself can't be automated. It relies on human judgment, curiosity, and real-time decision-making. But bugs it finds should be automated as regression tests so they don't recur. Exploratory discovers. Automation guards.
What is a test charter for exploratory testing?
A charter is a one-page document that defines mission, time-box, device, areas to explore, and a space for recording bugs found. It turns unstructured exploration into a repeatable, documentable practice.
How long should an exploratory testing session be?
60-120 minutes is standard range. Sessions shorter than 45 minutes don't allow deep exploration. Sessions longer than 2 hours lead to tester fatigue and diminishing returns. 20-minute focused sessions work for targeted areas.
