Ultimate goal of bug reporting is to make an application more stable and allow developers to fix it without any trouble.  Bug reporting is a skill and art that needs to be practiced regularly. Efficient bug reporting depends on your understanding of business requirements, scenarios you tested, ability to differentiate between an average bug and good bug, details you capture and how simply you present to developers.

There are noticeable differences between developers and testers over bug reporting. Every now and then bug is rejected by developers as irreproducible and it doesn’t go well with testers since they can reproduce it. This is one of the minor differences that raise several misconceptions about software testing.

I work closely with QA and development teams in IT industry and have created an ultimate cheat sheet on bug reporting. Points mentioned in this cheat sheet are tried and tested and have been approved by several project managers and clients. These points and template will certainly enhance the efficiency of your bug reporting skills.

Art of Bug Reporting:

There is certain type of result that is expected in every bug reported by a QA team.  As a tester, bug reporting is more of a documentation of your findings due to which it should be very simple. Developers, project managers or even a layman should be able to understand and reproduce that bug.

Simplest 4 point format which I and my team use in for bug reporting. Bug description should include:

• Scenario: List all steps that tester took that will help others to replicate the bug. These steps can also include basic information such as name of browser on which you tested, clearing cache etc.

• Expected result: The final result which is expected based on business requirement and which end user will see by following above steps.

• Actual result: The result which is currently visible to user and which could be correct or incorrect.

• Additional Data: Any additional information, observation or special instruction which is useful for team to replicate it, including which browser and OS used, relevant screenshots, any video recording that captures any intermittent bugs, adding references to the specifications etc.

Once you have described the bug based on this template, you will notice that not only that you have captured required information relevant to reproduce the bug, you have also answered any potential question from developers. You will also find it relatively easy to fill following important fields of any bug tracking tool:

• Bug Title: This has to be one liner, crisp and precise. You have already covered details in bug description
• Product Name: It will be name of the product, project or module you are testing
• Version: Version of build, module or product
• Operating System: Windows, Mac, Linux etc. along with their versions
• Priority: It is generally set from P1 to P5. P1 means Bug needs to be fixed on highest priority and P5 means Fix the bug as time permits
• Severity: Business impact of bug. There are 6 types of severity and one needs to be selected:
  1. Blocker: Further testing cannot proceed
  2. Critical: Application crash, Loss of data etc.
  3. Major: Major loss of function
  4. Minor: Minor loss of function
  5. Trivial: UI enhancements
  6. Enhancement: New feature or Change request
• Status: Bug status which shows whether it is new, fixed, reopened, verified or won’t fix
• Assign To: This is critical – Be very sure which developer is responsible for this. If you don’t know whom to assign, leave it blank so that manager can assign to developer. In this case, add manager email in CC so that he gets notified.

I have experienced a huge improvement in quality of bugs reported, higher bug closing rate and overall coordination effort using this bug reporting template and process. Yes, initially it seems a time consuming process but this is a key for any good but report. This is main communication between developers, testers and project managers which can be easily tracked in case of any disputes.

I am sure this ultimate cheat sheet of bug reporting will be remain handy for all QA managers and project managers as quality bug reporting saves lot of time that goes in explaining and reproducing bugs, maintaining good relationship between testers and developers.

This article is based on my learning and experience. I believe there could be more changes, scenarios based on which we can customized bug reporting template and process.

Do you have recommendations or examples which could be helpful for others? Share with us – we are open for learning.