How often (or rarely) does it happen when your bug gets rejected with a comment (from devs) that they were unable to repro the bug reported. Or it was rejected on the grounds of being incomplete or obsolete ?
if it happens more than often, it’s time to introspect.
Bug Advocacy is crucial to the project. An incomplete bug report can only harm the project to delay it further as it puts everyone’s time and money at stake. QA’s have to put in time to write the bug. Devs have to study the bug and send it back if they do not understand it. Meetings with the management. Stakeholders time and money is involved. Too much of to-and-fro communication just depletes the time and money inches down.
You as a tester need to take charge here. A tester guides the project. you are the one giving direction to it. If a Tester mislead, the project can derail.
Few things that you can do as a QA.
UNDERSTAND THE REASON FOR BUG REJECTION
Go through Devs comments and if nothing much is mentioned, talk to them. Take Rejection in a positive way. It’s Okay if the bug comes back. Don’t go in exile. See if you missed adding crucial information while writing the bug report. Add comments and update the issue.
WRITE CLEAR REPRO STEPS
At times, developers directly start reading the repro steps without understanding the Observation & Expectations. See if you haven’t missed out on repro steps. If there are too many steps involved, it’s always good to attach a video. Record the steps and share the video link in bug report with developers. This makes it real easy to understand the issue and fix it at the earliest. You can download the free screen recording software from Screen Cast O Matic. You can create a free video of up to 15 minutes using this software. Upload the video on YouTube / Vimeo and share the link in the bug report. Make sure the link is not public and is accessible by intended members of the team only.
SHARE AS MUCH AS INFORMATION
Share enough information by adding screenshots especially if the bugs are intermittent.
Developers mark bugs as Obsolete when there is a change in functionality and the issue reported does not exists anymore.
EASY TO UNDERSTAND ISSUE
Your bug report should stand on its own to create an impact on everyone involved in the project as to why the bug is important to fix. Anyone in the team reading your report should be able to understand the issue.
EDITING SOME’s WORK
Do not edit someone else’s bug report. If you find anything missing / incorrect, update it in comments section in the bug report.
SPEAK WITH DEVELOPER
If you think the report is complete in itself, sit with the dev team and talk to them over phone, Skype or in person. Get clarity. Get inputs and try to resolve the issue at the earliest.
END USER MATTERS
Tester must write the bug report keeping in mind the end user who might face the issue.
Sentences should be grammatically correct enough to convey the message.
If it’s a Browser related issue, mention the browsers with their Versions used while generating the bug.
If it’s a UI issue, mention the screen size, resolution, browser, OS details. it may not be possible UI issue you see on your machine should be visible on all screens or OS. Check browser / OS related UI / UX issues using Browserstack. It gives a trial account with 30 minutes window to select from variety of OS / browsers combinations.
Prioritize the bug. High priority bugs are less likely to get rejected. if it does, it must be addressed immediately.
KEEP IT SIMPLE
Keep it simple. No use of long sentences or descriptive bug reports. Developers have time crunch to read the entire bug report.
ONE BUG ONE REPORT
Do not add too many issues in one bug report. Developers may only fix few of them and ignore the rest. It’s better to create a separate report for each bug found.
Bottom line, make sure the message is conveyed in the right way without too much of to-and-fro.
And before you leave, I would love to hear your views on this.
Latest posts by Rahul Aggarwal (see all)
- Importance of Writing for Testers - December 5, 2016
- 5 ways to be A Smart Tester - November 21, 2016
- Lessons Learned in Handling Complex Feature’s Development & Testing - November 6, 2016