Ad-hoc testing may be unstructured sort of testing which features a goal to interrupt the testing process so as to seek out the possible defects or errors at an early stage. This type of testing is done randomly and it is usually an unplanned activity which doesn’t follow any documentation and a test design technique to create test cases.
Ad-hoc testing which is not structured:
Ad-hoc testing does not follow any structured way of testing and it is done randomly on any part of the appliance. This testing can be achieved with a software testing technique called error guessing, which can be done by the people by who have enough experience on the system to ‘guess’ the most likely source of errors.
This testing requires no documentation/planning/process to be followed. Since the testing goals find defects through random approach without any documentation, defects will not be marked to the test cases.
When we have to execute ad-hoc testing?
This testing can be done when there is limited time, or not sufficient time to do elaborative testing. Ad-hoc testing is done after a formal test execution. If time permits, ad-hoc testing can be done on the system. Ad-hoc testing is going to be effective as long as if the tester is knowledgeable about the system under test.
Types of Ad-hoc testing:
There are different types of ad-hoc testing. They are:
- Buddy testing- Two buddies mutually work on identifying defects in same module. Mostly one buddy will be from development team and another person from testing team. Buddy testing helps the testers to develop better test cases and developer can also make design changes.
- Pair testing- when two testers are assigned same modules, share ideas and work on the same machine to identify defects. One person can run the tests and another person can note down the findings.
How buddy testing and pair testing differ?
Buddy testing is combination of unit and system testing along side with developers and testers but pair testing is completed only with testers who have different knowledge levels.
Best practices of Ad-hoc testing:
There are many practices for adhoc testing:
- Good business knowledge
Testers will have a good testing knowledge of the business and clear understanding of the requirements. Detailed knowledge of the end-end business process will help find defects easily. Experienced testers find more defects as they are better at error guessing.
- Test Key Modules
Key business modules should be identified and targeted for ad-hoc testing. Business Critical modules should be tested first to realise confidence on the standard quality of the system.
- Record defects
Entire defects need to be recorded in a notepad. Defects always be assigned to developers for fixing. Each valid defect, corresponding test cases must be written and added to planned test cases.
- Creating a rough idea:
We can create a rough idea in place, the tester will focus. It doesn’t need to have a document of a detailed plan as what to be tested and how to test.
- Divide and rule
Testing the appliance part by part. We will have a better focus and better understanding of the problems if any.
- Targeting critical functionalities
A tester should target those areas that are not covered while designing test cases.
- Using Tools
Defects also can be delivered to the lime light by using profilers, debuggers and even task monitors. Hence by being proficient in using these tools, one can uncover several defects.