How to Report Bugs Effectively

As per defined in wikipedia –

“A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. Most bugs arise from mistakes and errors made by people in either a program's source code or its design, and a few are caused by compilers producing incorrect code. Reports detailing bugs in a program are commonly known as bug reports, fault reports, problem reports, trouble reports, change requests, and so forth.”

There might be many fields (information) need to be filled while reporting a bug.  The number of fields, mandatory fields, optional fields etc. differs from team to team.  But few bare minimum fields that are required during reporting a bug in almost all teams are as follows:

1. Title
2. Description
3. Steps to Repro
4. Expectation
5. Severity / Priority

Most of the time, testers go and try to provide these information in hurry, without providing sufficient / relevant details to stakeholders.  Before we understand how to report bugs effectively, it is important to know the answers of following questions –

1. Why testers report bugs?
2. Who are these stakeholders?
3. Why stakeholders hate ‘Badly’ reported bugs?

Why testers report bugs?

• Testers report bugs so that it is not found / reported by end users and by doing this testers make end users happy, which in return help business.
• Testers report bugs so that cost to company can be reduced by increasing the throughput or decreasing the resource utilization.

So, in other words testers report bugs for minimizing impact on users / business due to fault present in the system / application.

Who are these stakeholders?

Broadly stakeholders of a bug are ‘Developers’ and ‘Project Managers’.  Developers are the one who are responsible for fixing the fault in the application and Project Managers are the one who decides on priority of fixing the fault.

Why stakeholders hate ‘Badly’ reported bugs?

• Developers need to fix the fault and he / she got irritated when an additional work for them becomes to understand the bug itself or to reproduce the bug.  Sometimes, few developers get irritated almost on every bug raised due to additional work required by them for fixing it, please ignore those kindsJ.
• Project Managers need to prioritize the bugs and they got irritated when additional work for them become to understand the impact on user / business from the scratch.
• Project Managers, Developers and other stakeholders (if necessary) require triaging the bugs during triage meeting and they got irritated if takes lot of their time only to read and understanding the reported bugs.

With above questions answered, it can be analyzed that for an effective bug report, following points should be considered before reporting a bug –

Title

• The title should be concise and should report a fault present in the system.  Clear and concise bug title expedites the review meeting(s).
• The title shouldn’t contain the opinion / expectation, e.g. “Information Message box” should be displayed after clicking the info button, and rather the bug title could be “Information Message Box” not being displayed after clicking the info button.

Description

• The description should be adding more information to the title and should be done only when required.  In case, information present in the title is sufficient, then detail should be filled as “Same as the title” rather than copying / pasting the content from the title.  It should be done to reduce duplicate content and hence reduce review time.  For the above example – the detail can be “Information Message Box” not being displayed after clicking the info button on the ‘Login’ page when user navigates to the Login page after registering.
• The description should also list impact on users / business due to the bug.  It helps Project Manager to prioritize the bugs faster.  If the impact on user / business is obvious as in the mentioned above bug, then listing of impact(s) can be avoided.
• One example of a bug (for survey site) where it could help to write impact(s) would be – “Lots of unnecessary / irrelevant details like ‘Education Background’, ‘Family Details’ etc. are being gathered during the registration process, which is time consuming and might drift the users to complete the registration process and hence business might lose few prospective users.

Steps to Repro

• It should list all steps required for reproducing the faulty behavior.  The steps should be common understandable actions than all steps required for navigation.  For example, rather than having steps like –

1. Navigate to home page
2. Click on the registration link
3. Fill the registration details
4. Click on “Register” Button
5. Verify user gets registered successfully
6. Click on the Login link
7. Click on ‘Info’ button in the login page
8. …

The steps below could be more readable and quicker to review –

1.      Register as a new user

2.      Navigate to the login screen after successful registration

3.      Click on ‘Info’ button in the login page

4.      Note:  “The information message box” is not being displayed for the first time registered users whereas when info button is clicked for returned users, its working fine

5.      …

• It should point out the problem / fault as shown (as Note) in the above example for expediting the review process or helping developers by explicitly pointing the fault during repro.

Expectations

• This is the section where testers should list down their opinions or recommended solutions to developer.  For example – ‘Information Message Box’ should be displayed after clicking the info button consistently. Or Following are the information that I think are irrelevant during filling the registration form and can be gather later.
• The opinions / solutions are only recommendations whereas the actual solution should be discussed and decided by all stakeholders collaboratively.  For example -  It might be decided in the meeting that only few of the listed information is irrelevant during the registration process whereas others are valid and should be gathered during the registration flow itself.

Severity

• It suggests the severity of impact of bugs on users / business.  Usually, for testers definition for Severity is more important and priority needs to be defined by the Project Manager. Generally Test Engineers will give their opinion on priority but assigning the priority is the responsibility of the Project Manager.

Following definition can be used while setting the severity –

Severity
1	Blocker – System crash or anything that blocks users to progress further
2	Critical – Crash or anything that loses persistent data or data corruption
3	Major – Feature that doesn’t work at all
4	Minor – Aspect of a feature that doesn’t work
5	Trivial – Cosmetic problems, misspelling in dialogs, redraw issues etc.

Summary

In an effectively reported bug –

• The Title should mention the fault present in the system clear and concisely and large number of bugs can be reviewed quickly without checking its detail.
• The description should add more information to the title if required and should hint how the bug can impact users / business.
• The steps to repro should allow developers to see the faulty behavior with minimal steps execution.
• The expectations should allow testers to put his opinions / recommendations for resolving the fault.
• The severity allows testers to highlight the impact of bug on users / business.