Friday, November 9, 2012

Introducing proper defect management


A defect process, a process where project related defects (bugs) are addressed and resolved, can be run efficient or can become frustrating and very time consuming. Certain people don't take up their responsibilities, certain procedures are not clear and therefore not followed. Defects start flying up and down between parties and start revealing some people's deepest emotional frustrations or  interesting dialogues, sometimes they even carry the only analysis of a certain topic available in the whole program... 
A defect is not an information exchange process, nor is it an analysis addendum or personal ventilation tool. A defect should be clear and unambiguous. The turn-around time of a defect should be quick. Therefore a defect needs to be light and to the point.


Process

The defect status flow is most often discussed. You might be using the companies existing process flow. However, often even if the process is defined, it is not always unambiguously explained. When your company is less mature in testing and test process implementation, it is advised to keep status flows as simple as possible. More statuses require more overhead and result in more confusion.
The 3 main questions you need to clarify in order to describe a defect process are:
  1. What are the circumstances for a defect to arrive in a certain status?
  2. Which role is responsible to treat a defect when it arrives in a certain status?  
  3. What are the next possible statuses a defect can arrive in?


Defect procedures

Defect procedures look into your particular instance of the maybe generic defect flow. Who will take up certain roles? What are the steps to be undertaken in certain situations? Agree on clear responsibilities.
These are, which I found vital defect procedures 
  • Defect coordination board with as main purpose treating defects that are not agreed upon. 
  • Defect retest procedures. Who retests where and how do we know a defect fix is deployed in which environment.

Defect guidelines or instructions 

Defect guidelines or instructions are the good practices you share with all testers and developers when registering a defect. A developer needs to know how to reproduce a defect and a manager needs to see what a defect is exactly about at a first glance.

These are defect guidelines that I find most important:

  • Summary - One line issue description, following a convention of giving the location where the defect occurred and a short and clear description of the defect that occurs: e.g. Billing - Field 'Street' should also accept numeric values 
  • Comments - Comments are added to a defect after them being discussed. No changes are made to a defect without a complete and concise explanation.
  • Prioritization - Define severity, impact and priority parameters unambiguously. The more statuses you invent, the more complex it will become to keep an overview. Keep it simple.

Defect coordination is mainly communication

You can introduce a flawless defect process, defect procedures and guidelines, if they are not understood and carried by all involved parties, your defect coordination is doomed.  When you are to become a defect coordinator, make sure you involve your main stakeholders. The easiest way to do so is to involve them in a workshop and start from a decent proposal. In environments where defect management is new, it often gets confused with production issue management. If defect management is a completely new item in the company, it is recommended to do a dry run with your stakeholders. 


2 comments:

  1. I'm curious about variations in implementation of what you say between small (<20 emp.), medium (20-70) and large (70+) companies. Whereas small companies need a compact and lightweight system, I suppose large companies put more value in clarity and assignment of responsability?

    I think it would be very useful to have a visual diagram of a "default" defect logging framework you propose (ie defects, their parameters, possible statuses, possible status flows, ...). That would make it more concrete, easier to understand and more ready to actually put into practise after reading this post.

    I think I agree on most of what you say, but for a person who does not deal with defect management on a daily basis, it is difficult to fully comprehend.

    ReplyDelete
  2. Hi Dodgedog,

    Thanks for your comment.
    I posted a new blog post to address your question. I hope it helps.

    http://commontestsense.blogspot.be/2012/11/an-example-of-simple-defect-life-cycle.html

    ReplyDelete