Monday, November 19, 2012

Tester's friend - The BUG

Every normal human being gets pleasure while finding mistakes in others, sad, but true. Tester is also a human being and when he/she finds a bug, it further motivates him/her to find more. A tester aims to fail the software in any way possible, and tester succeeds when bugs do appear. I do not worry about the theoretical definition of bug; to me, anything that the software does in a manner that is not intended as per specs or by implied needs, is a bug. Hence bug, error, problem, issue, failure etc. all come under the same category, though you can find zillion definitions for these words if you google.

When a bug appears while you test, do the test again. Ensure it appears again. This will prove that, you as a tester, had not done any mistake in executing the test. Soon after confirming its consistent nature, do not call the developer. Developer has a tendency to reject or dispute. Do not send a mail either. You need to ask a few questions to yourselves before you formally state that it is a bug. 

Try to describe the bug in 1 line. This is like writing the email subject. "User does not get confirmation email after registration", "Application accepts invalid SSN in Add Customer Page". Try to convey the exact problem with minimal words.

Mention the screen name where the bug appears. This will help the developer directly to go to that place, without wasting time. If possible, take a screenshot where the bug appears. A picture means more than 1000 words.

Explain the bug in detail, by telling the steps to reproduce. You get bugs when you execute a test case. Thus, the bug must be appearing against one of the test steps. Copy paste the test case itself and mention the exact problem against the test step. If the developer does the same thing, he/she should get the same bug.

How does this bug affect the product? The answer to this question will help you to set the Severity of the bug. Are you able to proceed further to do other test cases? If not, this bug is termed as a Show Stopper or Blocker. This means, you have no way to test anymore unless development team fixes the same. 

Is there a crash or data loss or a feature is missing in the product? This falls under High or Major category, provided you are able to do other tests. This means, that the product has a serious problem. For example, when we page customer details, Save operation itself does now work and hence the data entered is lost. Technically a developer may say that he can fix this in 2 minutes, but always look from customer's angle. For the customer, data is more important than the product itself. Any loss of data is a major bug. The severity code Major is also termed as High in many companies.

Bug does not stop me from testing, there is no data loss or crash, but the functionality is wrongly implemented. The app saves data, but some part of the results are not accurate. In this case, companies usually treat this as Minor or Medium severity.

The app does the job, but there are spelling mistakes or improper messages to users or imporper field alignments in the UI. Usually companies treat this as Cosmetic or Low severity.

To sum up, if we can write the following, then we are good in reporting bugs to dev team.
  • One line description of bug
  • Details to reproduce the bug
  • Screen name where the bug appears
  • Screenshot of the bug
  • Severity of the bug
By principle, every problem must be reported and tracked. We will see tracking mechanism in the next post. For more details on bugs, please see this bug tracking demo.


  1. Testing explained in simple and lucid terms. Best wishes

  2. Thanks for sharing such a knowledgeable article. But I like to ask how many companies follow such steps to log bugs? Can some professionals share their experiences?