Bug Reporting

Bug Reporting is the activity of posting a bug to the development team to fix it. Bug reporting in independent software testing can be done using a simple spread sheet or using a bug tracking tool. While reporting a bug don’t forget to fill up following fields –

• Bug ID (Auto generated in case of tool)
• Project Name
• Bug Summary
• Description

– Reproducible steps
– Actual Result
– Expected Result

• Bug Priority
• Bug Severity
• Assigned To
• Status
• Reporter
• Affects Version
• Environment
• Component/Module
• Attachments
• Test Case link
• User Story link

Severity Vs Priority

In the Bug reporting, the terms “Priority” and “Severity” are used to share the importance of a bug among the team and to fix it accordingly.

• Priority:

– Priority means how fast a bug has to be fixed.
– The priority status is set based on the customer requirements.
– Values can be (Blocker, Critical, Major, Minor, Trivial)

• Severity:

– Severity of a software bug is based on the degree of the bug impact on the operation of the system.
– Values can be (Blocker, Critical, Major, Minor, Trivial)

Why Need a Good Bug Report?

If your bug report is effectively documented, chances are very high that it will get fixed. So fixing a bug depends on how effectively you have reported it.

Qualities of a Good Bug Report

• Reproducible – Incorporate reproducible steps.
• Be Specific – there should not be any ambiguity in bug summary and description.
• Add required screenshots and error logs wherever required.

Tips to write a Good Bug Report

• Report the problem immediately if using a bug reporting tool.
• Reproduce the bug twice before writing bug report.
• Test the same bug occurrence on other similar module as well.
• Write a good bug summary that gives a brief about the bug.
• Read bug report before clicking on Submit/Save button.
• Do not use Abusive language at all.

Bug Tracking

Bug tracking means tracking the status of any bug until it get closed. At any point of time a bug must be in any of the states given below in the diagram-

There are several stages in a bug life cycle

• Open – bug that is raised and yet to be validated.
• In Progress – bug is validated and under fixing.
• Not a Bug – Sometimes developer or team lead can mark the bug as “Not a Bug” if the system is working according to specifications and bug is just due to some misinterpretation.
• Deferred – When a bug cannot be addressed in that particular cycle it is deferred to future release.
• Duplicate – Same bug is already logged by QA team.
• Fixed – Bug has been fixed by developer and QA has to verify it in next build.
• Reopened – When the bug is NOT fixed, QA reopens/reactivates the bug.
• Closed – If bug is verified by the QA team and it is fixed then QA can mark bug as ‘Closed’ or a bug can be closed if the defect is duplicate or considered as NOT as bug.

Need of Bug Tracker

The risks of not using a bug tracker in any project might result to the following –

• Important issues getting lost.
• Project teams waste too much time figuring out the stability of the project.
• Customers do not have the idea about the progress of bug fixing activity.
• Developer don’t realize that they’ve been assigned an issue.
• Getting bug status reports takes too long.