reducing production defects

Defect Tracking: Getting the Right Data at the Right Time

Software executives constantly play the game of balancing extra detail with extra overhead. Most software efforts eventually trend towards the latter, as budgets dwindle and deadlines loom. Eventually, a company may adopt a policy that is too far in line with the finance department and not enough with quality control. However, defect tracking, if properly implemented, has the ability to benefit development rather than slow it down.

Tracking in Preproduction

One of the best ways to completely avoid the friction between financing and quality is to bolster the defect tracking process in preproduction. The defects that occur upstream are usually the easiest to fix for many reasons, including the following:

  • Early defects (that are caught) cannot affect later programming, which will undoubtedly be more complex
  • They are the easiest to find, because there is less overall code
  • They provide the greatest ROI – finding small defects early limits large amounts of technical debt and fatal errors later on

Use Defects to Compare Performance?

There is one fatal mistake many companies make when they decide to track defects in preproduction:  using this standard as a comparison benchmark. Coders who are knowingly judged by that standard will likely seek out easier defects to look better in front of management. You can also get into some very technical and useless arguments about what constitutes a defect, especially with people who feel their jobs may be on the line.

Management must be personally involved in defect tracking from the beginning of the process. The company must not give into the temptation to manage by spreadsheet, creating a false comparison baseline that will slow down production instead of improve the build.

The Right Data at the Right Time

Combining defect testing with exploratory testing is the more successful way of providing for additional defect testing while preserving and improving team efficiency and time-to-market. Coders should focus on the defects that are actually reducing productivity in the build. Management should focus on prioritizing the removal of the defects that are most important to the project. A great compromise is to reduce the tracking of some of the feature level defects if time is short, especially if there are not a great deal of release testing defects.

Understanding the patterns in defect tracking is the most important aspect of retaining efficiency while improving quality. Ideally, defects that will weigh on the final product should be prevented rather than tracked. If tracking begins in preproduction, and all aspects of production are coordinated through management, patterns should emerge that can be addressed.

Following the Fundamentals of Successful Defect Tracking

It is essential to ensure that everyone is on the same page when tracking defects. Although methodologies will differ based on product, team skill set and available resources, the basics are usually the same:

  • Defining a defect through information capture – In preproduction, management should sit down with the dev team and determine the amount of information that defines a defect. This process should be simple enough that its use is not limited. However, it cannot be so simple that it glosses over important information.
  • Determining when a defect fix is a priority – If a user can reproduce a defect, this usually verifies that it has been fixed. Defects that cannot be reproduced usually take a lower priority. They may be addressed if there is extra time in the schedule.
  • Environmental concerns – One of the more frustrating aspects of passing defects through departments is determining whether that defect can be reproduced in different environments. Before the quality assurance team passes along a defect to be fixed, they should be completely sure whether the defect is Android-specific, only occurs on iOS, etc.
  • Scheduling defect tracking – Prioritizing the severity of a defect is an important part of managing future defects. Team members may be less likely to follow-up on certain leads if that information is routinely dismissed by management as a priority. This is why management and the dev team must work together so closely in preproduction to define what is most important to track.
  • Open lines of communication – Those who are responsible for fixing defects should be able to report back and suggest improvements to those who find defects. A one-way line of communication is a quick way to a less successful defect removal process.

Best Practices for Quality Assurance

Make sure that your developers are following the same defect tracking methodology as your testers. All groups deserve the right to express feedback.

User should be able to report defects easily, but criteria should be set up from the beginning to focus their efforts on the product components that have been prioritized by the company. A caveat: Do not be so blind to user feedback that you are not willing to reprioritize if a certain defect is found to overwhelmingly affect the user experience.

Finally, make sure that input screens for each stage of the defect reporting procedure reflect only the relevant aspects for that person or department. Simplicity is never wrong when it comes to getting the right data at the right time.