Have the bug which was reported by you ever been rejected/deferred? Yes, we have all gone through this. It really lowers your confidence to a great extent. I have always felt like this is really a bug but why are they not accepting it?
But when I came across Bug Advocacy skills, I understood some Bugs will never be fixed. Our responsibility is not to make sure that all bugs are fixed. Our responsibility is to report bugs accurately in such a way that allows reader to understand the full impact of the problem. The Effective Tester looks to the effect of the bug report, and tries to write it in a way that gives each bug its best chance of being fixed. A Tester does not complain but offers evidence. You can make programmer’s job easier by providing good bug reports and don’t waste the programmer’s time with mistaken or frivolous reports.
When I started following all this, the acceptance rate of the bugs reported by me increased significantly and I was so happy now and really enjoyed finding and reporting bugs. I strongly believe that when you will follow Bug Advocacy skills, your bug acceptance rate will definitely increase, you’ll have a lot more credibility, and that will translate into support and influence.
The excellent bug report raises the issue and provides sufficient data for a good decision.
The Big question is what makes programmers resist spending time on the Bug?
• The programmer can’t replicate the defect.
• Strange and complex set of steps required to induce the failure.
• Not enough information to know what steps are required, it will take a lot of work to figure out.
• The programmer doesn’t understand the report.
• Unrealistic (e.g. “corner case”)
• It will take a lot of work to fix the defect.
• A fix will introduce too much risk into the code.
• No perceived customer impact
• Unimportant (no one will care if this is wrong: minor error or unused feature.)
• Management doesn’t care about bugs like this.
So what’s the Solution now! Whether you think of it this way or not, your bug report is a sales tool, it’s designed to convince people to give up precious resources in order to obtain a benefit that you propose. But Bug Advocacy is much more than good bug reporting. It is a guide which helps you how to properly investigate bugs, look for corner issues and report a bug better. RIMGEN is one such bug investigating framework which helps you to looks for bugs in a better way.
R- Replicate:
- Make sure the failure is reproducible by anyone who follows the steps in your report. When you test with two machines, you can also check your bug report while you write it.
- Write the steps of the bug report on machine 1.As you write them try them on machine 2.In this way the report has been tested. If you can follow your report someone else can follow it too.
I – Isolate:
- Write the bug in the easiest way possible and narrow down to the exact critical conditions that led to the bug
M- Maximize
When you see a minor failure don’t just make the bug reproducible and report it. You do not now know at first how serious the underlying problem is. Do follow up testing to find
- Is it more serious then it first appears?
- Is the symptom more general then it first appears?
Follow up Testing can be done in various ways
- Vary your behaviour-Trying a different way of doing the same task.
- Vary the options/settings – There could be program settings that you can toggle on or off or adjust for browser testing, you can try adjusting the zoom sizes.
- Vary the data-If you saved/uploaded a small file, try uploading a bigger file and observe.
- Vary the Environment-Vary the OS/Browsers used
G-Generalize
- Uncorner your corner case
- Suppose the 0-999 program rejects 999. If you stop with this result, some programmers might ignore it (“Who would enter 999? That’s the biggest possible value. No one would do that!”).
- Don’t stop with this result. Instead, try smaller numbers until you learn what range of supposed-to-be-acceptable values are rejected. If the program rejects anything bigger than 99, you can report that it fails throughout the entire range of 100 to 999. This will capture attention.
- If the program fails only at 999, that is useful information, too. Report it explicitly.
2. Never assume that an obvious bug has already been filed.
- If you think a bug might have been reported, check the tracking system to see how it was described and what the response was.
- Strengthen the report with your comments or added information. Add your name, date in comments for proper communication.
- Maybe a new report if the old report was weakly written and rejected.
3. Check whether the bug is new to the version?
- Has this bug been there through several releases? If no customer ever complained probably it won’t get fixed.
- An old bug which shows up under new conditions.
4. Check whether the bug is Configuration dependent?
- Bugs that don’t fail on programmer’s machine are less credible to programmers.
- It is common to test on 2 machines.
- Machine 1:Latest processor, updated operating system, lots of Ram, faster network connection
- Machine 2: Slow processor, less Ram, slower network connection, old version of operating system.
- If you find a defect on machine 2, replicate the same on machine 1.If you get the same failure write it up. If you don’t, you have configuration dependent bug. Trouble shoot it.
- Provide the environment details, Screenshot, log files for the bug
E-Externalize
- Compare your product’s behaviour to a leading competitor’s. This helps you describe user expectations, and it helps marketing managers assess the severity of the problem.
- Learn from competitor’s mistakes by analysing their reviews from app store, support forums and report your bugs accordingly.
N-Neutral Tone
- A remarkable number of bugs are fixed in the last weeks of the project, by programmers who are working heavy overtime to get the product finished. Be Humble and use simple words while reporting bugs.
- A good summary gives the reader enough information and be taken up in triage meetings.
- No benefit is gained by adopting a blaming tone. For example, reports written in ALL CAPS read as though you were SCREAMING. Keep a neutral tone.
Some good Bug Reporting skills to Remember:
- Report defects promptly. Don’t wait until tomorrow when you have forgotten some key details.
- Compare closed bugs that were fixed and not fixed. Look for differences in the way they were reported. If you want yours fixed, report them like the ones that historically do get fixed.
- Read programmers’ (and others’) answers to bug reports. What makes them confused? Angry? Unreceptive? Appreciative?
- Don’t rank a bug as “serious” that would normally be classed as “minor” just to get it added attention. Use the rank you believe is appropriate and explain at the end.
- When you report a minor bug, take extra effort to make your report clear and well analysed.
- Always report Non-reproducible errors. Programmers have tools that you don’t have. If you report the symptoms clearly, the programmer can often trace through the code, asking how you could have gotten a certain message or what could possibly have happened.
- Never use Bug-Tracking system to monitor programmer’s performance.
- Report perceived quality gaps as bugs.
Let me give you an example of uncorner your corner case which I reported. I had participated in a hackathon where we had to test a book reading app. It is important to have all authors listing out their books. I figured out one Author didn’t had any books listed under his name. If I had reported it as a bug, it might have easily got rejected/deferred as one author is okay. But I didn’t stop there and went ahead in looking out for how many more authors didn’t have any books listed. I figured out all the authors, listed them and reported it as one bug. And believe me it was classified as the Best Reported Bug.
Conclusion:
Next time when you find a bug, think of RIMGEN and the good reporting skills. Bug advocacy is much more than good bug reporting. Do take an extra effort to check for all the possible cases, environment, and configuration. I have always compared the product to a competitor and got a lot of ideas from there. Follow up testing too has helped me find a lot of bugs. Always focus on why this a bug, who does it affect, what is the risk of not fixing it and how can I keep it simple and clear for others to understand the bug. The day I had started following Bug Advocacy skills and the good reporting skills, my bugs have been taken up for fix more which made me feel happy and enjoy Testing. So next time when you test, do remember the skills and increase your credibility. Happy Testing.
References:
Picture Credit: https://newline.tech/bug-report/
References:
- http://www.testingeducation.org/BBST/
- Lessons Learned in Software Testing: A Context-Driven Approach, By Cem Kaner, James Bach, Bret Pettichord
Know Our Writer
Mousumi Bhanja
Software Tester
Mousumi Bhanja is Passionate and a Curious Tester Freelancer. She has 3+ years of Testing Experience.She took a professional break of 8 years and is back now and learning and exploring.
Leave a Reply