If we look at the term ad hoc, it refers to something that is created or done only once, for a specific purpose as deemed necessary. Now if you apply this to software testing, you have something with no planning, no documentation, and no formal processes – gone are all the requirement documents, test plans, and test cases that we usually associate with testing.
As you can probably tell, ad hoc testing is the least formal testing method, which has often brought with it unwarranted criticism due to the lack of structure. But this takes away from the benefits of its purpose. Ad hoc testing is done to discover issues and defects which cannot be found in the more formal processes of testing, something along the lines of a last resort for testing.
Although the nonexistent structure makes it a lot more difficult to repeat finding defects, the real strength of ad hoc testing is that it enables you to find important defects quickly and in ways that are done outside of the box, not following the regular norms of testing,
It is performed by improvisation, with the tester seeking to find bugs any way that seems appropriate – seen as a light version of error guessing which in itself is a light version of exploratory testing. For ad hoc testing to be successful it’s essential that the tester has a very good and in-depth knowledge of the product or application
- When is it carried out?
Ad-hoc testing can be completed at any point in time whether it’s the beginning, middle, or end of the project testing. In terms of testing it is the last option to find any bugs or errors.
- What’s its purpose?
The aim of ad hoc testing is to break the application without following any processes or plans.
- What about the tester?
As mentioned, it is vital that the tester has a good knowledge of the product or application; without this they won’t be able to find anything.
- How often can ad hoc testing be carried out?
Ad hoc testing can only be carried out once, unless a defect is found that requires retesting.
By now you should know what ad hoc testing, is but what about when to use it. Knowing when or when not to use testing can be extremely tough and this is only amplified with ad hoc testing.
When to use it?
If you’re a tester, then you should be well aware that ad hoc software testing doesn’t always come as a first priority, and this can be attributed to all of the formal processes that have to be completed beforehand. As long as the tester has in-depth knowledge of the product or application then ad hoc testing can provide a different insight into testing, as it identifies bugs and defects which you wouldn’t normally find.
When not to use it?
Arguably, the more important question is knowing when not to use ad hoc testing, to stop you from investing valuable time, effort, and money on your project. Ad hoc testing should be avoided when there is a test case where a defect exists. In this case, there is a need to document the failure of the test case and to then verify and retest the defect once it is fixed. Additionally, there are scenarios where the end user may have the chance to test the beta version of the software.
Different types of ad-hoc testing
Buddy: Two buddies work together to identify any defect in the same module. One buddy will be from the developing side and the other buddy will be from the testing side. Importantly, it allows for testers to develop better test cases and allows for developers to make design changes at an early stage, before its too late. This happens after Unit Testing is completed.
Pair: Two testers are assigned modules where they share ideas and work on the same product or application to find any faults. This normally is done with a tester and a scriber who takes notes on any of the findings.
Monkey: Testing is done randomly on the product or application without test cases. The purpose here is to break the system.
Experiences from our testers
Anna Zhiltsova: “To make sure you get the most out of ad-hoc testing there’s a few different things that you need to note. First, if ad-hoc testing is to be done for multiple features, then testers should first categorize and prioritize the features. Features that are highly used by the customers should be tested first so that if any priority bug exists in the feature it can be reported and fixed early. Second, is the documentation of observations: if defects are found then the relevant test case should be created so that it will help the tester to retest the scenario in the future.”
Nikolay Semenov: “From my experience, it’s always a good idea to combine ad-hoc testing with other techniques. For example, you can consider adding a demo as a required step upon passing every user story from development to QA. In this demo meeting, the developer demonstrates added and changed functionality, how it works, and what parts of the system it affects. In the same meeting, if the QA and developer do ad-hoc testing, this technique becomes even more powerful. This makes it possible to concentrate on the riskiest areas and in turn increases the probability that defects will be uncovered at the early stages – before the code has even passed the structured testing. Importantly, this also enables the developer to fix the issue at a much faster rate.
As you can see ad hoc testing often creates a lot of confusion, due to it being so different from other areas of testing, which are detailed and structure. Ad hoc testing is very much the opposite of this, but what is does so well is that it provides a different insight than the normal avenues of testing and enables you to identify faults that you wouldn’t normally find.