Trust your instincts, switch to ad hoc testing

As a QA manager, I have to constantly evaluate the most fundamental aspects of testing in my project that is finding bugs in the code. What if you implement the well designed and created test plan and still do not find bugs. Or you simply encounter resource and time problem, where early detection of bugs is much more important than following the process finishing the automation for example). I talked about exploratory testing in one of my previous posts. Exploratory testing is a informal testing which is totally different from the formal testing paradigm where emphasis is on reuse such as acceptance and regression testing. Ad hoc testing is considered by many as aimless black box testing approach, but its contextual. In many situations ad hoc testing can be very useful.
So what is an ad hoc test?
An ad hoc test is a case which you run only once unless it uncovers a bug. A primary goal of ad hoc testing is to uncover a new bug in the product. If exercised by highly experienced tester it can be very effective. To put into perspective, each testing method's strength and weakness can be measured in terms of defect finding power and confidence building. Ad hoc tests are supposed to have high defect finding power but low confidence building attributes.
Ad hoc testing approach:

• Pair testing - This is a kind of improvisational testing where two people collaborate and work together on finding bugs using ad hoc testing. The improvisation of originally planned testing document can be very useful when done by group. Improvisational testing is also very useful when verifying a fixed defect.

Advantages of ad hoc testing:

• Discovering missing testcases - can find holes in your original testing strategy that can be incorporated later.
• Gives more understanding of how program or feature behaves which may not be known by reading external designs.
• gives better understanding of the testing priorities, for example if an ad hoc test runs very well, you can decide testing in that area can be deferred to the later stage.

So, how do I do ad hoc testing effectively?

Ad hoc testing is challenging because its highly intuitive and has very less logical structure. 

1. First take a paper and pencil and note down most important thing you want to know about the code and specifically what you want to achieve in how much time. Also what you are going to do if you do not find a problem.
2. Understand the design goals and requirements for the low level function you are going to test. what choices and assumptions were made by developers when they designed the function. What are the weaknesses of these choices and see if you can exploit them.
3. Read defect report for similar or same project. what kind of problems developers or other team are finding. Expand your horizons in breadth and width. For example running your ad hoc test on optimized/profiled build or on different platform.

More, as we progress on our own exploratory tetsing...until then keep testing !