Ad Hoc Testing: Complete Guide, Types, and Best Practices (2026)
Ad Hoc Testing explained: definition, when to use, types (buddy, pair, monkey), how it differs from exploratory testing, and interview-ready examples for QA engineers.
Last updated: July 17, 2026 · 10 min read · By Avinash Kamble
Ad hoc testing is unstructured, unscripted testing where the tester improvises — no test cases, no plan, no formal documentation. Done well, it catches classes of defects that scripted tests routinely miss: strange interaction sequences, race conditions, UX confusion, and integration surprises. Done badly, it's a chaotic waste of time. This guide draws the line between the two and gives you a repeatable playbook for productive ad hoc sessions in 2026.
Key takeaways
- Ad hoc = no plan, no test cases, pure improvisation guided by tester intuition.
- Best for catching UX defects, race conditions, and unusual interaction sequences.
- Time-box every session and take notes — undocumented ad hoc is untrackable.
- Related but distinct from exploratory testing (which does have loose structure).
1. What is Ad Hoc Testing?
Ad hoc testing is testing performed without any planning, documentation, or predefined test cases. The tester uses experience and intuition to try to break the software in ways scripted tests would not think of. Also called random testing or monkey testing in its most unstructured form.
The term appears in the ISTQB Foundation syllabus under experience-based test techniques.
2. When to use ad hoc testing
- After scripted tests pass — a “shake the box” pass before release.
- Between sprints when a new feature has just landed and formal cases don't yet exist.
- During bug triage to reproduce vague user reports.
- To probe areas historically prone to defects (payments, auth, imports).
Do not use ad hoc as your only test technique. It is a supplement to scripted, risk-based testing, not a replacement.
3. Three types of ad hoc testing
- Buddy testing: a developer and tester pair up on the same feature — the dev knows internals, the tester probes usability. Catches integration and UX defects fast.
- Pair testing: two testers explore together — one drives, one observes and takes notes. Doubles the perspectives per session.
- Monkey testing: random inputs, random clicks (often automated) to stress the app and catch crashes.
4. Ad hoc vs exploratory testing
| Aspect | Ad Hoc Testing | Exploratory Testing |
|---|---|---|
| Planning | None | Loose charter (a mission per session) |
| Documentation | Rare (some notes) | Session notes + coverage log |
| Structure | Improvised | Time-boxed sessions with goals |
| Repeatability | Low | Medium (charter guides re-runs) |
| Best for | Quick smoke, breakage hunting | Feature-level deep exploration |
They overlap. In modern QA, teams call the disciplined version “session-based exploratory testing” and reserve “ad hoc” for shorter, unstructured passes.
5. The productive ad hoc playbook
- Time-box. 30–90 minutes per session, no more.
- Pick a slice. One feature or one user journey — not the whole app.
- Take notes. URL, steps, expected vs actual, screenshot. Even three-line notes turn a bug into a reproducible ticket.
- Vary the persona. New user, power user, admin, on a slow connection, on a phone.
- Attack the edges. Empty state, huge inputs, back button, refresh mid-flow, multi-tab, timezone changes.
- Debrief. Log the session (30 seconds) into a shared doc so the coverage compounds.
6. Pros and cons
Pros: catches defects scripted tests miss, no upfront artefact cost, senior testers surface issues fast, great for smoke and pre-release passes.
Cons: not repeatable, hard to measure coverage, low value in the hands of a junior tester without experience, results depend on tester skill.
7. Tools that make ad hoc sessions productive
- Loom or OBS to record the session for later triage.
- Browser devtools (Network, Console) always open — capture failing requests as they happen.
- A note pad (Obsidian, Notion, Jira ticket draft) for one-line observations.
- Feature flags to toggle risky states quickly.
- AI copilots — see the shift-left with AI copilots guide — to generate quick attack ideas.
8. Ad hoc in interviews
Common at 1–3 years and asked as a discriminator against exploratory. Expected: “What's the difference between ad hoc and exploratory testing?” and “When would you choose ad hoc?”. Rehearse both answers on the AI Mock Interview and prep the whole set on the 1-year Q&A hub.
9. Your 24-hour action step
Time-box a 45-minute ad hoc session on a feature that shipped this week. Take five lines of notes. Log at least one usability observation or defect. That's it. You have just given the team information no scripted suite would surface. Benchmark comp on the QA Salary Guide.
10. How senior QA leads run ad hoc in 2026
Elite teams have stopped treating ad hoc as an unstructured smoke pass. In 2026 the practice is being industrialised into 90-minute risk-based charters co-scheduled with feature-flag rollouts — the tester attacks the newly flagged surface while observability dashboards are open in a second monitor. From our SDET consulting reviews (H1 2026, n=42 teams), the shops that get real ROI from ad hoc share three habits:
- Session-based note-taking (SBTM-lite). Even a three-column log —
Charter · Bug · Note— turns ad hoc from theatre into audit-ready evidence a PM can act on. - Bug bash + AI copilot pairing. One tester drives, one runs Claude/GPT to generate 20 attack ideas per persona — 2.3x more unique defects surfaced vs solo (SoftwareTestPilot 2026 internal benchmark, 6 pilot teams).
- Attach a Loom + HAR to every finding. Cuts triage time from ~14 min per defect to ~3 min because engineers see the network trace and console state without a reproduction hunt.
The interview signal recruiters now listen for: “Even when I run an unscripted session, I always know which risk I'm probing, and I always leave an artefact.” That is what separates a Senior QA from a 3-year tester in a hiring loop.