Interview Questions

How to find all the Bugs during first round of Testing?

Software QA/Testing Technical FAQs

(Continued from previous question...)

How to find all the Bugs during first round of Testing?

I understand the problems you are facing. I was involved with a web-based HR system that was encountering the same problems. What I ended up doing was going back over a few release cycles and analyzing the types of defects found and when (in the release cycle including the various testing cycles) they were found. I started to notice a distinct trend in certain areas.
For each defect type, I started looking into the possibility if it could have been caught in the prior phase (lots of things were being found in the Systems test phase that should have been caught earlier). If so, why wasn't it caught? Could it have been caught even earlier (say via a peer review)? If so, why not? This led me to start examining the various processes and found a definite problem with peer reviews (not very thorough IF they were even being done) and with the testing process (not rigorous enough). We worked with the customer and folks doing the testing to start educating them and improving the processes. The result was the number of defects found in the latter test stages (System test for example) were cut by over half! It was getting harder to find problems with the product as they were discovering them earlier in the process -- saving time & money!

There could be several reasons for not catching a showstopper in the first or second build/rev. A found defect could either functionally or physiologically mask a second or third defect. Functionally the thread or path to the second defect could have been boken or rerouted to another path or physiologically the tester who found the first defect knows the app must go back and be rewritten so he/she procedes halfheartedly on and misses the second one. I've seen both cases. It is difficult to keep testing on a known defective app. The testers seem to lose interest knowing that what effort they put in to test it, will have to be redone on the next iteration. This will test your metal as a lead to get them to follow through and maintain a professional attitude.

The best way is to prevent bugs in the first place. Also testing doesn't fix or prevent bugs. It just provides information. Applying this information to your situation is the important part.
The other thing that you may be encountering is that testing tends to be exploratory in nature. You have stated that these are existing bugs, but not stated whether tests already existed for these bugs.
Bugs in early cycles inhibit exploration. Additionally, a tester's understanding of the application and its relationships and interactions will improve with time and thus more 'interesting' bugs tend to be found in later iterations as testers expand their exploration (ie. think of new tests).
No matter how much time you have to read through the documents and inspect artefacts, seeing the actual application is going to trigger new thoughts, and thus introduce previously unthought of tests. Exposure to the application will trigger new thoughts as well, thus the longer your testing goes, the more new tests (and potential bugs) are going to be found. Iterative development is a good way to counter this, as testers get to see something physical earlier, but this issue will always exist to some degree as the passing of time, and exploration of the application allow new tests to be thought of at inconvenient moments.

(Continued on next question...)

Other Interview Questions