The Job of Testing

How would you respond to the following question?

"What is the job of testing?"

• I rejoiced each time I or a teammate found a defect and patted ourselves on the back with each one that we reported.
• I included the number of defects we discovere
d in my individual performance appraisal for many of the projects that I tested.
• I understood vaguely that the cost of fixing defects rises if the defects are detected later in the SDLC.
• I thought that up-front quality was a developer responsibility which led to random fantasies of "...I hope they do some unit testing."
• When I participated in walk-throughs of requirements and design documents (many times I did not see these documents until after they were approved), it was difficult to shift gears from a different project that I was actively testing. I did not prepare for the reviews and often multi-tasked as the reviews were facilitated.

"A quality assurance organization should champion processes that build quality into the code from the start rather than test quality in later."

1. I started logging the defects detected and removed as we improved the requirements, design, and testing artifacts and championed static testing to increase the focus on the document reviews.
2. I collected defect metrics for each project and shared the results with our business partners after each project.

1. Defect Discovery Rates (percentage of total defects discovered during static testing, system testing, and production)
2. Defect Leakage % (percentage of requirements and design defects leaking into test or production)
3. Defect Detection % (percentage of defects discovered before implementation – an indicator of the overall effectiveness of the combined static and dynamic testing)

"Inspections give you a double hit – not only are they the best for defect removal, but they are very effective for defect prevention, because the people that participate in inspections stop making bugs in many categories"