What is a Bug?

14 Sep

It’s becoming clearer and clearer that there is a lot of confusion around what a bug actually is.  How many times have you heard “That’s not a bug”.  Although we can go into an extended discussion around the difference between a Defect, Bug and an Error2, for the sake of expediency lets assume we are referring to the same thing.

It seems like in today’s world when a tester raises a bug it is assumed to be an issue with the developers code but the fact is a bug is simply product of an unexpected result.  It seems like such a simple thing until one ponders all the possible reasons for an unexpected result.

  1. Developer/Code
    1. It is a development/coding error
    2. It is an unpredicted scenario/combination
  2. Environment/Configuration
    1. It is a deployment issue
    2. It is an environment/data issue
  3. Requirement/Analysis
    1. It is an incorrect requirement
    2. It is a missed requirement
    3. It is an incorrectly managed change request
    4. Non-functional requirements
  4. Test
    1. It is an incorrect test
    2. It is a misunderstanding

(the list really does go on)

None of these examples negate the relevance of the defect at hand.  I can only assume that anyone reading this knows the story of the first bug ever found, erroneously attributed to Grace Hopper:

In 1946, when Hopper was released from active duty, she joined the Harvard Faculty at the Computation Laboratory where she continued her work on the Mark II and Mark III. Operators traced an error in the Mark II to a moth trapped in a relay, coining the term bug. This bug was carefully removed and taped to the log book. Stemming from the first bug, today we call errors or glitch’s [sic] in a program a bug.

Pasted from <>

This is a perfect example of the fact that a bug is not necessarily the fault of anything or anyone in particular but may be the result of a particular set of circumstances that couldn’t have been predicted or managed.

Regardless each “issue” needs to be discussed, validated, prioritised and an appropriate plan for resolution needs to be defined, including assigning to the correct owner to ensure it is resolved.  This is the purpose of Triage4,5,6.

After all, it’s all about a product/project being released with Quality and Quality is owned by everyone, right?

More Reading:

Leave a comment

Posted by on September 14, 2011 in Quality Assurance


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 )

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

%d bloggers like this: