Makes testers have a "right to see" reproductions of their own bugs
closed
Afgan Sofyan
Reproduction is the only reason if our bugs acceptable or not as an information to be forwarded to customer.
But sometimes the bugs condition 'quite unique' and only ONE/Not-At-All positive reproduction that could be seen. Unfortunately, the testers couldn't really see them, and turned out:
- For negative reproduction: Some Testers want to confirm them via cycle chat, that's not simple (delay respond or not respond at all from respective testers).
- For positive reproduction: Testers could have a "blind trust" that mislead them to keep the bugs report, even when the reproduction is invalid.
Thus, with all those concerns I suggest for testers to have a "right to see" reproductions of their own bugs, as information to decide validity of their findings.
That's I believe will help to improve performance scores of the testers. Thank you.
Tetiana Yezerska
marked this post as
closed
S
Sablina
Hello, Afgan!
Thank you for your commitment to improving our platform and for sharing your thoughtful suggestions.
We completely understand testers’ concerns regarding bug rejections related to reproduction issues. Please note, however, that a Team Leader does not reject a bug solely because it has negative reproductions. A bug can be rejected if the Team Leader is unable to reproduce it personally.
Our Team Leaders have a wide range of devices and always recheck reported bugs carefully. The number of negative reproductions has minimal influence on whether a bug is forwarded to the customer.
Additionally, the Team Leader verifies whether each reproducer followed the bug’s conditions correctly, completed all required steps, and adhered to the necessary testing guidelines.
Allowing testers to view reproductions of their own bugs would essentially duplicate the Team Leader’s work and could create unnecessary confusion in the chat. Moreover, reproduction data is considered internal information and, therefore, is not publicly accessible.
We appreciate your understanding and continued efforts to help make our platform better for everyone.
Mahmood
Sablina I’m really disappointed after hearing the decision on this post. I was genuinely expecting that this suggestion will become a permanent TestIO feature and I respectfully disagree with the reasoning that allowing testers to review reproductions on their own bugs would increase the workload for team leaders.
In fact, I believe it would reduce their workload. Let me give a couple of examples from a recent cycle: 144941/2817424 & 2816753 —
both of these bugs were rejected as non-reproducible. The team leader had to review these bugs and all the reproductions and then reject them. Later, disputes were opened in both bugs since there was at least one positive reproduction — but the disputes were also rejected since, the testers had no idea that the positive reproduction had been invalidated due to the wrong reproduction type being selected.
As a result, both the team leader and the dispute team spent extra time handling something that could have been avoided. If testers had been able to review the reproductions themselves, they would have recognised the issue and deleted the bugs before it reached that stage — saving time for everyone involved.
For these reasons, I strongly recommend that this suggestion be reconsidered. I truly believe it would help streamline the process for testers, team leaders, and the dispute team alike.
S
Sablina
Mahmood , thank you for taking the time to share your concerns. We truly appreciate your attention to this matter.
We’d like to clarify that a Team Lead’s decision to reject a bug is never based solely on negative or incorrect reproductions. Team Leads always verify bugs themselves—especially those that are difficult to reproduce or behave differently across devices.
Our TLs are experienced professionals, and we have full confidence in their expertise and judgment. For this reason, additional monitoring from testers is not necessary.
Thank you again for your involvement and for helping us maintain a high standard of quality on the platform.
Tetiana Yezerska
marked this post as
under review
Tetiana Yezerska
Hello! Thanks for your suggestion!
Could you please provide more details about the benefit of seeing reproductions to your bug, and in case you see it what your next actions expected?
Thanks!
Afgan Sofyan
Tetiana Yezerska Hello, thank you for the respond!
For your questions, the benefits what I could imagine are:
- We become more "objective and confident" to keep our finding bugs to be reviewed, even though only ONE "knowingly valid" positive reproduction executed (assumes the issue is valid by cycle scope).
- We have a chance to correct the "invalid" reproduction by "directly asking" the testers (via chat 'at the moment'), either to "support" our own bug reports or just being kindly to help the other testers.
- We could evaluate "more objectives" when we found all reproductions are negative.
In the case all negative reproductions are "valid," we would review our bug steps (instead of clarifying reproduction steps when we couldn't see them):
- If we eventually found crucial missing steps, we would update the steps and ask other testers to update their reproductions (via chat 'at the moment'). With this we'll give more accurate information for customers.
- If we didn't find any missing steps, while the valid negative reproductions in "similar environment," we could "evidently more content" to accept the "local issue" and delete the reports. This way, we keep our performance score from possibly getting worse.
(For all negative reproductions because of "different environment", that is different issue)
These are benefits I could imagine. I realized the new problems will arise when the current problems are distinguished, so the priority values should be considered carefully. Thank you!