Why Bug Reporting is an Art That Should Be Learned by Every Tester?

What exactly the tester is supposed to do? I was just brainstorming with my team. A number of answers popped up:

Okay, but I think, there is one quality which makes a tester, a “very good tester”. Every pair of an eye had question “how”.

What happens when you report an issue? I threw another piece to think.

Also read => Complete defect life cycle

Good, but why the developer does not resolve or delay fixing or mark the issue as “Not reproducible”?

After a pause, the most interesting phase of brainstorming started – discussion.

Presenting here some excerpts from the discussion:

As a tester, it’s our primary responsibility to test the application or product and report the issues. But mind well, the responsibility really does not end here. Actually, from here, the real duty starts. It’s very important to understand why your bugs are being rejected or being marked as “not reproducible” and how do you react to it.



Bug reporting and tracking is an art, a fine art whereby applying some fine points, we can change the quality of product from downside up and can win the trust of the client. No matter at which level of hierarchy you are sitting, being in software testing, it’s necessary that you master the skill of bug reporting. Bug reporting is not a document but a summary report about what is going wrong, how it is wrong and where it is wrong. The bug report is an enveloped bad news about an application and how you present it, is crucial in deciding the future of that bug.

You must have read about what information a bug should have and which fields should be included. But what about overall bug report? Even after including every necessary field, you might not be able to create a good bug report.

From my experience, I have listed out some points to be taken care while reporting a bug. I have provided an example for each point to make it more graspable.

Example:

Let’s consider an e-commerce website selling car parts and accessories. I have described some of the relevant issues with “should not be” and “should be” columns for each point below.

Have a look:

#1. Read the bug you just reported and ask yourself – are you able to understand it?

Not able toAble to
Title: Application is very slowTitle: Performance of application is poor on some specific pages.
Steps to Reproduce: Whenever user tries to buy something, he finds that the response is slow and sometimes not able to take the required action.Steps to Reproduce: Some specific pages of the application, i.e. Car models, new arrival, and accessories taking more than 15 seconds to load

#2. Provide proximity of reproducibility to save time and efforts

Should not beShould be
Title: Application crashes on payment pageTitle: Application crashes every time, on payment page for a specific selection
Steps to Reproduce : Whenever user selects payment option, application crashesSteps to Reproduce: Whenever user selects payment option as XYZ bank credit card, application crashes.

#3. Understand that bug is a project matter and not personal

Should not beShould be
Title: Application not working properlyTitle: Application does not respond when user selects a specific inventory to be added in cart.
Steps to Reproduce: As I had already conveyed to you and showed you that Application is not working for many pages and shows error pages. Please resolve this issue ASAP.Steps to Reproduce: When user selects a specific part to add it in shopping cart, application does not respond.

This issue is a barrier in testing the application flow. Please consider it as highest priority.

#4. One bug, one issue only:

Should not beShould be
Title: Certain parts are not selectable and application crashes if selected some other partsTitle 1: On Car Accessories page, certain parts are not selectable
Steps to Reproduce: On Car Accessories page, following parts are not selectable :

Mobile holder

Car backseat pockets

car perfumes
Steps to Reproduce: On Car Accessories page, some of the parts are not selectable. Also, when user selects grey seat covers or rich brown seat covers, application crashes.Title 2: On selecting specific types of seat covers on Car Accessories page, application crashes
Steps to Reproduce: On Car Accessories page, when selected following parts, application crashed :

Grey Seat covers

Rich brown seat covers

#5. Provide possible reason, if you know:

Should not beShould be
Title: After cancelling purchase for any accessory from cart, if selected once again, price to be paid shows double of the original priceTitle: After cancelling purchase for any accessory from cart, if selected once again, price to be paid shows double of the original price
Steps to Reproduce: On Car Accessories page, select any item and add it to the cart. Now delete it from the cart and re-select it and add it to cart.Steps to Reproduce: On Car Accessories page, select any item and add it to the cart. Now delete it from the cart and re-select it and add it to cart.



Note: While looking in to database, I found that when user deletes any item from cart, the specific entry does not get deleted from database and therefore when user selects same item again, the price shows up as double. This can be the possible reason of the issue.

I hope, above examples clarifies the points, I wanted to convey. And again, let us know your views/opinions about this post.

About the Author: This post is written by STH team member Bhumika Mehta.  She is a project lead having 10+ years of experience in software testing. She appreciates good ideas, innovations and risks but hates monotonic work, people and environment.

Happy testing as always. :)