Adhoc Testing

In this section, we will learn about Adhoc testing, types of Adhoc testing, the need for Adhoc testing, and advantage/ disadvantage of the adhoc testing.

What is Adhoc Testing?

This testing we do when the build is in the checked sequence, then we go for Adhoc testing by checking the application randomly.

Adhoc testing is also known as Monkey testing and Gorilla testing.

It is negative testing because we will test the application against the client's requirements.

When the end-user using the application randomly, and he/she may see a bug, but the professional test engineer uses the software systematically, so he/she may not find the same bug.

Example of Adhoc Testing

Scenario 1

Suppose we will do one round of functional testing, integration, and system testing on the software.

Then, we click on some feature instead of going to the login page, and it goes to the blank page, then it will be a bug.

To avoid these sort of scenarios, we do one round of adhoc testing as we can see in the below image:

Scenario 2

In Adhoc testing, we don't follow the requirement because we randomly check the software. Our need is A?B?C?D, but while performing Adhoc testing, the test engineer directly goes to the C and test the application as we can see in the below image:

Scenario 3

Suppose we are using two different browsers like Google Chrome and Mozilla Firefox and login to the Facebook application in both the browsers.

Then, we will change the password in the Google Chrome browser, and then in another browser (Firefox,) we will perform some action like sending a message.

It should navigate to the login page, and asking to fill the login credentials again because we change our credentials in another browser (Chrome), this process is called adhoc testing.

Why do we need to perform Adhoc Testing?

When the product release to the market, we go for Adhoc testing because the customer never uses the application in sequence/systematically for that sake; we check the application by going for Adhoc testing by checking randomly.

Checking the application randomly without following any sequence or procedure since the user doesn't know how to use the application, they may use it randomly and find some issues to cover this we do one round of Adhoc testing.

When we perform adhoc testing

We go for Adhoc testing when all types of testing are performed. If the time permits then we will check all the negative scenarios during adhoc testing.

Type of Adhoc Testing

Following are the types of adhoc testing:

• Buddy testing
• Pair testing

Buddy testing

Buddy testing is done with at least two members. And one member is from the testing team, and another one is from the development team.

When the unit testing is performed on the application, then only we can perform buddy testing. This type of testing helps the developer team and testing team to do their jobs.

Pair testing

In this type of testing, two testers will work together to test the software, where they can share their ideas and identify the bugs or defects in the application.

One of them will test the application, and the other one can review and analyze the application.

Advantages of Adhoc Testing

Following are some of the benefits of adhoc testing:

• Adhoc testing cannot follow any process; that why it can be performed anytime in the software development life cycle.
• The test engineer can test the application in their new ways that helps us to find out many numbers of bugs as compared to the actual testing process.
• The developer can also execute adhoc testing while developing the module that helps them to code in a better way.
• When the in-depth testing is required in less time, adhoc testing can be performed and also deliver the quality product on time.
• Adhoc testing does not require any documentation; that's why tester can test the application with more concentration without worrying about the formal documentation.

Disadvantages of Adhoc Testing

Following are the disadvantages of adhoc testing:

• Adhoc testing is dependent on the test engineer's product knowledge because he/she knows the flow of the application, so he/she knows where the application can collapse, and a new test engineer may not that much familiar with the application.
• Sometimes reproducing the bug is difficult because, in this testing, we did not follow any planning.