The other day I took some time to read a case-study written by RSnake entitled Death by 1000 Cuts. The study was interesting in the fact that a small pile of 10 minor and medium defects turned into 1 large security issue. It’s a good read and I suggest it if you have 5 minutes on your hands.
Before I even started reading the study the term “Death by 1000 cuts” hit me. This is the perfect term that I had looked for so many times in the past to explain an out of control project with tons of minor defects, the release date around the corner, and the implementation that was going live no matter what. The 1000 cuts in this case being the dozens and dozens of low severity defects that when put together made a pretty crappy looking and feeling Web site.
When the project has a customer weighing in like 800 pound guerilla holding tight on promised release dates, the over-worked development team tends to get the high severity defects fixed first and the low severity defects are quick to be ignored by developers and project managers by abusing the leniency in the defined QA Exit Criteria:
Severity 1: Zero remaining defects.
Severity 2: Zero remaining defects.
Severity 3: To be agreed on by the QA Lead, Project Manager and customer. Depending on the agreement of the disposition of these defects, this status could possibly delay QA exit.
Severity 4: To be agreed on by the QA Lead, Project Manager and customer. However, defects of this severity will not delay QA exit.
As mentioned before, a large pile of Severity 3s and 4s in a Web site can simply suck. Sure, for the most part it works and the user can do what they need to do, but the overall user experience can be just plain horrible. Don’t let your project die the Death of 1000 Cuts due to guerilla tactics and bad QA exit criteria. Create strong exit criteria (stronger than listed above) and stick to your guns. I did, and the defects at go-live turned from several dozen to a few.