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”.
Recommended IPTV Service Providers
- IPTVGREAT – Rating 4.8/5 ( 600+ Reviews )
- IPTVRESALE – Rating 5/5 ( 200+ Reviews )
- IPTVGANG – Rating 4.7/5 ( 1200+ Reviews )
- IPTVUNLOCK – Rating 5/5 ( 65 Reviews )
- IPTVFOLLOW -Rating 5/5 ( 48 Reviews )
- IPTVTOPS – Rating 5/5 ( 43 Reviews )
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. 🙂