Skip to main content

10 statuses you should have in a Defect Life-Cycle


There are different approaches to achieve a proper Defect life-cycle solution with different theories and goals behind each one of them but from my experience most of the solutions that will have the following 10 statuses when implemented will have the better results in improving the final quality of the company’s product:

New
New status will be the first status for a freshly created Defect. This status should be reviewed by leading person like Development team lead or a QA manager and should be then assigned to a specific developer who will fix the problem.
From this status the Defect can become “Open” or “Awaiting Client’s Clarification”

Open/In-progress
Open status exists to emphasize that a specific Defect is in active state. This status means the some actual work is done related to this issue or that some investigation regarding this issue is happening.
From this status the Defect can become “Fixed” or “Won’t Be Fixed” or “Awaiting Client’s Clarification”

Postponed
In case that some constrains of the current release preventing the development department from fixing a specific Defect this Postponed status is used to symbolize the fact that this issue will be fixed in the future.
From this status the Defect can become “Open” or “Won’t Be Fixed”

Awaiting Client’s Clarification
Awaiting Client’s Clarification status indicates that the issue raised by this Defect is requirement related and requires client feedback as whether it is an actual problem or not.
From this status the Defect can become “Open” or “Won’t Be Fixed”

Fixed
Fixed status is self explanatory and represents the fact that the Defect had been fixed.
From this status the Defect can become “Re-Open” or “Fixed – Postponed” or “Fixed – Closed”

Fixed – Postponed
Fixed – Postponed status existence is to provide the option to mark a Defect as fixed but emphasize the fact that it had not been verified by QA in the last test cycle. As a common practice this status should not be used and it should be kept for extreme situations only when because of some constrain this unusual situation happened.
From this status the Defect can become “Re-Open” or “Fixed – Closed”

Fixed – Closed
Fixed-closed status is to communicate the fact that a Defect that had been fixed by development had been verified by QA as well and the fix is fully accepted

Won’t Be Fixed
Won’t be fixed status is used to categorized two types of Defects: those that are not actually a Defect and had been created by misunderstanding of client’s needs, and those that represent a problem that to costly to fix when compared to the benefit of the actual fix.
From this status the Defect can become “Re-Open” or “Won’t Be Fixed – Closed”

Won’t Be Fixed – Closed
Won’t Be Fixed-closed status is to communicate the fact that there is an agreement from QA side with the fact that this Defect shouldn’t be dealt with, and no more future work will be invested in this issue.

Re-open
Re-open status come to emphasize that it isn’t the first time that this Defect is reaching the development. This status can be a result of a “Fixed” status when the fix had not been complete, or it can be a result of “Won’t Be Fixed” status when there is a disagreement from QA side that this Defect is not important enough.
Note: Re-opening a Defect it is critical move and it should always be done with detailed comments explaining the reasons for it.
Labels:

Comments

Post a Comment

Popular posts from this blog

Proper QA estimation in Agile project

  Today, I want to chat about a common issue in Agile development – story point estimation. You see, it's easy to get caught up in estimating how long a feature will take to develop and forget about the crucial Quality Assurance (QA) effort.  It happens to often: your team is in the middle of sprint planning. New user stories are being discussed, and estimations are given, but there's a catch. You've estimated the development time perfectly, but you've barely even glanced at how much effort QA will take. Why? Agile talks about Development Team and you mistakenly thought that it is all about DEVELOPMENT. Sound familiar? Trust me; it's a more common scenario than you might think. So, what's the big deal? Well, when you leave QA effort out of the equation, several not-so-great things can happen: Vilocity can suffer: You might think you can squeeze more into a sprint than is humanly possible, setting your team up for disappointment and overcommitment. Quality can de
Post a Comment
Read more...

Performance testing vs Load testing vs Stress testing

Today I want to discuss a popular topic regarding a difference between Load and Performance testing. Those two types of testing are commonly used together but there are several key differences between the two. To get a better understanding of the topic lets have a real life example from one of my clients and use it to explain the difference. I have worked for a client that was building an in-house web application that provides its customers with an option to select and order different products and services. The request was, before the up-coming release, to test the performance of their product. We started the task by trying and understand what they expect from performance point of view and then went through an exercise of defining what is captured by what test. The client said that they are looking to have about 900-1300 active users on the site at a given moment, and the expected response time (for a page to load) should be less than 5 seconds. With those details what are the t
Post a Comment
Read more...

What is the velocity of an Agile scrum methodology?

Let's discuss some of the important measurements in Agile, and that is the Velocity of the Scrum team work. Based on Wikipedia definition Velocity is " ...the rate of change of its position with respect to a frame of reference and is a function of time...", which when transferred to the scrum world can be summarized as: The amount of work that the scrum team completed in a single measure of time - in a sprint. How we Calculate Velocity? Velocity is actually a very simple to calculate, it is done but totaling the number of story points of fully completed user stories from the sprint backlog. So if a current sprint included 4 user stories: 2 with 8 story points each, one with 3 story points and one with 32 story points. and by the end of the sprint the 32 one was not fully done the velocity calculation will be: 8+8+3=19 Note: the 32 story points are not part of the velocity calculation as this user story was not completed. What Velocity is used for? The v
Post a Comment
Read more...