Ad Hoc Testing in Mobile QA: When It Works and When It Fails

Key takeaways

• Ad hoc testing is unscripted, unplanned, time-boxed exploration of an app with goal of finding bugs that structured tests miss. Not absence of a plan. The deliberate choice not to write one.
• It works for post-fix verification, new feature exploration, and probing hunches. It fails for regression coverage, cross-device parity, performance tracking, and anything that needs audit trails.
• Most teams do ad hoc badly because they skip two disciplines: time-boxing and screen recording. Both are free. Both turn ad hoc from vibes into signals.

Ad hoc testing in mobile QA is a technique where an experienced tester explores an app without a predefined test plan, script, or checklist. The tester picks a target, decides on fly what to probe, and reports what they find.

No test cases written up front. No coverage matrix. Just a person, a device, and a hunch about where bugs live.

The problem with every "ad hoc testing guide" online is they say same three things: it's unstructured, needs experienced testers, and is good for tight deadlines. That's true and useless.

This post is for people who actually need to decide when 'ad hoc' earns its place, when it's wrong tool, and how to run it in a way that produces reportable findings.

What ad hoc testing actually is (and isn't)

Ad hoc testing is deliberate absence of a test plan for a specific session. Emphasis on "deliberate."

Not "We didn't get around to writing tests." Not "We don't have time for a plan." The choice not to plan is point. You want the tester to follow their instincts about where app is fragile, not run a script that could be automated.

ISTQB defines it as testing carried out informally, with no formal preparation, no recognized test design technique, and no expectations for results, where tester's intuition guides execution.

That's definition. The reality on mobile is messier.

What "ad hoc" is NOT:

• Not exploratory testing. Exploratory has structure through charters, time boxes, and note-taking. James Bach's Session-Based Test Management describes "exploratory" as "simultaneous learning, test design, and test execution." Ad hoc skips learning-in-parallel part. A tester doing ad hoc already knows app well.
• Not monkey testing. Monkey (or fuzz) testing uses random input generators to bombard apps with unexpected data. "Ad hoc" uses human judgment, not randomness.
• Not "manual testing." Manual testing executes scripted test cases by hand. Ad hoc explicitly has no test cases.
• Not buddy testing or pair testing. Those are collaboration models that can happen in scripted, exploratory, or ad hoc formats.

Exploratory sessions and ad hoc testing get grouped together, but they're not same activity. Exploratory has a charter ("investigate how app handles session timeout during a background transition") and ends with a session report. Ad hoc has neither.

If you write down what you're going to test before you start, you've stopped doing ad hoc and started doing exploratory. Both are valuable. Neither is a substitute for other.

When ad hoc testing works on mobile

Four scenarios where ad hoc earns its keep. In every other scenario, it's wrong tool.

1. Post-fix verification for narrow bugs.

A dev patched an issue where "Add to cart" button occasionally rendered off-screen on iPhone SE 3rd gen. Grab an SE 3rd gen, open the app, tap through, verify. Ten minutes.

No test case needed because there's no reusable coverage here. The bug was specific, fix is specific, and the verification is specific. Writing a formal test case for this would be theater.

2. Probing a specific hunch.

A tester notices app feels slower on certain screens after a recent build. They can't articulate why. They spend 45 minutes tapping through, watching for moments where their gut says, "This used to be faster."

They find a lag that only shows up when cart has more than 20 items. Scripted tests would never have caught this. Nobody writes a test for "does cart feel slow with 20 items."

3. New feature initial exploration.

A new feature ships to staging. Before writing test cases, an experienced QA lead spends an hour with feature, poking at it. They find:

• Three usability issues
• Two crash paths
• One integration bug with existing analytics layer

Now they know what test cases to write. Structured checklists work for regression, but new features often start with ad hoc testing before anything gets written down.

4. UAT overflow.

UAT sessions often turn into ad hoc testing once acceptance criteria are cleared. A user rep signs off on happy path in 20 minutes, then spends next hour poking around because they've spotted something odd about backgrounding behavior.

That extra hour is ad hoc. It's often where real production bugs get caught.

When ad hoc testing fails

Every SERP article says "ad hoc has limitations" and moves on. Here are actual failure modes:

• Regression coverage. Ad hoc will never tell you, "The previously fixed bug is still fixed." It doesn't produce repeatable evidence.
• Cross-device parity. Two hours of ad hoc on a Pixel 8 tell you about Pixel 8. It tells you nothing about other 11 devices in your matrix. This is single biggest failure mode teams underestimate.
• Performance regression tracking. Did checkout screen get slower between v3.2 and v3.3? Ad hoc can't answer that. No baseline, no repeat measurement, no comparability.
• Security vulnerability discovery. Ad hoc might catch an admin field visible to regular users. It won't catch token leakage in a network request, keychain misconfiguration, or path traversal.
• Regulated environments. FDA 21 CFR Part 820, PCI DSS, and SOX all require traceable test execution. Ad hoc has none of that by design.
• Load and stress behavior. Ad hoc is one device with one user. Load testing needs orchestration.
• Onboarding new team members. A new QA hire cannot start with ad hoc. They don't know app well enough. Scripted tests are how new hires learn app.

The pattern: anything that needs consistency, comparability, or auditability is wrong job for ad hoc.

The mobile-specific ad hoc discipline

"Web ad hoc" means clicking around. Mobile ad hoc has more surface area to probe. Doing it well means knowing which surfaces produce bugs scripted tests miss.

Interruption injection. Start a flow. Trigger an incoming call mid-flow. Answer. Hang up. Return.

Does state restore? Do it again with an alarm. With a low-battery notification. With a Face ID prompt from another app. Interruptions are a classic mobile ad hoc target because scripted tests for every possible interrupt combination are prohibitively expensive.

Permission toggling mid-session.

The tester grants location during onboarding. Later, mid-flow, they go to Settings and revoke it. Come back to app:

• Does it crash?
• Does it silently fail?
• Does it prompt again correctly?

Same idea for camera, notifications, photo library.

Network condition manipulation. Wi-Fi → 4G mid-load → offline → back to Wi-Fi. Check what state app is in after each transition. Ad hoc chains these in ways scripted tests rarely do.

Device orientation during specific flows. Rotate device during checkout. During payment confirmation. During a video call. During biometric prompt.

Orientation triggers onConfigurationChanged on Android and view controller lifecycle on iOS. Bugs live in specific flows where orientation isn't expected.

Background/foreground timing:

• Background for 30 seconds. Foreground.
• Background for 4 minutes. Foreground.
• Background for 20 minutes. Foreground.

Different timings surface different bugs. Session expiry, state loss, resume failures.

Rapid input sequences. Double-tap "Submit." Triple-tap. Tap "Submit" and then immediately "Cancel." Race conditions in click handling are a mobile-specific bug source that ad hoc surfaces.

Storage state manipulation. Fill device to near-full storage. Try to install an update. Record a video. Download a file. Behavior at storage boundaries is rarely scripted.

Cold vs. warm state. Fully kill app between actions. Rapidly relaunch. Compare behavior to a warm-state resume.

These aren't test cases. They're areas to probe. The tester decides on fly which ones to explore based on what looks fragile in current build.

The reporting problem nobody solves

Ad hoc testing produces bugs. Most of those bugs get filed. Most of them are unusable.

The classic bad ad hoc bug report:

"The app crashed when I was in checkout flow. Can't remember exactly what I did. Screenshot attached."

The dev cannot reproduce it. The bug sits in backlog. The next release ships without fixing it.

This is biggest reason teams distrust ad hoc. Not because it doesn't find bugs. Because bugs it finds are hard to act on.

The fix is cheap, and most teams skip it: record everything.

• iOS: screen record via Control Center
• Android: built-in screen recording since Android 11

The tester turns on screen recording before starting session. When they hit a bug, recording captures the exact sequence. They stop, save clip, attach it to the bug. Dev has exact repro steps as the video.

That solves 80% of ad hoc reporting problem for cost of turning on a toggle.

For last 20%: tester should keep their notes app open. When something looks weird, one line ("home screen loads slower than yesterday; checkout screen has a 200ms lag on button"). Not full documentation. Enough breadcrumbs to reconstruct later.

If your team's ad hoc bugs aren't reproducible, it's not because ad hoc doesn't work. It's because you skipped these two steps.

Time-boxing turns ad hoc from vibes into signals.

The biggest discipline missing from most ad hoc practices is time-boxing.

An ad hoc "session" without a time box runs either too short (tester gets bored in 20 minutes) or too long (loses focus after 90). Both produce bad findings.

The Session-Based Test Management framework recommends 90-minute sessions, with 60- or 120-minute variants for specific cases. Even for a purely ad hoc without a charter, time boxing works.

The workable pattern:

• Pick 60 to 90 minutes
• Set a timer
• Do session
• Log what you found
• Stop

The time box forces testers to prioritize. In 60 minutes on a complex mobile app, you can't probe everything. You have to decide what to focus on, which means engaging intuition that makes ad hoc useful.

For a full release cycle, most teams find 4 to 8 hours of ad hoc across a release is a sweet spot. Split across different testers and focus areas. Less and you don't get value. More and more returns diminish fast.

The hybrid that actually works

The false dichotomy in every SERP article: "ad hoc vs. scripted testing." Real teams do both, together, in a specific pattern:

1. Automated scripted tests handle regression. Every core flow, every critical path, in CI on every PR.
2. Manual scripted tests handle new features on their first cycle. Written from acceptance criteria. Executed once. Then automated or dropped.
3. Ad hoc sessions fill gaps. Two 90-minute sessions per release. Different testers, different focus areas.
4. Exploratory sessions handle specific hypotheses. Charter-driven. Runs when there's a specific area being investigated.

Ad hoc without scripted tests underneath is dangerous. You have no regression floor.

Scripted tests without ad hoc above them are brittle. You miss bugs that don't fit test case format.

Both together are the answer.

Where automation fits

Ad hoc testing is manual by definition. Nothing to automate here.

The relevance of automation to ad hoc is indirect: stronger your automated coverage, more valuable your ad hoc time becomes.

• Regression suite catches 95% of bugs → testers focus their limited ad hoc hours on interesting 5%
• Regression suite catches 40% → testers spend most of ad hoc re-finding bugs that should have been caught scripted

For mobile teams, automated coverage floor is often shaky because selector-based frameworks flake. When Appium tests are 65% reliable, you can't trust regression to have caught anything. Every ad hoc session starts by re-verifying happy paths.

Drizz tests are written in plain English:

• Tap "Add to cart"
• Validate "Order confirmed" is visible

Vision AI reads the screen way a person does. When automated regression is reliable, ad hoc testing time gets spent on real product exploration instead of bug re-verification.

Before, on Appium:

• Automated regression pass rate: 68%
• Testers spend 3 hours per release re-verifying failed happy paths manually
• Ad hoc sessions squeezed to 30 minutes because there's no time
• Ad hoc finds limited, mostly re-discoveries of known issues

After, on Drizz:

• Automated regression pass rate: 96%
• Testers spend 15 minutes per release triaging real failures
• Ad hoc sessions run their full 90 minutes each
• Findings shift from "found same crash again" to "found a new race condition in permissions revocation during a payment flow"

Different quality of findings.

That's actual value proposition for automation and ad hoc together. Not "ad hoc" is dead. " Ad hoc gets more valuable when it's not only thing catching bugs.

FAQ

What is ad hoc testing?

Unscripted exploration of an app by an experienced tester aiming to find bugs that structured tests miss.

How is ad hoc testing different from exploratory testing?

Exploratory testing has a charter and structured note-taking. Ad hoc has neither. Both are unscripted, but exploratory is more disciplined.

When should you do ad hoc testing on mobile?

Post-fix verification, new feature exploration, probing specific hunches, and UAT overflow. Not regression, not cross-device parity checks.

Can ad hoc testing be automated?

No. Ad hoc requires human judgment about what to probe next. Automation is scripted by nature.

Who should do ad hoc testing?

Experienced testers with deep product knowledge. New hires lack intuition about where bugs cluster in app.

How do you report bugs found during ad hoc testing?

Turn on screen recording before you start. When you hit a bug, save clip as repro steps.

‍