Adhoc Testing in Software Testing with Examples

Adhoc Testing is informal software testing that is used to test application functionality in a less structured manner as compared to expected results and without performing any kind of test cases creation. It’s usually performed by developers or testers during the early phases of Software Development Life Cycle (SDLC) such as requirements gathering, prototyping, and verification, etc. when software is not yet stable or mature enough.

Adhoc testing is an informal testing type, done with an aim to break the system. This testing is generally an unplanned and undocumented activity and is applied to early scientific experimental studies. It does not follow any type of test design techniques and thus does not require any test cases for performing the testing. The test is intended to be executed only once unless a defect is discovered. It is primarily performed if the knowledge of the tester is very high. It is a form of Black Box testing or behavioral testing.

As discussed earlier, Adhoc testing does not follow any Documentation, Planning, and Process. Since this testing aims at finding defects through a random approach, without any documentation, defects will not be mapped with any test cases. Hence sometimes it is very difficult to reproduce the defect as there are no steps or requirements mapped to the test cases. However, the string of Adhoc testing is that important, that defects can be found quickly. Adhoc testing is a type of error guessing, which itself is a light version of exploratory testing.

What is Adhoc Testing?

The term adhoc is used to mean “for this purpose only” or loosely translated to be “on the fly”.

In software testing, ad hoc testing is a method of executing tests without any formal documentation; this type of test typically requires less time preparation than other quality assurance methods. Normally these manuals are developed by software testing companies and then executed.

Adhoc testing can be known as the informal or casual approach to software testing, but I have used this word on my site because if you search for adhoc in google then most of the time you will get results related to IT.

Ad hoc testing is also known as “firefighting” and is performed by project managers or system administrators. These tests are designed and executed to resolve specific problems or issues that occur during the development of a software product.

Adhoc testing is also known as “random” testing in some sources, although this can be confusing because it may not be truly random due to the fact that ad hoc test methodologies are still quite structured. This blog post will primarily focus on ad hoc testing as a form of informal software testing.

When to perform Adhoc Testing

When we are talking about Adhoc testing, then the very next question which arises is that, When do we need to perform the Adhoc testing? And by whom it needs to be done?

Adhoc testing can be done at any time of the application development cycle, whether at the beginning, middle, or at the end. It is performed when there is limited time for performing elaborate testing. It is generally performed only after formal testing is done. And if time permits then Adhoc testing can be done on the system.

Adhoc testing will be effective if the tester has detailed knowledge of the system under test. So, the tester performing the Adhoc testing should have much experience and be detail-oriented. The experienced tester can find more defects as they are better at error guessing.

Adhoc Testing And Exploratory Testing

To understand the difference between ad hoc and exploratory testing, we need to know what is exploratory testing first.  The term “exploratory” in this context was borrowed from mathematics where it means that the process of finding something is more important than the outcome.

Exploratory testing is a non-structured method for software testing where the tester has the freedom to do and say whatever they want throughout the testing session.

In contrast, adhoc testing is similar to exploratory testing but with some differences – mainly that it’s performed for a specific purpose and with little or no documentation or preparation. Adhoc testing can be included as a subset of exploratory testing, but there are several key differences between these two:

• Exploratory testing is performed by the software testers only for finding bugs in the application at that time whereas ad hoc tests can be done by developers, system admins, and testers as well.
• Exploratory testing is performed without documentation or preparation, while ad hoc test can be done with some documentation (chat/email conversation) between developers/testers/etc but not fully prepared beforehand.

Exploratory testing involves a tester who doesn’t have any information about the product and tests it in a non-structured way. The tester has the freedom to perform any type of test including positive, negative, boundary value, and error or exception-based tests. Whereas in ad hoc testing the tester may get some idea from other testers/developers about what should be tested before conducting actual test execution.

Ad hoc testing can be performed on a daily build or release candidate to check for new bugs, whereas exploratory testing is performed after the entire product is built.  In ad hoc testing, testers perform tests without any help from developers or other technical experts, although in some cases they may ask them if they need any assistance while performing the tests.

