"A Bug Dispute is a feature designed to give you an opportunity to submit a request to our Dispute Managers for the final look if you think that your bug is legit or downgraded without reason."
Motivation
Getting a bug rejection is never easy to digest but our experienced testers know how to deal with it. They know when and how to submit a successful Bug Dispute in order to get their bug report a final review by the Dispute Managers. A Bug Dispute is a feature designed to give you an opportunity to submit a request to our Dispute Managers for the final look if you think that your bug is legit or downgraded without reason. More about the Bug Dispute feature can be found here.
When should you submit a Bug Dispute
To prevent yourself from getting a Dispute block for a month, you need to make sure that you are submitting a Bug Dispute only for the bugs you are 100% sure off. It might sound like we are trying to scare you out, but that is not our goal. We want you to start thinking about the bug you submitted and about the rejection/downgrade reasons provided in the TL's comment.
Ask yourself: "Did I overlook something? Did I upload a console log to support my claim about the bug? Is there a chance that I forgot something to share in the bug report? Did I understand the product correctly?". Once you answer those questions you will have the answer should you submit a Bug Dispute or not.
What does a good Bug Dispute contain
Have you ever thought about filing a complaint in court? It is not that different from submitting a Bug Dispute. Both of them need to contain:
The official greeting for the reviewer
The explanation of why you contacted them
The reason why you think that your rights have been endangered
The additional proof like attachments, links and logs
The proposed solution for the problem
The official greeting at the end
Dispute Resolution: Dispute Managers' Role
The goal of dispute managers is to ensure fairness in resolving disputes between team leaders and testers.
If both sides present valid arguments and the weightage of their claims is equal, the advantage is given to the tester, and the dispute managers make decisions in favor of the tester. In such cases, the tester's concerns are prioritized.
However, if a dispute is rejected, it means there are genuine reasons for the rejection, and the tester should learn from it.
The dispute managers strive to maintain a balance of fairness for testers, always considering the rules, and the quality of the bug report, and applying their extensive experience when reviewing bug disputes. Their aim is to be as fair as possible in their decision-making process.
A positive example of the Bug Dispute
Above you saw what is required to make your Bug Dispute successful. Now, let's see what it looks like in the practice. The example below covers a real-world scenario. Sometimes, testers don't need to use all the elements mentioned above to prove that the issue is valid. In the positive example below, you can see that tester used only 4 elements:
The greeting "Hello Dispute Team"
The reason why the tester considers the issue a bug
The possible implications and the audience affected if the bug is not fixed
The official greeting at the end is "Kindly re-check it! Thanks!".
Taking into account that the tester was as short as possible and as detailed as needed, we can conclude that finding the right balance is the key to the success as well. What would also increase the chances of the dispute being successful is providing some additional information which was not included in the initial bug report. For instance, a second screencast or console log is uploaded to Google Drive and shared as a link in the Dispute.
A negative example of the Bug Dispute
Going into a Bug Dispute with anger or harsh words is never a good idea. You can try it, but you will end up with a rejection, warning or even a ban from our platform. So, calculate what are the possible scenarios of being rude, non-professional or violent. Sounds bad, huh?
Some of our testers, on the other hand, don't read or forget our rules which leads to Bug Report rejections and Bug Dispute rejections. In the case shown below, the tester wrote:
The title and the actual result should be similar.
The title is aimed to give a short description of when, where and what happens. It should be as short as possible and as descriptive as needed. On the other hand, in the Actual results, testers should explain in detail what is the issue, point out the scope of the issue, other pages affected (if any), etc. Sharing all those details in the Bug Report title would be impossible.
The video shows exactly the sequence of all steps and shows the described problem.
The screencast should not show all the steps one needs to take to reproduce the bug. Only the last one or two steps should be shown in the video.
What was missing in the Bug dispute?
The official greeting at the beginning
The knowledge about our rules
The knowledge about our Bug Report Quality standards
The additional information to support the claim about the bug severity
More examples of tester mistakes while submitting a Bug Dispute are:
Sending only "Please review!" in the Bug Dispute
Writing "Thanks TL. I understand!" thinking that they responded using a comment to the Bug Report
Addressing the Dispute Manager as TL
Lying about non-answered requests, etc.
Remember that we see the history of every single bug report. The path of truth and hard work is the only guarantee that we will consider you for possible promotions in the future. If you want to make your career with us, make sure that you are taking the right steps in that direction.