How to keep track of the defects: most common defect statuses

I find that one of the biggest challenges in a team is to get everybody on the same page regarding defect life cycle and statuses. People bring different knowledge and skills to the table, as a QA lead you have to come up with a common process that everybody agrees to follow.

Logging a defect and keeping track of defects is so different when you ask Maria and when you ask John. Hopefully, when you start your first job as a tester, you’ll be lucky to land in a team that follows the same process; but if you’re not, here’s what you should know:

The most common defect statuses are:







1. When you first log a defect the status is New. This status can be assigned automatically if you’re using a tool like Mercury Quality Center or by you if you use a tool like Excel.

2. You assign the new defect to the developer.

3. Sergey, the developer, analyses the defect and concludes that indeed, it is a defect. He changes the status to Assigned and he begins working on resolving the problem. If your defect is not reproducible or it is not a defect, Sergey will reject it and assign it back to you.

4. After some time (can be hours, days, weeks) Sergey does a “code drop” and then marks the defect as Fixed and assigns it to you for retest.

5. You will now close the defect or reopen, depending on the result of your retest.

This diagram will help you remember these steps. log-defect-process-jpeg


It is very important that everybody involved follows the same process. If only one person does not mark the defect with the appropriate status, the cycle is broken. You have to use other resources to find out in what stage the defect is.

I find this is a process that is almost never followed when testers use Excel to record the defects. It is very much related to how much importance management gives to keeping track of the defects. Being part of small teams where people communicate on the phone or by email is also a cause of not caring about proper defect tracking. Or it can be just pure laziness…


What’s a “code drop”? Simply put, there are two test environments used: Dev and QA. Developers first check their code/fixes in Dev environment and then, if everything works, they promote the fixes into QA. That’s where the testers retest the fixes. The “code drop” refers to the action of promoting fixes to QA.

See an example of defect tracking spreadsheet and of a test execution report.

What you can do with a testing tool like Mercury Test Director?

Will a test tool resolve your problems?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s