Bug Reporting

Bugs are treated as “Bread and Butter” for testers in IT World, the more they find – they live on and raise their living.

If you are new to QA/Testing, You need to log the bugs on the product you are testing.

So at first you will try to find any template the department/ organisation has. If not, you will search at power searching tool i.e. Google. And you find so many bug reporting sheets.

Q: Is there a standard template for reporting bugs?

A: No, There is no standard template.

Q: What all to be logged in the bug?

A: The following are the bug attributes which needs to be used for logging the bugs.    (This is not limited)

1.    Bug Id – This can be referred as bug id and should be in a particular format.

2.    Title – Short and meaningful title which gives exact problem statement.

3.    Description – Descriptive Summary of the Bug: what the bug is, how it is reproduced, the effects of the bug and the areas that are affected by that bug.

4.    Expected Results – What was expected as a result of this test

5.    Actual Results – What is the actual result, which the application is resulting?

6.    Severity – The severity of the bug is rated depending on the level of the bug it effects the application.

Different types of Severity levels:

·         Critical

·         High

·         Moderate

·         Low

The Severity levels are listed depending on the organisation you are working.
If they do not have, create your own list of levels.

7.     Business Priority – Speak to the Product owner / manager, explain the bug and rate the priority level. This is an optional one.

Different types of Priority Levels:

·         High

·         Moderate

·         Low

8.    Detected By – Detected Date – Assigned to – Assigned Date – Reviewed By – Reviewed Date

These are the additional attributes, which can help bug reporting tool look in organised way.

9.    Module – The module name in the application under test.

10. System Specifications – This depends on the type of test, if we are testing a website application: The specifications would be browser type, browser version.
If we are testing a windows application: The specification would be Operating system with version number, RAM, CPU etc.

11. Associated Test Cases – Specify the test cases which fail as a result of this test. This clearly shows the traceability of the test cases and helps to fix and run minimal test runs.

12. Build Number – The Product Build Number which is responsible for this bug.

13. Environment – In which environment, this bug has been found.

E.g.: Development Environment / Testing Environment / Production Environment.

14. Attachments – This is optional. Attachments such as Screenshots can be useful (Before and after).

15. Status – The status depending on the Defect Life Cycle.

Different Types of Status:

The following are the different types of status, which can be used in logging the Bug.

·         New

·         Open

·         Fix

·         Differed

·         Close

·         Re Open

·         Can’t Fix

16.  Remarks – Any remarks to specify as a result.   

From my experience, the more we give clear information, will be easy to developers:  to recreate, investigate and fix the issue (Hopefully in less time).

There are different approaches that can be helpful for logging the bugs: Like, Video Recording, Screen Shots etc. This can help the developers to understand the way the software tester has logged the bug.

(This Blog post will be Updated.. As I Learn)

Quote of Day:
"The Key is not to prioritize what's on your schedule,but to schedule your priorities" - Stephen Covey