Tester Feedback

I do have a few suggestions for improvement which will definitely helpful not only for tester but also for Test io growth: Warning Policy: The current "three warnings" policy feels a bit strict, especially considering it applies over a tester’s lifetime on the platform. I believe that after a certain period, these warnings should be reset if the tester has shown consistent improvement. People grow and learn, and offering them a clean slate after demonstrating progress would be motivating and fair. Of course, if mistakes continue without signs of improvement, stricter action would be understandable. TL Reporting Process: Some TLs (not all) tend to report testers immediately without giving a prior warning or guidance. I don’t think this approach is entirely fair. Everyone can make mistakes occasionally, even TLs. For example, if a tester received a warning in the past but makes another mistake after a long period, the TL should ideally inform them first rather than immediately reporting it. This kind of feedback loop would help testers improve and would benefit the overall quality of the platform.

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.

Hello TestIO Team, According to TestIO Academy’s rejection reasons, the categories “Not a Bug” and “Other” are especially risky. These reasons often depend on subjective judgment — for example, a team lead may have one opinion, while several experienced testers see the issue differently. Example cases: 2814509, 2814496. It’s clear that new testers sometimes submit weak or irrelevant bugs — that’s part of the learning process. However, for experienced testers (Level 4–5) there should be a conflict-free review system for such cases. When a tester with proven experience gets a rejection like “Not a Bug” or “Other,” the decision should not rely solely on one team lead’s personal interpretation. Team leads, being experienced professionals, naturally have their own perspective. But sometimes this leads to situations where decisions feel one-sided — as we say back home, “I’m the boss, you’re the fool.” This kind of approach demotivates testers and can damage communication, especially when rejections feel emotional rather than analytical. To make the process fairer and more transparent, bugs rejected as “Not a Bug” or “Other” should: • undergo a double review (e.g. by another team lead or senior QA), or • be escalated to the client for the final decision, with the possibility for testers to challenge such decisions without opening a dispute and without payment for tester until final approval or rejection in the second round . But only for testers lvl4 and 5 and “Not a Bug (intentional behavior) and “Other” reasons. Disputes are stressful and often create cold conflicts between testers and team leads, which harms motivation and teamwork. Adding a neutral review layer for these subjective rejection categories — especially for experienced testers — would make the platform fairer, more motivating, and more professional for everyone. Thank you for your review! Best regards, Aleksandra

It is sometimes very confusing when the exact same bug behavior is accepted in one test and rejected in another test. I say this because I had a very recent experience of this. For instance, a case where the TL never mentioned certain exclusions in the chat but goes ahead to reject bugs (e.g. bugs reported on credit card encryption issues or bugs reproducible only on specific device or browser OS) If some TLs cannot be clear on these kind of exclusions, then Test IO should be clear on such disputable issues (e.g. on reproducibility, I have also seen bugs where none other tester could reproduce positively, still get forwarded to customer because it was OS or device specific). Up till this time, it’s still unclear why Test IO is permitting such inconsistencies on bug rejection reasons from some TLs even after a bug dispute (especially when exact same bugs have been approved in previous tests) In such cases, the TL position should not be agreed-to in a bug dispute (especially when such exclusions were not made clear in the test scope, chat or Test IO academy but are valid bugs). If Test IO did not state in the academy that certain bug scenarios be not reported anymore, then ALL TLs should ALWAYS state test-specific exclusions (not stated in out-of-scope section) in their opening comments via chat (e.g. in this test TL approves card encryption caching bug, in another test TL reject exact same card encryption caching issue). This is just one example. I could go on-and-on with other examples. I would really appreciate Test IO to look into such disputable issues and to revise the bug assessment sheet to provide clarity and classifications for such bugs.

This is particularly for test cycles which haven't had a single bug reviewed at the expiration of the allotted time. There are cases where testers are unsure if a bug is a duplicate and wait for the TL to review the similar bug, but the TL doesn't begin review until the test cycle ends. This also helps for bug reproductions where there isn't sufficient clarity as to whether it is a bug or not.

Hello Everyone, I have also noted, and you must have also noted how test invitations/confirmations/test cases/user stories are accepted at the speed of light. I don't think I also manually accept, but by chance, a confirmation/test case gets accepted, but how do some testers accept these things so quickly? Ever thought about it? As far as I think, some testers use bots/Auto Clickers that automatically do this work. Now I may receive criticism for this and I am absolutely ready for it :) So, idea (by the way it's a suggestion from TL Victor) is that something should be done that would allow test case/confirmations/test invitations to be manually accepted. For example, the inclusion of CAPTCHA.