A beginner's guide to ad hoc testing

Ad hoc testing is an informal software testing methodology that does not follow a predefined test scenario. Rather, it is a random and unstructured approach to testing that allows testers to explore their software freely, without the need for documentation, defined test cases, or formal test plans.

Your team can perform ad hoc testing at any point in the software development life cycle but it is most valuable after formal testing is complete. The flexible nature of this testing type gives your team the freedom to apply new testing techniques, inputs, and functionality quickly to determine their validity as well. Ad hoc testing is also highly valuable for identifying and resolving bugs that aren’t tied to formal test results.

Types of ad hoc testing

There are three core types of ad hoc testing.

Monkey testing 

Inspired by the Infinite Monkey Theorem, monkey testing is the most unstructured type of ad hoc testing available to your team. To do monkey testing, your testing team performs random actions on a piece of software without any planning or strategy. There are no desired outcomes.

The random inputs of monkey testing help your team find unpredictable bugs or vulnerabilities that might be overlooked with a more structured testing technique. This random testing also allows your team to stress test your software, as the inputs generated through monkey testing put an unexpected and illogical strain on the application.

There are three main types of monkey testing:

• Brilliant monkey testing is designed to simulate the actions of advanced users with specific, complex needs from your software. It is best used to refine the user experience for complicated workflows.
• Smart monkey testing is designed to simulate the actions of a regular user performing rudimentary tasks. It is best used to understand the different ways your application reacts to commonly performed actions.
• Dumb monkey testing is a totally random approach to testing. This type of monkey testing is best used in the early stages of development when critical bugs are more common.

Monkey testing should only be used once baseline usability and stability have been established in your application. The randomness of this type of ad hoc testing does not provide enough structure to build defined test cases or scenarios. It should only be used to simulate the random actions of a real-world end-user.

Buddy testing

Buddy testing is a collaborative approach to ad hoc testing that involves two people, one member of the development team and one member of the testing team. In buddy testing, the developer and tester work together on the same module or application. 

Often used as a follow-up to unit testing, buddy testing is a great way to identify bugs and make small improvements to an individual module or application quickly. It helps your team refine test cases over time, which can then be used for more structured and documented testing strategies in the future.

Buddy testing also helps your team collaborate more effectively, as members of different teams are involved in the testing process from the start. This increases overall team efficiency and communication, while also making error guessing and issue dedication more effective.

Pair testing

Pair testing is a two-person collaborative approach to ad hoc testing as well. It involves two members of the testing team, each with different responsibilities. In pair testing, one person is responsible for testing the software while the other is there to take notes and document the test findings.

In an ideal situation, the two testers should have different levels of experience with the software, so that they can share ideas and perspectives from different angles. This process helps less experienced testers gain proficiency in new testing techniques and methods while also allowing the more experienced testers to focus solely on the test scenario in front of them.

Since each team member has defined priorities for testing or documentation, pair testing can also improve efficiency and lessen the time it takes to complete an ad hoc test.

Buddy vs. Pair Testing

Buddy testing and pair testing can easily be confused with one another, as both types of ad hoc testing involve two people. But there are some key features of each testing technique that can help you differentiate them more easily:

Buddy testing involves one member of your development team and one member of your quality assurance (QA) team. You should use buddy testing when the testing goal is to quickly identify and resolve bugs in your software. As a developer is involved in the test, they can quickly provide input to your testing team and make changes to the software in real time, which helps you resolve bugs faster and more efficiently.

Pair testing involves two members of your QA team with different levels of experience. Pair testing is used when your goal is to conduct a comprehensive test on your software. As you have a more diverse testing perspective from within your QA team, pair testing is ideal for situations when you want deeper insights into any potential issues with your software. While bug fixes may be slower, they can be very useful for teams where resources are stretched thin.

Ad hoc testing vs. Exploratory testing

Ad hoc testing is sometimes confused with exploratory testing, but there are key differences that can help you tell the two methodologies apart.

Both ad hoc and exploratory testing are flexible approaches to manual testing, but benefit your team in very different ways. Ad hoc testing is most often used to find random bugs that impact the user experience. Exploratory testing lets your team design and execute test cases on the fly to gain a better overall knowledge of software functionality.

These differences are small, but understanding how each testing approach functions for your team will help you apply the correct methodology for your company’s specific needs.

When to use (and not to use) ad hoc testing

Ad hoc testing is a great addition to your testing team’s toolkit, but it’s not a suitable testing methodology for all your needs. Due to its informality and lack of defined structure, ad hoc testing should only be used after formal testing is complete. 

Ad hoc testing is a great choice when:

• Your testing team has limited time and resources to perform more complex and structured tests.
• You have experienced testers with a solid understanding of your software.
• You need to find unexpected errors and bugs throughout the software development lifecycle.
• Your team is unfamiliar with a new feature and needs to validate functionality after regression testing is complete.
• You’re performing user-acceptance testing and need to confirm alignment with business requirements.

Your team should not use ad hoc testing techniques when:

• Your team does not have experience with the software or features.
• You find a bug as a part of a formal test case.
• Your software is in beta testing.

As an informal and unstructured testing approach, ad hoc testing should also never be used as a replacement for more formal testing methodologies.  

Advantages of ad hoc testing

Ad hoc testing will help your team create a more consistent user experience with your software when used in combination with other, more formal testing methodologies.

• Ad hoc testing is flexible. It gives your team the freedom to explore your software without defined goals or outcomes, which aids in error detection for bugs or issues that might have been missed during formal testing.
• Ad hoc testing promotes creativity throughout your team because testers have free reign of your software. This helps them develop better critical thinking skills that can be applied to other testing approaches.
• Ad hoc testing simplifies the testing experience for your team, which saves valuable time and resources, especially for leaner organizations.
• Ad hoc testing increases overall testing coverage when used in combination with more formal testing methods.
• Ad hoc testing helps your team identify bugs throughout the development lifecycle. As this testing technique isn’t tied to any specific plan or scenario, your team can perform ad hoc testing at any point when they have the bandwidth.

Disadvantages of ad hoc testing

Due to its lack of overall structure and planning, ad hoc testing is not a good choice for certain complex testing scenarios.

• Ad hoc testing cannot replace formal testing techniques. The lack of documentation and planning means your team will not learn as much from ad hoc testing as they would from more structured methodologies.
• Ad hoc testing does not guarantee your team will find errors. If you have known issues with your software, this type of testing will not give your team the structure they need to resolve them.
• Ad hoc testing does not follow a repeatable test plan, so it will be difficult to replicate issues that come up as a result of this type of testing.

Incorporate ad hoc testing into your repertoire

While it is not a replacement for more formal testing methodologies, ad hoc testing will help your team build a more consistent user experience with your software. It is a great way to identify random and unexpected bugs while giving your testing team the freedom to explore new features and functionality without a lot of up-front work in documentation or planning.