Podcast Notes: Managing Software Development - Episode #3 Defects

The Managing Software Development podcast was by James Edgell and came out in 2008. I actually found it was a useful series of podcasts and was disappointed that the series did not run for very long.

I am combining my notes from this podcast with experience I have had. For about four years, I was in charge of tracking, prioritizing, assigning and testing bugs/issues at my organization. I actually had thoughts of creating a QA team, but changes in the organizational structure and my position have led me away from focusing strictly on testing and issues. However, I still am involved in this role on a minor basis every working day.

• Defects add risk to your products but can assist in making product improvement. – No client wants to have to deal with daily defects in a product. While no product is perfect, the more defects can be eliminated, the happier the clients are. Learning from defect resolutions allows you to develop a stronger product and avoid issues in the future.
  
• Defects can tell you a lot about a team. – I agree with this, but feel even more strongly that developer responses to defects can tell you even more about a team. Having developers that are interested in making the product as strong and error free as possible enables the testing and support and business development areas of the company also work more efficiently and with less stress.
  
• Daily or weekly bug meetings help you keep on track of open defects and making sure that impact and severity levels are set correctly. – Until a product is fairly stable, keeping on top of issues and resolving them in a timely manner is critical towards keeping satisfaction with the product at a high level.
  
• Prioritize defects. – Prioritization allows the testing team and development team to focus on the most critical issues at the moment. Putting out small fires is much easier than dealing with an out of control fire in a windy, remote location. The same thing applies to defects – take them in order and get the worst fires out and keep them from growing and engulfing all the efforts of your organization.
  
• Make sure defect resolutions are thoroughly tested before rolling out to clients. – You really don't want to let a client know that an issue is resolved, only to have them call you back and state that they still see it. Taking pride in your product and your work should show and this is one of the ways to make it shine.
  
• Having a "Monitor" state for defects when a defect is intermittent or cannot be reproduced. After x number of days, status moves to terminate. – This allows developers to focus on critical issues, but also allows you to keep track of potential issues, especially if they become less intermittent. On a side note – there is nothing like finally finding a way to reproduce a pesky issue. I can testify this produces shouts of joy and happy dancing all around.
  
• Having a "Terminated" state for defects – defect is being reported, but is actually working as defined or is a duplicate.
  
• If defects are not being found – testers are not doing their job. You shouldn't be releasing until the chart of defects starts to flatten out. – Does anyone really believe they have a perfect product and that there are no issues? If so – you might want to incorporate some drug testing for your staff members.
  

We still have not found a perfect method of tracking bugs, but there are many software programs out there that will help make this process more effective. Defects are inevitable – dealing with them is critical – avoiding them is just not allowed.