Monday, 19 August 2013

How to avoid Testers making mistakes or missing bugs?

Nowadays testers are more recognized than few years ago ... testing areas are more professionals. Lot of companies invest in training their HHRR in specific qualifications (ie. ISTQB, CSTE, etc ...) Which is always good and welcome because it improves testers skills and motivates them. It wont contribute to improve soft skills such as ability to handle stressful situations, or communication with relatives among others.
Teaching to a tester new testing techniques doesn't help to avoid human mistakes. There are more than hundreds known techniques that contributes to test an object from many different ways for example: Assertion Testing, Fuzz Testing, Localization Testing,  Fault Injection ... We can all easily learn them but they cannot guarantee we won't make a mistake.
Then what lot of companies do is to combine with CMM-I, TMM-I, or any other process improvement methodology or software development method to reduce the possibility of a human mistake.

But what it seems to be a fashion is Test Automation to prevent testers missing bugs. For me is not one but a combination of few activities to reduce the change of missing bugs:

* Early Test Planning. If its not possible then minimal test documentation executing negative testing seems to be effective.
* Good test plan. Even identifying testers soft skills and taking advantage of them.
* Test Automation: Whatever is repetitive, Whatever is critical.

There is not magic trick that helps to avoid this or that I'm aware of. So, question remains unanswered, whats the best strategy for you to prevent testers making mistakes while testing or missing bugs?

4 comments:

Involving testers during the actual feature development and even feature specification is key to understand the most important goals of the new feature. It is up to the Product manager (or Business Analyst) defining the feature to include testers in this process as soon as feasible. This will enhance understanding and ownership of the new feature with designated testers.
Robert Westers

It all boils down to a testers ability to understand downstream and upstream impact. This is not something you are able to teach. It's either in your DNA or not!

Interesting answers, then it triggers me the following question: How to successfully identify who's a real tester?

In my recent experience, everything stated is very true. I recognized that testing was only being performed on the "code changed" and not any downstream processes. Plus, the Technical Analysis Document rarely included expected results and/or explanation of how the coding resolution was reached.

Reporting this to the team manager, which had surprised them, with a rewrite in the Technical Analyst Document to provide this important testing information resulted in a new focus on full system integration testing and procedures.