Culture

Surprisingly, when it comes to reducing the number of defects, your organization's culture is often the biggest challenge that you will face. There are many assumptions that organizations make about defects. Such as "all software has defects", "it is impossible to write software that does not contain defects", or "we do not care enough about defects"; "it is someone else's job to find defects" is also something that you may hear.

Each of these assumptions are not true. For example, even if the reality is that some defects will exist, it is still possible to have software that does not have many defects. The goal is to create software with zero defects. It is therefore important that your team recognizes that it is possible to write software without defects and that as a team, it makes an effort towards that goal. If your company does not seem to care about defects, this does not mean that you or your team cannot care about them.

Everybody on your team is part of that effort. Developers and testers can find the same defect, but in different ways (unit testing versus acceptance testing). It does not matter who finds the defect as long as that defect gets found and then fixed.

Some companies say "we don't have any priority 1 defects." Does that mean that you do have priority 2 defects? When defects are categorized, it is a way of accepting that some defects will not get fixed. A priority 1 defect is a type of defect that shows up in an area of the application that customers use all the time. A priority 2 defect is a type of defect that shows up in an area of the application that customers use less often (or even much less often); however, this does not mean that it's acceptable for the area of the application that is used less often to be of less quality than the area that is used all the time.

If your team does not learn how to eliminate defects, they will keep showing up. If your team does not learn to fix all defects, then only part of your application can be considered of high quality.