Suggestion: Add an “Archived Bugs” Tab to Prevent Duplicate Reports
R
Ramratan M
Feedback to Test IO
Dear Test IO Team,
As testers, we would like to kindly request that you consider implementing a system where, if a copied bug is reported (whether intentionally or unintentionally), the payout is automatically set to zero. This approach would help avoid misunderstandings and ensure fairness for both testers and customers.
When we participate in many test cycles for the same customer, it becomes very difficult to manually check all past cycles before submitting a bug. Having such a system in place would allow us to focus on providing valuable and unique findings without the fear of unintended duplicate reports leading to unnecessary actions on our accounts.
We truly want to avoid reporting copied bugs, as they do not add value to the customer. By following this suggestion, it will create a smoother experience for testers and motivate us to confidently report new bugs without hesitation.
Thank you very much for your understanding and consideration.
Mahmood
It’s also worth highlighting that testers often make mistakes identifying bugs that share the same root cause, even when those issues are part of the known bugs list for the current cycle. That’s why duplicate rejections are so common.
But when it comes to bugs from previous cycles, there seems to be an entirely different standard — one where testers are expected to have a 100% accurate understanding of every past issue’s root cause. That’s not realistic. If confusion can occur with issues listed in the current cycle, it’s only natural that mistakes might happen with older bugs as well.
Mahmood
I also rarely report bugs for any cycles, that I have participated previously, because after a point, it becomes impossible to memorise all of the bugs in all of the previous cycles, and it takes unbelievable amount of time to check all of the previous cycles, every time I have found a bug.
I also support the ideas of the OP, that if a copied bug is reported (whether intentionally or unintentionally), the payout is automatically set to zero as well as report getting rejected. This approach would discourage testers to copy previous bugs. In addition, the idea of “Archived Bugs” tab is another solid suggestion.
S
Sablina
Hello, and thank you for your valuable contribution in helping us improve our platform. We truly appreciate you bringing this matter to our attention.
You are absolutely right—tracking duplicate issues can be challenging, especially in recurring cycles with a large number of reported bugs, as well as when duplicates originate from previous cycles. We fully recognize the difficulty this creates for testers.
At the same time, setting the payout for repeated bugs to zero is not a sustainable solution, as it could introduce other complications. Please rest assured that we are actively investigating this matter and working towards a more effective and balanced resolution.
Thank you again for your feedback and for supporting the continuous improvement of our platform.
Aleksndra Mitiukova
Sablina Hello team. I completely agree with Ramratan M and Mahmood
Motivation part - we losing motivation to participate in the cycle. In old cycles that repeat for more than three months, there may be more than 1,000 in history. If we encounter an old bug that still reproduces and it is removed from what we know, we have to do a lot of work to find this bug and copy it word for word, and please note - we receive ONLY PART OF THE PAYMENT. It is easier for us to IGNORE the bug.
Meanwhile, from the customer's side, they have received confirmation that the bug has not been fixed. Or they have not received confirmation because the bug was ignored by the tester and this bug went into production. The customer loses quality and quantity of bugs.
As a result, the customer will have 0 results for cycles and will leave.
Fear — we walk the line between ignoring bugs and being blocked for accidentally rewriting a bug. I often don't publish bugs at all if I can't find them in the history, because they may have been on the known issues list and the customer cleared that list. Also, I very often ignore such cycles.
The result: the customer doesn't get activity in the cycle and loses quality. We lose the customer.
Income - by ignoring bugs we all lose money!!! We as a tester and you as a platform. You don’t have bugs - you got less paid!!! Which is affecting TestIO business directly.
Aleksndra Mitiukova
I can see only 1 solution. Leave only the list of known bugs and take care of it carefully and do not clean it as long as customer do not clean it itself to check his new updates
Aleksndra Mitiukova
Sablina Hello again. By the way, another improvement idea — it might help to integrate an AI suggestion system for duplicate detection.
When a tester writes a bug title, the system could automatically show similar historical bugs (not older than 3 months) under the title as suggestions to copy and fill the bug report automatically from the history. If the tester sees that the same issue already exists, they can link it instead of creating a duplicate.
If AI finds that a tester ignored a clearly matching historical bug, then it would make sense to apply penalties or warnings.
But if there’s no match in the AI suggestions — the tester should be free to submit it as a new valid bug.
This approach would both reduce duplicate reports and make the review process fairer, since the responsibility would depend on whether the platform provided relevant matches.
(Important: limit the history check to the last 3 months — otherwise the system might become overloaded.) and known bug list stay as it is now.
Mahmood
Aleksndra Mitiukova Thank you! You are absolutely right, this is the only solution. For each product there should be a single known bugs list. Every time a bug gets forwarded or rejected by customer should be automatically added to that list and customers shouldn’t have access to edit that list.
This way every cycle will be a fresh one without any connection to the previous one and this bizarre Copy-Paste rule will die on its own, and all honest testers will test happily there after :)
R
Ramratan M
Hi Sablina,
Thanks a lot for your detailed reply and for taking the time to look into my concern. I really appreciate the clarity in your explanation and the effort your team is putting in to handle this issue better. It’s good to know that the feedback is being taken seriously. Thanks again for your support and quick response.
AV-Master
Aleksndra Mitiukova
Any attempt to delegate the task of detecting duplicate bugs to AI will not only fail to deliver meaningful results, but is also likely to increase abuse. For example, a dishonest tester might try to pass off an old bug as a new one in a way that avoids duplicate detection. Seeing AI hints that a similar bug exists, they would modify the description until the AI no longer recognizes it as a duplicate or only returns similar — but non-identical — cases. They then submit the old bug as new, technically without breaking any rules, and receive full payment for a copied bug. This provides a ready explanation: the system did not indicate a duplicate, so the tester submitted the report and expects full compensation.
Kelvin Addy
Aleksndra Mitiukova
I absolutely agree with you, there have been countless times I’ve had to go back to more than 5+ cycles (all of with 80+ submitted) bugs in order to avoid unintentionally rewriting a bug. It’s very frustrating and breeds fear because some team leaders will always assume you intentionally rewrote the bug despite these constraints.
The addition of an archived bug list or another bug list not handled by the customer would be very helpful and solve this issue in my opinion.
R
Ramratan M
Dear Test IO Team,
I hope you’re reviewing this feedback.
To help testers avoid submitting duplicate bugs and improve efficiency, I suggest adding an “Archived Bugs” tab where all unresolved bugs (except KB) from previous cycles can be stored. Once a bug is marked as fixed, it should be removed from this tab.
This will make it easier to review past reports quickly and focus on finding new, valuable bugs without the risk of duplicates.
Thank you for considering this suggestion.
R
Ramratan M
Hi Test.io Team,
I am scared to submit bugs now, as I recently received a final reminder email about submitting a copy-paste bug.
The challenge I face is that it’s becoming increasingly difficult to verify whether a bug I find has already been reported in previous cycles, especially when there are 10–15 past test cycles reports to review.
If a bug submitted is the same as one reported earlier, I suggest making its payout zero or whatever test.io rules, instead of taking action against the tester’s account.
Aleksndra Mitiukova
Thank you for opening this point!
Bugdigger
Ramratan M This is one reason why I don’t report bugs in cycles I have worked on. I only reproduce other bugs because you could just receive an email saying you copied a bug from previous cycle whereas you have no idea it was on the previous cycle. Thank you for pointing this out.