Involving Quality Assurance via the Defect Profile

Published on Author Dan Galorath

Many years ago I was the Software Engineering Manager for an Avionics software company.  Fortunately, I had already been a SEER for Software user for many years and made use of many of the various charts and reports to help manage my teams.  One of my favorites was the Defect Profile.

The Defect Profile Chart “profiles” software defects as they are estimated to be introduced and removed throughout the development life cycle.  The information displayed in the chart is rather remarkable – not only does it tell you how many defects to anticipate but also identifies in what phase they will be introduced.  Considering that any defect found early will save money makes the chart  incredibly valuable.  Here is how I used the chart.

defects

The Defect Profile chart breaks the development life cycle into monthly increments.  By using the Activity Report one can determine what activities are being performed during any given month.  For example – if the Defect Profile chart indicates that during month three there will be 25 defects inserted – I can then look on the activity report to see what activity is taking place.

activities

In this example the team is leaving Preliminary Design and going into Detailed Design.  Armed with this information I can call in the Quality Assurance lead and inform them of the estimated insertion rate.  The QA lead then monitors the design/peer reviews to see how many defects are being captured.  QA already knows it is probable that 25 defects will be introduced – QA can now be more proactive to prevent them.   This process continues through the entire life cycle.

What should QA think if less defects are being removed than the Defect Profile indicates should have been discovered?  There are two possibilities:

  1. The team is performing a better than the model predicted, (not likely if the model was built correctly).  If true, then the appropriate parameters in the model should be adjusted to reflect the improved performance.
  2. The team is not being diligent in finding defects, (the most likely scenario).  QA should review the peer review and code inspection process – first to see if they are being followed and second to see if they need to be improved.  It is often a combination of both – poor process not being followed.

This is just one of the tricks I used while managing programs and it proved to be a popular mechanism; QA enjoyed having a tool to use and the developers liked knowing how they were performing.  It was a win-win for everyone.