Ad hoc testing can be performed manually or automated, but exploratory testing is typically only performed manually because it’s informal and unstructured.  In the case of adhoc testing, a tester may ask developers to skip some usability checks this way increasing the chance to find more defects for the early stage of the software development life cycle.

Adhoc testing is performed manually but exploratory testing can also be automated to some extent. This brings the main difference between these two types of testing.

Adhoc Testing in Software Development Life Cycle (SDLC)

The phases where adhoc testing is most effective are requirements gathering, prototyping, debugging, and/or verification and validation.  For example, testers can look for new bugs in the requirements or specifications before formalizing them into detailed design documents. In the case of prototyping, ad hoc testing can be utilized to verify that current functionality is working as intended or for finding defects for newly added features; etc.

Adhoc testing should not be performed on non-functional requirements such as security, portability, performance, usability, etc. because it doesn’t provide any benefit in this case. The reason is that these requirements shouldn’t change during the development process so if they have bugs/defects then it’s the developers’ responsibility to fix them before moving forward.

The team that performs ad hoc testing should be composed of testers, developers, and project managers. This may vary depending on the organization’s policies but according to my experience, it should be like this.  The reason is that ad hoc testing can reveal defects during integration or unit testing which can help developers to identify coding problems in applications early before releasing software products to the quality assurance (QA) team for regression testing.

This way it helps developers and testers to improve product quality. Ad hoc testing can be performed at the end of each sprint but some organizations may allow ad-hoc testing during any phase of an SDLC which is not recommended in my opinion because it can create an unnecessary burden for test teams who are already struggling with their day to day tasks.

Ad hoc testing should not be confused with exploratory testing. Exploratory testing can also be performed on newly added functionality but it’s a more formal method of software testing that consists of more detailed planning and documentation.

For example, in exploratory testing testers create test cases for each type of user role (user type) such as power user, IT manager, etc. whereas in ad hoc testing testers just try to perform some kind of functionality without any documentation and test case creations.

In fact, they are both different because exploratory testing is a type of software testing where testers analyze application features and then perform an informal test plan with the goal of discovering as many defects as possible before the product goes to a formal testing phase.

Ad hoc testing is also different from the contextual inquiry which is a very formal type of user testing where testers interview actual users to understand how they use software or which type of features they need in the future releases of application as well as what they don’t like and how can it be improved. Contextual inquiry is a very time-consuming process and therefore it’s usually performed in the later stages of SDLC when most features have been developed.

Types of Adhoc Testing

Even though Ad hoc testing is an unstructured type of testing we must follow certain conditions to get the best results.

• Buddy Testing
• Pair Testing
• Monkey Testing

Buddy Testing

In Buddy testing, Two members work together on identifying defects in the same module of the application. Mostly one member will be from the development team and another member will be from the testing team. Buddy testing helps the tester in making better test cases and also helps the development team make the required design changes at the early stages of development. This testing generally happens after the completion of unit testing.

Buddy Testing is suitable when a tester wants to test some specific aspect of the application, but he/she doesn’t know or understand how can it be tested. As testers usually work directly with developers therefore they can ask them about the best way to do it.

This is a time to ask for the help of your buddy. He or she will guide you through his/her testing experience and point out some flaws in the application which can be considered as bugs.

Pair Testing

In the Pair testing, two testers from the testing team are assigned modules, share ideas and work on the same machine to find the defects. They basically divide the testing scenarios among themselves and work together. The main aim of this type of testing is to cover maximum test scenarios so that the module has complete test coverage. Among them, one tester is responsible for executing the testing and another tester will act as a Scribe and will take notes of the findings and documentation. The paired testing is a combination of both experienced and inexperienced testers.

Many times we want to verify that two people are performing the same task on the application and that they are doing it in the correct way. Pair Testing is suitable for this because we can compare two tester’s test results to see if both testers reached the same conclusion about certain aspects of application features.

Pair testing is also preferred when you want to have bigger coverage of code or understand how can new functionality impact existing features. Other than that, pair testing can be very effective in reducing defects because if two people reached different conclusions about certain aspects then it means that functionality is not clear and there must be some kind of defect.

