Skip to content

Bug Advocacy For Incomplete Bug Reports

Incomplete bug reportHow 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.


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.


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 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.


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.


Do not edit someone else’s bug report. If you find anything missing / incorrect, update it in comments section in the bug report.


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.


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. No use of long sentences or descriptive bug reports. Developers have time crunch to read the entire bug 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.

Rahul Aggarwal
Follow me

Rahul Aggarwal

Tester at Mindhunters
I am a Freelance QA, a learner, passionate about Testing. I love to blog here on various Testing topics and otherwise.
Rahul Aggarwal
Follow me

Latest posts by Rahul Aggarwal (see all)

2 thoughts on “Bug Advocacy For Incomplete Bug Reports

  1. Gaurav Khurana says:

    Very nicely documented most of the things. I think it would be better to mention the impact of the bug. I mean what the problem end user will face with the current bug. It will give more clarity to dev why it should be fixed.

    • admin says:

      i totally agree with that Gaurav. It’s not good when users find bugs in the live application. Stakeholders reputation is involved. And plus the competition in the market. Any bug can put back / tarnish the image of the company.

      QAs must try to make the team understand why it is important to fix this bug. Afterall, nobody wants to get into WAR room if the bug is later found by real time application users.



Leave a Reply

Your email address will not be published. Required fields are marked *