Ad Hoc Testing: Types, Examples, and Best Practices

A QA lead gets a Slack message at 4pm on a Thursday. The release is scheduled for 6pm. The regression suite already passed. Someone wants a second pair of eyes on the checkout flow before it ships. There is no time to write a test plan. There is no time to review the existing scripts either. Someone just needs to poke around the app for twenty minutes and say whether anything feels wrong. That twenty minute session is ad hoc testing. Most QA teams run it constantly without giving it a name. This post explains what it actually is, how it differs from its cousins, and how to run it without losing the findings the moment the session ends.

What is ad hoc testing?

Ad hoc testing is unplanned, improvised testing with no test design done in advance. The tester opens the application and starts interacting with it based on instinct and prior experience. There is no script and no documented steps. Often there is no fixed goal beyond checking whether something feels broken.

That makes it easy to confuse with exploratory testing. The two are not the same thing.

• Ad hoc testing has no session structure at all. Someone just starts clicking.
• Exploratory testing is still improvised, but it usually has a charter. That means a stated goal, a time box, and a tester who takes notes as they go.
• Scripted testing is the opposite of both. It follows a documented test case with expected results defined ahead of time.

Ad hoc testing sits at the loose end of that spectrum. It depends almost entirely on the tester's domain knowledge, since there is no script to fall back on. A tester who has spent two years on a billing system will find different bugs in twenty unplanned minutes than a tester who joined last week. That difference comes purely from knowing where billing logic tends to break.

Types of ad hoc testing

Ad hoc testing is not one technique. Teams generally run it in a few recognizable forms.

• Buddy testing: a developer and a tester sit together, usually right after a feature is built. The tester tries to break what the developer just wrote while the developer is still available to explain intent.
• Pair testing: two testers work the same feature together. One drives the keyboard and one watches and calls out ideas, catching things a single person would miss.
• Monkey testing: random, high volume input thrown at the application. Testers often click through screens as fast as possible or enter garbage data, purely to see if anything crashes.

None of these produce a repeatable script. All three produce bugs that scripted tests would likely never catch. Those scripts, after all, were written before anyone knew where the weak spots were.

When ad hoc testing is actually useful

Ad hoc testing earns its place in a QA process in a few specific situations. It is not a general replacement for planning.

The first is the quick sanity check. A team ships a small copy change to the pricing page on a Tuesday afternoon. Running the full 200 test suite feels like overkill for a text edit. So someone spends five minutes clicking through the page to confirm nothing else broke.

The second is filling a gap right before a release. The documented suite covers the main paths. But there is a nagging feeling that the new discount code field was never really tested end to end. An unplanned session the night before release can surface that gap fast.

The third is onboarding. A new tester joining a team does not yet know the product's history or its weak spots. Turning them loose on the app for an hour, with no script, forces them to build intuition. It often surfaces bugs precisely because they do not yet know which paths are supposed to work.

A concrete example: testing a checkout flow

Picture an e-commerce checkout page the day before a release. A tester picks it up for a fifteen minute ad hoc session with no script. In that window they might do the following:

• Add an item to the cart, remove it, then add it again to see if the cart total recalculates correctly.
• Apply an expired discount code to check the error message actually explains why it failed.
• Switch payment methods mid-checkout to see if the form resets fields it shouldn't.
• Resize the browser window to a narrow width to catch a button that overlaps the total on smaller screens.

None of those steps were planned in advance. Each one came from the tester's memory of past bugs on similar flows. Say the narrow browser window reveals an overlapping button. That finding did not come from a test case, it came from fifteen minutes of curiosity. It is exactly the kind of bug that a documented suite would likely have skipped, since that suite was written to check specific fields and totals, not screen widths.

A documented suite is only as good as the scenarios someone thought to write down ahead of time. Ad hoc sessions exist precisely to catch what nobody thought to write down.

Best practices for running ad hoc testing well

Ad hoc testing goes wrong when it turns into aimless clicking with nothing to show for it afterward. A few habits keep it useful.

• Time box the session. Fifteen to thirty minutes is usually enough. An unbounded session tends to drift and loses focus fast.
• Write down what you find, even without a script to reference. A single line like "narrow browser width, checkout total overlaps the pay button" is enough to act on later.
• Feed anything real back into the documented suite. If the ad hoc session found a genuine bug, someone should write a repeatable test case for it. That way the next release catches it automatically instead of relying on another lucky session.
• Rotate who runs the session. Different testers, or even a developer stepping in, will notice different things based on what they already know about the product.

That last point about feeding findings back is the one teams skip most often.

It is also the one that actually compounds the value of ad hoc testing over time. A bug found once by accident and never turned into a test case will likely resurface the same way months later, again by accident.

The limits of ad hoc testing

Ad hoc testing is a useful supplement, not a foundation. It has real limits that matter when you are deciding how much to lean on it.

It is not repeatable. There is no script, so two different testers running an "ad hoc session" on the same feature will likely check completely different things. That means you cannot reliably compare results across releases.

It is not auditable on its own. Suppose a compliance reviewer or a new team lead asks what was actually tested before a release. "Someone clicked around for twenty minutes" is not an answer that holds up. There is no record of what was checked or what passed.

It depends heavily on the tester's experience. A junior tester running an ad hoc session on an unfamiliar payment system will likely miss the exact edge cases a specialist would catch instantly. The technique only performs as well as the person running it.

For those reasons, ad hoc testing works best as a fast, cheap addition to a documented, repeatable test suite. It should never replace one. The two are complementary. The documented suite gives you consistent, auditable coverage release after release. Ad hoc sessions catch the odd thing that suite was never written to check.

Most teams settle on the same balance: keep ad hoc sessions as a fast supplement, and let a documented, repeatable suite carry the actual release decision.