How to Report a Bug

A Bug report template may vary from tools to tools based on the tool that is been used. If you are writing bug report manually then some of these fields need to be mentioned specifically Bug number, Priority, Assigned to should be mentioned manually.

"Every time you report a bug, you should explain how exactly the product is broken."

1. REPORTER:

   The name of the Bug reporter and email ID.

2. PRODUCT/ PROJECT NAME:

   Name of the Product In which bug was found.

3. RELEASE NAME/ VERSION:

   The Version of Product if any.

4. MODULE NAME/ COMPONENT:

   These are the major Sub- modules of the product/ Software.

5. BUG STATUS :

   The status of the which can be changed based on the timeline and action that is been taken place.

6. SEVERITY:

   The Severity indicates the Impact of defect on the Product, The Severity of Bugs should be written. i.e., LOW, HIGH , CRITICAL , BLOCKER , TRIVIAL.

7. PRIORITY:

   A Bug can be LOW, HIGH , CRITICAL , BLOCKER , TRIVIAL. The Priority of Bugs should be written based on Severity/ Criticality of the Bug can be given from P1 to P3 where P1 having HIGH priority and P3 having the LOW priority. So the important ones are viewed first.

8. PLATFORM/ENVIRONMENT:

   OS and Browser configuration is necessary for a clear bug report. It is an effective way to communicate how the bug can be reproduced. Without exact platform or environment, the application may behave differently and the bug at tester's end may not be replicated at Developer's end.

9. ASSIGN TO:

   The name of the Bug Assignee and email ID.

10. TEST ENGINEER STORY POINTS:

    Time taken to test the bug from test engineer point of view.

11. DEVELOPER STORY POINTS:

    Time taken to fix the bug from Developer point of view.

12. TEST URL:

    URL of the page where the bug appears/ occurred.

13. SUMMARY:

    A Brief Summary of the bug, This should be within 60-80 words giving a entire summary of the problem on where the problem is and what the problem is about.

14. DESCRIPTION:

    A detailed description of the bug.

Use the following fields for Detailed description:

• STEPS TO REPRODUCE THE BUG-

Clearly, mention the Steps to reproduce the issue.

• EXPECTED RESULT-

How the application/ product should behave when a certain action is performed on it.

• ACTUAL RESULT-

What actual result is reproduced after performing the mentioned steps i.e., the behavior of the bug.

TEST EVIDENCE-

The proof/ screenshot/ screen record to show the occurrence of the bug and it's behavior. Highlight the unexpected behavior. This will help in drawing the attention to required area.