What exactly the tester is 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
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.
- Developer resolves it
- Sometimes they do not resolve it
- Sometimes they delay fixing the issue
- Sometimes issue is marked as “Not Reproducible”
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 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 of reproducibility to save time and efforts
| 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 bug is 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 reason, 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, 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. :)
Very Nice Examples to specify the bugs detail which is able to understand by developer .
excellent report with examples to understand where I personally making mistake at job
Thanks Bhumika
Great Artempt to let others understands facts and findings .
A good article. Quite helpful . Thanks to STH
Article is very clear and easy to understand.
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)
Nice article… It’s helpful for us to improve our knowledge about making a good bug report… Thanks bhoomika mam
Example 4 and 5 is ambiguity. Please correct it.
It is a very informative article for all who work as developer or tester.
Understand the problem first.
Really very very good Article, so valued, with very simple examples
To the Point ,informative article. :-)
Little typo error in Point 5 title that both should not be and should be titles are same
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
#3 is HUGE and is a major source to dev vs. qa issues.
very nice article, useful.. Thanks
good article,thanks
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?
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.
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 !!
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.
Clear Picture of Bug Report !!! thanks for Sharing your knowlendge on bug reporting it was very helpful.
Thanks – Bhumika Mehta
Genial, buen aporte Bhumika Mehta xD