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

By Vijay

By Vijay

I'm Vijay, and I've been working on this blog for the past 20+ years! I’ve been in the IT industry for more than 20 years now. I completed my graduation in B.E. Computer Science from a reputed Pune university and then started my career in…

Learn about our editorial policies.
Updated February 29, 2024

In this article, we will see why bug reporting is an art that should be learned by every tester. Let’s get started.

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

  • Should test
  • Should test thoroughly
  • Should not miss any bug
  • Should understand application
  • Should try to break the application

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

bug reporting skill

Okay, but I think, there is one quality which makes a tester, a “very good tester”. Everyone had the question “how”.

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

  • Developer resolves it
  • Sometimes they do not resolve it
  • Sometimes they delay fixing the issue
  • Sometimes the issue is marked as “Not Reproducible”

Also read => Complete defect life cycle.

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

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

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 you, the responsibility really does not end here. It is here that the real duty starts. It’s very important to understand why your bugs are being rejected or being marked as “not reproducible” and how you react to it.

Bug reporting and tracking is an art, whereby applying some fine points, we can change the quality of product and can win the trust of the client. No matter at which level of hierarchy you are 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. A bug report is enveloped with 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 the 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 some points to be taken care of while reporting a bug. I have provided an example for each point to make it easy to understand.

Example:

Let’s consider an e-commerce website that sells 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 to reproducibility to save time and effort

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 bugs are 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 reasons 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 the above examples clarifies the points I wanted to convey. Do let us know your views or opinions about this post in the comments section below. We would love to hear your thoughts. 

About the Author: This post was 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. 🙂

Was this helpful?

Thanks for your feedback!

Recommended Reading

23 thoughts on “Why Bug Reporting is an Art That Should Be Learned by Every Tester?”

  1. this may be my own pet peeve, but example #1 still is poorly written. What – exactly – is meant by “poor on some specific pages”? Defect should clearly identify the page, expected service level, and reference the specific requirement(s). Too often, the tester/developer is chasing down poorly written requirements or unwritten requirements. My all-time favorite comes from a State Police Captain who wrote, “The web page colors are not pleasing to the eye”. How the heck do you code to that?

    Reply
  2. Hi Bhumika Mehta,

    I have slightly different idea of Bug reporting and I have worked with few clients in USA.

    Bug Report templete:

    Summary of the Defect: Performance of application is poor on some specific pages.

    Steps to replicate:
    1. Login to application with appropriate user.
    2. Navigates to Car models, new arrival, and accessories taking.
    3. System takes more than 15 seconds to load.

    Expected Result: Performance of application is good.

    Actual Result:Performance of application is poor on some specific pages.

    Username And Password used to login.
    User Credentials:
    URL Address:
    Build/Version:

    Attach the appropriate screenshots, if required.

    Reply
    • Hi, Mounesh

      The way you wrote the bug template is absolutely correct and it’s very helpful for QA’s but here she (Bhumika) just gives a brief idea about how to write a bug. So, just appreciate her efforts.

      Anyways, thanks Bhumika for this article and also thanks Mounesh for sharing your experience about how to write a bug.

      Reply
  3. To the Point ,informative article. 🙂
    Little typo error in Point 5 title that both should not be and should be titles are same

    Reply
  4. Thanks a lot for this article! Precisely explained about proper Bug reporting so that there will be no understanding problem from developers and hence the Productivity improves and time got saved. The application can become flawless in the short span, if we can follow this correct method of Bug reporting.

    Reply
  5. Readers,

    Thanks a lot for those kind words and glad to know that the post was informative and helpful.

    @Tejaswini,
    Thanks for pointing out but its not an error. The titles are actually same for both Should be and Should Not Be. For that point, I was trying to describe the main point as – every bug should be reported with possible reason.

    Thanks everyone….


    Bhumika Mehta

    Reply
  6. Clear Picture of Bug Report !!! thanks for Sharing your knowlendge on bug reporting it was very helpful.

    Thanks – Bhumika Mehta

    Reply
  7. How could i report, if i see application performance is slow only few times, that which we cannot reproduce again(not every time but few times)

    Reply

Leave a Comment