Ad hoc testing is randomly conducted unstructured software testing that detects possible defects at an early stage. It is a completely unplanned activity that neither follows documentation nor any test design (techniques) to create test cases. The tests are run only once unless a defect is found.

Ad hoc testing is done with the aim of finding defects by means of random checking and it is performed on any part of the application. It is a kind of light version of Error guessing which is “guessing” the most likely source of errors and is usually done by those with adequate experience in the system.

As this testing is performed with neither documentation nor planning, any defects found are not mapped to test cases. The main criticism against this method is: that any defects found using this method are harder to reproduce, as there aren’t any written cases. However, important defects can be found quickly and this is a huge advantage of ad hoc testing. 

Usually, ad hoc testing is done after the formal test execution and when there is no time to perform any elaborate testing. Ad hoc testing is effective only if the tester has adequate knowledge about the system that is being tested.

Types of Ad hoc testing

Buddy Testing

In buddy testing, two people, one from development and another from testing, work together on the same module and spot defects. Through buddy testing, the testers are able to develop superior test cases and the developers are able to make design changes earlier on. This testing follows Unit Testing.

Pair Testing

In pair testing, modules are assigned to two testers, and to find defects, they share ideas together and work on the same machines to spot defects. One person, as a tester, executes the tests and the other person, as a scribe, takes notes on the activities. 

While buddy testing is a combination of system and unit testing along with developers and testers, pair testing involves only testers but with varying knowledge levels, one experienced and another, who is a novice. 

Monkey Testing

Monkey testing is performed randomly, without any test cases, where the goal is to break the system.

You might also like to read: All You Need To Know About Configuration Testing

Best practices of Ad hoc testing

Here are a few of the best practices which will ensure effective ad hoc testing:

Detailed business knowledge:

Testers should possess a strong knowledge base and have an adequate understanding of the business requirements. Detailed knowledge of the process will help spot defects easily. Experienced testers find more defects as they are better at error guessing. 

Preparation by getting details of defects of other similar applications: 

By getting those details, one increases the likelihood of finding the defects. Network testing, too, helps ensure the configuration is working properly. 

Testing key modules:

Identifying key business modules as targets for ad-hoc testing is critical. Also, business-critical modules need to be tested on priority so as to gain confidence in the system’s quality.

Creating an outline of an idea:

By having an outline of an idea in place, the tester can have a more focused approach. A detailed plan is not needed to accomplish this.

Ability to use tools:

Defects can be identified by means of profilers, debuggers and task monitors: so, experience in handling these tools will come in very handy.

Divide and identify:

Testing the whole application part by part will enable a better understanding and perspective of the issues. 

Recording defects:

Even though it is a random testing, all defects should be recorded and they need to be assigned, for fixing, to developers. Each valid defect should be accompanied by its corresponding test cases and be added to planned test cases. These defect findings ought to be reflected in the next system while planning for test cases.

Conclusion

In conclusion, the key merit of ad-hoc testing is to be able to check for completeness of the testing process and find more defects than planned testing. In software engineering, ad-hoc testing saves a lot of time as it does not require elaborate test planning, documentation and Test Case design.