This type of testing is done without any formal Test Plan or Test Case creation.
Ad-hoc testing helps in deciding the scope and duration of the various other
testing and it also helps testers in learning the application prior starting
with any other testing.
A D V E R T I S E M E N T
It is the least formal method of testing. One of the
best uses of ad hoc testing is for discovery. Reading the requirements or
specifications (if they exist) rarely gives you a good sense of how a program
actually behaves. Even the user documentation may not capture the “look and
feel” of a program. Ad hoc testing can find holes in your test strategy, and can
expose relationships between subsystems that would otherwise not be apparent. In
this way, it serves as a tool for checking the completeness of your testing.
Missing cases can be found and added to your testing arsenal. Finding new tests
in this way can also be a sign that you should perform root cause analysis. Ask
yourself or your test team, “What other tests of this class should we be
running?” Defects found while doing ad hoc testing are often examples of entire
classes of forgotten test cases. Another use for ad hoc testing is to determine
the priorities for your other testing activities. In our example program,
Panorama may allow the user to sort photographs that are being displayed. If ad
hoc testing shows this to work well, the formal testing of this feature might be
deferred until the problematic areas are completed. On the other hand, if ad hoc
testing of this sorting photograph feature uncovers problems, then the formal
testing might receive a higher priority.