Monkey Testing

Monkey testing is a type of Adhoc testing, where the tester performs the testing of the application or system by giving random inputs and checking the application behavior. The main goal of this type of testing is to break the system. Monkey testing helps us to find undiscovered bugs which might not be caught earlier.

We have already discussed “monkey testing” when we were talking about white box software testing technique where a random tester performs a random test. But it can also be performed during ad hoc testing where the programmer will try to perform each and every feature that has been implemented in the released product. This method is preferred when we want to check how easy or difficult it is for application users to use new features.

Monkey Testing can also be done by testers who just try to perform operations that they are not familiar with. For example, testers can intentionally use applications in the wrong way or try to find bugs which can be dangerous for users because the application may become unstable and this is why it’s considered an unprofessional approach to software testing.

Importance of Adhoc testing

Though Adhoc testing is an unstructured and unplanned form of testing, still there exists a lot of benefits of Adhoc testing. Few of the importance of the Adhoc testing are listed below.

• It can be performed for the project will insufficient or limited software specification or requirements.
• It is beneficial when there is less time and a depth testing of the module is required. This helps in delivering the task with high quality and on time.
• Check for the completeness of testing
• Defect catching during Adhoc testing is added to planned test cases.
• Save much time as no formality is maintained.
• As it is an unstructured form of testing, so tester can emphasis more on testing the features of the module rather than focusing on the documentation part.
• This type of testing is not limited to the testers only, but also done by the development team and thus help in improving the code quality.
• It provides testers the freedom to implement new ways of testing the application and thus helps in finding undiscovered error or defects.
• It requires lesser level of preparation time.
• It can produce a quick result.

Advantages of Adhoc Testing

• Ad hoc testing is a good way to verify that new functionality works properly.
• Since ad hoc testing is an unstructured process therefore testers can get deep knowledge about application by analyzing different features from different perspectives which will also help in the context of exploratory testing.
• As Ad hoc tests are performed by more than one person therefore different testers can find different types of bugs which can reveal the larger scope of potential risks.
• Adhoc testing is an effective way to test certain features as well as possible ways how they work or not work. For example, if we want to check how does application work with new version of Java then we should ask specific person from development team who is responsible for Java version compatibility.
• Ad hoc testing is useful when we want to check how new functionality works with older versions of application as well as external software, services or devices.

Disadvantages of Adhoc Testing

• It’s very difficult to control ad hoc tests so it may lead to chaos and disadvantages.
• Adhoc testing can be annoying and frustrating when testers have to come up with an unstructured approach or brainstorm on their own when using application for the first time.
• Since ad hoc tests are performed by different people therefore there is a great possibility that someone will miss something during test preparation which may lead to erroneous false positive results or hiding of some important test scenarios.
• It’s very difficult to reproduce ad hoc tests therefore it may cause poor documentation, low test coverage as well as overlooked defects which can be later on considered as major issues for product.

Conclusion

While we were discussing different types of testing there was one type called “Adhoc testing” where randomly selected people perform random tests using their own creativity and imagination to come up with different test scenarios which can be very effective because it’s more like reallife scenario as testers use application for the first time.

Ad hoc testing may have some disadvantages too that could cause low test coverage, bad documentation, or even forgotten important test cases but we can eliminate this by making test preparation as thorough as possible and asking specific people from the development team who are responsible for the functionality that we are trying to test.

During ad hoc testing it’s very important to mention that testers should not try to use applications in the wrong way or use functionality which they are not familiar with otherwise it may lead to some chaos because test preparation and planning is an important part of testing therefore we should be prepared for everything even if we can’t predict what exactly will happen during tests run.

After all, it’s up to you to decide which type of testing you would like to use but remember that our main goal is to identify as many problems as possible and eliminate them before the product is released to the market.

I hope that this post was helpful and you learned something new today :). If so then please let me know in the comments below because it motivates me to write more awesome technical articles for you! Also if you found any mistakes or want to suggest something feel free to leave a comment too! I would really appreciate it!