A bug’s Afterlife

The question is similar to a question Nachiketa asked to Yama, the god of death. “What happens to the soul after death?”

The answer is: “None cares. It is just there till someone digs out a bug to prove a point on someone.”

And that is why Quality doesn’t improve.

Even the famous state transition diagram of Bugzilla doesn’t address one crucial point – there IS an afterlife of a bug! As a matter of fact, a bug may have many afterlives.

  1. Afterlife #1: A bug filed by a support/escalation engineer, found at a customer site
    1.  The purpose of such a fix is to work at the customer site, right? So conscientious QA keeps the bug in “Resolved” or “Verified” state and marks it as “To be Verified at the Customer Site” or similar phrase. It is the duty of the support engineer dealing with the customer to actually verify and close it
    2. Fixing a bug reported from a customer is often not sufficient. It is also advised to go out and declare that a defect has been addressed. This means Documentation team has to take notice of such a bug and include it in the next version documentation. So a clone of this bug must be assigned to the Documentation team
    3. Such a clone needs to be verified too, right? Typically a QA verifies such a documentation bug and closes it
  2. Afterlife #2: A “good” bug found by anyone
    1. Depending on the nature of the bug, the scenario may turn into a valid test case. So such a bug must be cloned as an assignment to a QA engineer to convert into at least one test case
    2. Such a test case needs to be verified and closed by QA too
  3. Afterlife #3: A “good” bug that has turned into a test case
    1. A valid test case is likely to get converted into a test script. So a bug may also clone for assignment to a test automation engineer
    2. Such automation needs to be verified by QA too

Here, cloning isn’t the only option but because a bug may split multiple ways – customer support, QA, automation and documentation, it is best to clone the bug and let each department worry about its further life cycles.

This is one of the reasons I disagree with ignorant non-QA (and also ignorant QA) folks who claim: “QA’s job is to find bugs”.

What do you say?


Leave a Reply

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

WordPress.com Logo

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s