A better way of handing Defects

For years I viewed defects as fights because that is usually what they turned into. And I hated it. Developers view defects as an assault on their reputation. Every defect opened is testings way of saying "you're not perfect." So developers took it personally and came into defect meetings with guns loaded. More show-stopper defects or the greater the volume of defects usually meant the bigger the developers guns became. As the "Quality Gatekeepers" of the project Testers needed to bring in just as much ammo because it was our perceived job to ensure these defects were resolved. Numerous grenades were thrown and numerous defects went into production.

Then I began working on agile projects. At first I was shocked by the lack of defects; both in the low number of defects coming out of development and the fact that none were logged. Being new to agile I decided to roll with this and see how it played out. To my amazement, it played out just like many agilistas said it would: working code was delivered faster. They were quick to point out that it took longer for me to log and manage the defect than it did for me to have a conversation with the developer and get it fixed. I actually timed this at first to check. To my amazement, it was true. And it wasn't a fluke. It happened again and again. There weren't many defects. But when there was they played out just as the agilistas expected.

The other thing that was amazing to me was how fast we were able to find the problem. This was due to the test coverage on all layers (Unit, Integration, GUI). Defects aren't about just finding a problem. Defects are about finding where the problem is. And this testing stack did a great job of layering and finding precisely where the problem was. 1 or 2 new Unit Tests, an Integration test and a GUI test later and we had working code.

With less of a need to focus on what is broken or where, I would like to propose a different approach. When a defect arises, in waterfall or agile or any other SDLC, get it fixed. But focus your questions and research more on the process which caused the defect to be created in the first place. If the root cause was a requirement miss, what can you do to prevent requirement misses in the future? Is there a coding miss? What can you (or dev) do to prevent coding misses in the future?

This approach worked wonders for me. My team was able to find that test cases were not being fully flushed out for higher risk features. By bringing the entire team to the Amigos we were able to better determine risk levels and better flush out test cases. And defects all but went away.

Focus on the why, not the what...