Tips on disputing a bug - Giovanni Pagani

Author: Giovanni Pagani

Introduction: Imagine yourself moving in a new application’s dungeon of features, performing your test case when everyone else in your country is sleeping, just to be the first one to find that precious gem, err, bug. You feel that this click will be the right one… Yes! I got it! Let’s rush to report and get some cash, and go on to that “Gold tester” status, where I’ll be able to unlock some fantastic testing opportunities.

Bug warrior’s sleep is sweet after some finding, right? But the morning after you see that instead of “Approved” you get a “Rejected”.

Stop. Don’t do what you’re thinking to do. Don’t “dispute” just now. First of all, you have only one dispute opportunity per bug, and a limited number of disputes per month. You can’t really play to “shoot ‘em all”. And your reputation as a tester could be affected. Surely you are going to waste time and definitely loose an opportunity.

At the same time a few discarded submission are quite normal when working in a testing environment. It’s an opportunity to improve your testing level; it’s not a honor offense to be avoided at all costs.

Let’s follow instead a simple check to see if raising your hand and asking for a debate (forget considering it a contest or an altercation, we are offering our services, even if responding to an invitation) is the best thing you can do, and if you are ready to.

Are you a newbie uTester?

Even if you’ve some silver in your hairs (or lost them all on the way) we’re all newbies sometime: it’s either lack of generic testing experience, or specific experience on that application (or website), or on uTest’s platform and community’s way to perform activities. 

If you feel newbie try to slow down your bug-submitting rush, set your pace at a slower speed and watch around, study what other testers are reporting, which submissions are approved and which rejected. Take a look at test cycle’s discussion thread. Don’t be shy: The time and place for asking clarifications is here and before submission.

Being new to a test cycle isn’t something to leave behind, it’s actually what our customers are looking for, since it raises your attention level. Lack of attention towards details when searching and reporting is our worse enemy, and it means you’re ready to start developing your own bugs.

 Is the customer new?

Even if you’re the best uTester in our community you can encounter a newbie customer. Sales and marketing did their best job to reach a new customer. Thanks to our platform we can dedicate to testing only, not to self-marketing and invoicing.  Maybe the customer is not familiar with uTest platform, maybe that they’re looking only for specific bug types but didn’t specify them into the out of scope section.

Maybe that a new customer forgot to share his internal list of known issues, so is discarding all your findings.  Instead of raising a controversy against someone that has just chosen our community to simplify and improve his testing processes, please contact the project manager. This is the way to go for a win-win-win solution. Maybe your bug won’t be approved, but surely your project manager will remember your approach in this kind of troubleshooting.

Is the bug a new one?

Check if that issue is really a new one: this step should be the easier to recognize after the rejection has happened since the customer will answer “known issue.” This may happen, it’s not always easy to check within a long and tedious list of known issues and findings by other testers, especially if there’s a list of several hundreds of uncategorized issues, with no proper keywords to search for.

If this is the case, consider that known issues lists are often made by copying and pasting our “bug reports” text from previous test cycles, but without attachments. Remember this when reporting your bugs, and help other testers avoid rejections or boring searches among meaningless descriptions. Same way, follow test cycle’s specific directions on bug title elements.

If you have checked your submission, and feel that you’ve been misunderstood, be sure to:

• Collect more data. It’s a time consuming activity, it’s easier to simply type a few words about our finding than to search for a video capture utility, learn to use it, capture and upload. But you need to do it, to show that your findings can be helpful: if video attachment is allowed it’s often the preferred and easier way to show your findings. 
• Collect significant data. Be specific when detailing your findings, even if you got a “generic error.” Add environment details, and if possible, cross check on alternate platforms or production version.
• Check again if test cycle instructions have been changed. You get an email when objectives are updated, so maybe you missed an important one. Check if your bug was within old scope, if it has been changed. Better to take a copy of a test case description for your reference
• Don't get angry or frustrated if the customer asks you to verify your information or asks you to repeat your test EVEN IF you'd already entered your results into the system. Instead, verify them once again. In the meantime your knowledge of the testing project could have been improved, so you are able to deliver a better report.
• Consider that your level of testing and the customer’s level of acceptance for the release can be at a different sensitivity. For example, an Alpha or early beta application version usually won’t be hurt by a misspelled word lying on the “terms and conditions” page.
• Put your efforts on describing your rejected bug as if it is a different finding. You need to add details on a different approach, not copy and paste what has already been rejected. Think to your bugs reporting standards it as to the step-by-step user manual, not a brief note for someone that already knows everything about the application being tested

Based on what’s the rejection listed reason and on which of the above checks shows your submission’s weak points you can finally place your request. Each cycle and each submission is different, but please apply this rule to all your disputes: never beg for some sort of gratuitous mercy regarding your findings.  It’s a clear indicator of how poor are your arguments. Instead be polite and ask for a bit more of customer’s attention since you have a better explanation for your findings.  By showing that you want to better learn what a customer is looking for you can end up as being chosen as a favorite tester even with a discarded bug , rather than having an approved feedback and being discarded as a tester.