Defects can help creating Quality

Even if software defects are not considered as ‘normal’ (see: Is Software with Zero-Defect Quality possible?), every defect is a chance for improvement.

For each defect a root cause analysis should be performed. This does not mean superficial causes like ‘programming error’. A proven method for the root cause analysis is ‘5 Why’, where you ask multiple (not necessarily five) times for the reason. Only when you reached the beginning of the cause-and-effect chain that there is no practical answer to the ‘why?’ question, the root cause most likely has been found.

At this point it is important that the root cause of the defect matches with a defect category. The list of defect categories should be standardized company-wide. Technically these categories can be implemented as a pick-list in the ticketing or defect tracking system. The standardization is the key for evaluations like categories which are defect hotspots, which is important to see where improvement measures are most effective.

With knowledge of the root causes improvement measures should be found which prevent the recurrence of such defects. This can be improvements of the constructive quality assurance, e.g. development methods or tools, possibly changes of the team, or regarding other areas. Of course there may be some defects which can not be prevented in the future by any measures.

A continuous improvement process on basis of defect analyses will only work if anybody is responsible for the communication of the found measures, plans their implementation, keeps track of it and checks the effectiveness after implementation.

This process, which similarly is in use in the car industry since the 70s, helps preventing defects in the future, which is a better investment than in analyses, tracking and corrections of defects. In other words: It creates quality.