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?
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 to | Able to |
|---|---|
| Title: Application is very slow | Title: 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 be | Should be |
|---|---|
| Title: Application crashes on payment page | Title: Application crashes every time, on payment page for a specific selection |
| Steps to Reproduce : Whenever user selects payment option, application crashes | Steps 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 be | Should be |
|---|---|
| Title: Application not working properly | Title: 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 be | Should be |
|---|---|
| Title: Certain parts are not selectable and application crashes if selected some other parts | Title 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 be | Should be |
|---|---|
| Title: After cancelling purchase for any accessory from cart, if selected once again, price to be paid shows double of the original price | Title: 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. 🙂
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?
Article is very clear and easy to understand.
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.
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.
To the Point ,informative article. 🙂
Little typo error in Point 5 title that both should not be and should be titles are same
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.
It is a very informative article for all who work as developer or tester.
Understand the problem first.
Genial, buen aporte Bhumika Mehta xD
Example 4 and 5 is ambiguity. Please correct it.
#3 is HUGE and is a major source to dev vs. qa issues.
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
excellent report with examples to understand where I personally making mistake at job
Thanks Bhumika
Very Nice Examples to specify the bugs detail which is able to understand by developer .
Nice article… It’s helpful for us to improve our knowledge about making a good bug report… Thanks bhoomika mam
Great Artempt to let others understands facts and findings .
Clear Picture of Bug Report !!! thanks for Sharing your knowlendge on bug reporting it was very helpful.
Thanks – Bhumika Mehta
A good article. Quite helpful . Thanks to STH
very nice article, useful.. Thanks
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)
good article,thanks
Very nice article helpful to improve our testing knowledge
thanks a lot.
Thanks for clearly explaining on art of Bug reporting also how it should be presented. Very informative !!
Really very very good Article, so valued, with very simple examples