What is Ad Hoc Testing?

Testing done without using any formal testing technique and without any formal planning is called ad hoc testing.
It is done to explore the undiscovered areas in the product by using intuition, previous experience in working with the product, expert knowledge of the platform or technology, and experience of testing a similar product.
Ad hoc testing does not make use of any of the test case design techniques like equivalence partitioning, boundary value analysis, and so on.
Ad hoc testing is done as a confidence measure just before the release, to ensure there are no areas that got missed out in testing.
The test cases are not documented.
Ad hoc testing can be done in all phases of testing.

Drawbacks of Ad Hoc Testing & Possible Resolutions

Drawback	Possible Resolution
Difficult to ensure that the learnings learned in ad hoc testing are used in future.	Document ad hoc tests after test completion.
Large number of defects found in ad hoc testing.	Schedule a meeting to discuss defect impacts. Improve the test cases for planned testing.
Lack of comfort on coverage of ad hoc testing.	When producing test reports combine planned test and ad hoc test. Plan for additional planned test and ad hoc test cycles.
Difficult to track the exact steps.	Write detailed defect reports in a step-by-step manner. Document ad hoc tests after test execution.
Lack of data for metrics analysis.	Plan the metrics collection for both planned tests and ad hoc tests.

Uses the “buddy system” where two team members are identified as buddies.
The buddies mutually help each other, with a common goal of identifying defects early and correcting them.
A developer and a tester usually become buddies.

Pair testing is testing done by two testers working simultaneously on the same machine to find defects in the product.
Two testers pair up to test a product's feature on the same machine.
The objective of this exercise is to maximize the exchange of ideas between the two testers.
When one person is executing the tests, the other person takes notes.
They can swap roles of “tester” and “scribe” during a session. They can mutually decide on the modus operandi.

Exploratory testing is a technique used to find defects by exploring the product, covering more depth and breadth.
Exploratory testing tries to do that with specific objectives, tasks, and plans.

There are several ways to perform exploratory testing:

Guesses

Guesses are used to find the part of the program that is likely to have more errors.
Previous experience on working with a similar product or software or technology helps in guessing.
This is because the tester would have already faced situations to test a similar product or software.
Those tests from guesses are used on the product to check for similar defects.

Architecture Diagrams & Use Cases

Architecture diagrams depict the interactions and relationships between different components and modules.
Use cases give an insight of the product's usage from the end user's perspective.
A use case explains a set of business events, the input required, people involved in those events and the expected output.

Study of Past Defects

Studying the defects reported in the previous releases helps in understanding of the error prone functionality/modules in a product development environment.

Error Handling

Error handling is a portion of the code which prints appropriate messages or provides appropriate actions in case of failures.

Discussions

Exploration may be planned based on the understanding of the system during project discussions or meetings.
Information can be picked up during these meetings regarding implementation of different requirements for the product.

Questionnaires & Checklists

Questions like “what, when, how, who and why” can provide leads to explore areas in the product.

Iterative testing aims at testing the product for all requirements, irrespective of the phase they belong to in the spiral model.
Iterative testing requires repetitive testing.
Developers create unit test cases to ensure that the program developed goes through complete testing.
Unit test cases are also generated from black box perspective to more completely test the product.
After each iteration, unit test cases are added, edited, or deleted to keep up with the revised requirement for the current phase.
Regression tests may be repeated at least every alternate iteration so that the current functionality is preserved.
Automation helps in iterative testing.

Agile and extreme (XP) models take the processes to the extreme to ensure that customer requirements are met in a timely manner.
Agile and XP methodology emphasizes the involvement of the entire team, and their interactions with each other, to produce a workable software that can satisfy a given set of features.
Software is delivered as small releases, with features being introduced in increments.
Extreme programming and testing makes frequent releases and in a controlled way by involving customers.

Activities in XP Work Flow

The rules that are followed in extreme programming and testing are as follows:

Cross Boundaries - Developers and testers cross boundaries to perform various roles.
Make Incremental Changes - Both product and process evolves in an incremental way.
Travel Light - Least overhead possible for development and testing.
Communicate - More focus on communication.
Write Tests Before Code - Unit tests and acceptance tests are written before the coding and testing activities respectively. All unit tests should run 100% all the time. Write code from test cases.
Make Frequent Small Releases.
Involve Customers All The Time.

Defect seeding is a method of intentionally introducing defects into a product to check the rate of its detection and residual defects.
Also known as error seeding or bebugging.
Usually one group of members in the project injects the defects while another group tests to remove them.
The purpose of this exercise is while finding the known seeded defects, the unseeded/unearthed defects may also be uncovered.
Defects that are seeded are similar to real defects. Therefore, they are not very obvious and easy to detect.
Total latent defects = (Defects seeded / Defects seeded found) * Original defects found. Latent defects are the number of defects which are yet to be found.

Precautions while defect seeding:

Care should be taken during the defect seeding process to ensure that all the seeded defects are removed before the release of the product.
The code should be written in such a way that the errors introduced can be identified easily. Minimum number of lines should be added to seed defects so that the effort involved in removal becomes reduced.
It is necessary to estimate the efforts required to clean up the seeded defects along with the effort for identification. Effort may also be needed to fix the real defects found due to the injection of some defects.

Scenario	Most effective ad hoc technique
Randomly test the product after all planned test cases are done.	Monkey Testing
Capture the programmatic errors early by developers and testers working together.	Buddy Testing
Test the new product/domain/technology.	Exploratory Testing
Leverage on the experience of senior testers and to exploit the ideas of newcomers.	Pair Testing
Deal with changing requirements.	Iterative Testing
Make frequent releases with customer involvement in product development.	Agile/Extreme Testing