Before exploratory testing we had ad hoc testing. Testers explored how systems worked and what might cause software to break. This kind of testing was improvised and often impromptu. Testers randomly tried the system’s functionality to see if they could break the system. The goal was finding bugs and vulnerabilities.
In the 1990’s, the term “exploratory testing” became widely used to refer to this testing approach. However, exploratory testing is generally considered more sophisticated, more thoughtful, and more methodical than its predecessor. oth approaches –ad hoc and exploratory– forego specific rigid step-by-step test plans. Testers improvise—they simultaneously design and execute tests, using what they learn from each test to develop the next one.
Many testers still use the term ad hoc testing, but more often than not it refers to deliberate attempts to break systems and may or may not require the refined testing skills needed for other forms of testing. Less often, ad hoc testing is used synonymously with exploratory testing. However, those who view exploratory testing as a disciplined approach requiring advanced testing skills rarely refer to their approach as “ad hoc.”
While ad hoc testing does include an element of randomness, “ad hoc” does not mean sloppy or careless. The Latin phrase means “for this” and the term is widely used to describe a response created for a specific situation or problem. The task is immediate and targeted and the approach was not planned in advance. An ad hoc solution is not generalizable to other contexts—it is unique to the dilemma at hand.
Exploratory or adhoc testing does not mean testing without documentation. This type of testing still needs a record of what was performed for managers to feel secure about test coverage. Recording tools, like our eXplorer tool, help testers document every step and provides managers visibility into ad hoc or exploratory testing.
From this perspective, the ability to use an ad hoc approach to testing is a valuable skill in a tester’s repertoire. Sometimes systems behave in unpredictable ways and the usual methods of identifying what is happening don’t provide enough insight. Occasionally, aggravating, ostensibly inexplicable problems require a solution designed especially for the present circumstances—an ad hoc solution—which may involve seemingly random attempts to replicate the problem or change how the problem presents itself. This randomness, characteristic of the ad hoc testing of yesteryears, may be exactly what is needed to unravel defects that seem to defy logic.
Another scenario where an ad hoc approach is likely to be the most effective and efficient path occurs when developers see a likely defect. An ad hoc test—one designed for that situation– can be executed quickly to verify or rule out a potential problem and resolve it right away.
Like so many aspects of software development, terms mean different things to different people. So when you talk about ad hoc testing, provide context. Your understanding of an ad hoc approach might be someone else’s exploratory approach, or they may call it monkey testing or buddy testing or another kind of testing. If you and your team are clear about the goal of the testing and the approach taken to achieve that goal, the name is really a secondary consideration.