Ad hoc testing is a term commonly used for the tests carried out without planning software and documentation.The tests are intended to be executed only once, unless a defect is discovered. This is part of the exploratory test, which is the least formal of test methods. In this context, it has been criticized because it is not structured, but it can also be a strength:

the important bugs can be found quickly. It is performed with improvisation, the tester tries to find bugs with all means that seem appropriate. This test is most often used as a complement to other types of tests such as regression tests. We affirm that the ad hoc test is a special case of Exploratory Testing. During the exploration testing, we will find a large number of ad hoc tests cases (one-off tests), but some will not. One way to distinguish between the two is to examine the notes associated with an exploratory test. In general, exploratory tests have little or no formal documentation, but the result and more notes. If the notes are detailed enough that the test can be repeated by reading, the it is less likely to be an ad hoc test. Conversely, if there is no note for an exploratory test, or if the notes are intended to guide the efforts of more tests to reproduce the test, then it is almost certainly an ad hoc test.

Where it fits in STLC:

It finds its place throughout the test cycle. From the beginning, this trial offer extended to testers' understanding your program, which helps in the discovery of early bugs. In the middle of a project, the data used to set priorities and timetables. As the project moves closer to the date of shipment, it can be used to examine defect fixes more rigorously, as described above.

Strengths of Ad-Hoc testing

One of the best uses of this test is to discover early bugs. Reading the specifications or requirements (if any) you seldom get a good idea of how a program behaves in fact. Even the user documentation May not capture the look and feel "of a program. You can find holes in your testing strategy, and may explain the relationship between sub-systems that would otherwise not be obvious. In this way, it serves as a tool for verifying the completeness of your tests. Lack of cases may be found and added to your arsenal of test. Find new tests in this way can also be a sign that you need to perform root causeanalysis. Ask yourself or your test team, "What other tests in this category should we be running?" Defects found by testing are often ad hoc examples of whole categories of forgetting the test case.