Zero Defects

When I talk to IT people doing traditional software development about developing software with Zero Defects, I often get blank stares or snickers of disbelief. Do I live in a fantasy land filled with bug zapping faeries and defect free code? Maybe, maybe not. Read on…

Traditional Model

In the traditional software development model, developers build a feature and hand it off to QA to be tested. The QA team tests the feature and discovers a defect. The defect is logged, prioritized, and at some future date, addressed by the development team.

Delays are inherent to this system due to departmental and hand-off/communication issues. Developers have moved on to new features and don’t want to be interrupted. Likewise, QA doesn’t want to interrupt the developers.

At some point after all known “SEV 1” defects are fixed, a decision is made to go into production. The remaining known “low priority” defects may or may not ever get addressed.

Agile Model

In the agile software development model, developers and QA staff work closely together to define acceptance criteria before development begins. They communicate at least daily and whenever questions or issues arise. If QA discovers a problem, it is immediately fixed by the developers before the story is accepted. There is no need to log or prioritize the defect.

At some point, a decision is made to go into production. There are no known defects.

In either model, defects will inevitably be discovered in production. In the agile model, new stories will be created for them, which will be immediately prioritized and fixed rather than being placed on a defect list.