Logging Bugs: Do's and Don'ts


Bug's Life Cycle
Bug's Life Cycle - [Image source: http://www.bughost.com]

As a tester tests an application and if he/she finds any defect, the life cycle of the defect starts and it becomes very important to communicate the defect to the developers in order to get it fixed, keep track of current status of the defect, find out if any such defect (similar defect) was ever found in last attempts of testing etc.
How to report a bug?It’s a good practice to take screen shots of execution of every step during software testing. If any test case fails during execution, it needs to be failed in the bug-reporting tool and a bug has to be reported/logged for the same. The tester can choose to first report a bug and then fail the test case in the bug-reporting tool or fail a test case and report a bug. In any case, the Bug ID that is generated for the reported bug should be attached to the test case that is failed. Tagging or naming the bug with the Unit or integration test will aid developers to find and analyze bugs more effectively and efficiently.
When to log items?
  • Do log everything. Be very verbose when describing/reporting bugs. It might seem important to you, but this will hep developer to find bugs much quickly. Just because the bug may seem trivial or simple or only happen 'every now and again' does not mean that it should be ignored.  Even it you are not sure it is an issue, LOG IT.  Better to have close off an non-issue then fail to report a major bug in hiding
  • Do include screenshots of any error. This is very important in diagnosing an issue and may be the only aid in cases where bugs cannot be replicated (rarely)
  • Do attached error logs or stack trace  (if any) when logging bugs.
  • Don't assume that someone else is going to fix the issue.  Also, don't assume this issue is too trivial or minor to report.  Wouldn't it suck to find out after the application went lived that you failed to report a critical bug because you thought it was not a 'big deal'?
Providing information on the log:
  • Do provide detailed information about the bug.  Save yourself the headache later and provide as much information as you possible can.  This should include, but not limited to items such as Build Version, Environment, Platform, Short Description of issue, Severity, Detailed steps to reproduce.
  • Don't make provide a single sentence that says something like 'Unable to perform XYZ in the ABC process'.  This type of information will provide nothing of real value to the next guy.  Sure, this would be a great line for the title of the bug.  But by no means is this enough information to fix the bug.
What types of items to log:
  • Do Log Everything.  Enough said
  • Don't make assumptions
When to log bugs:
  • Do log them as soon as possible.
  • Don't put it off.  If you dont log the bug as soon as you find it you WILL forget something about what you did to cause it.  For the sake of your fellow co-workers log it now before you forget.


When in doubt, be verbose - Ferron Hanse
Some content presented was adapted from several sources. A list is included below.


http://devlicio.us/blogs/derik_whittaker/archive/2007/08/19/logging-bugs-the-do-s-and-don-ts.aspx
http://www.buzzle.com/editorials/4-11-2005-68387.asp

Comments

Popular posts from this blog

JavaScript Module Pattern: 2 Forms

Pseudo-Random UUID Generation with mask support

Mocking Ajax with the JQuery Mockjax Library