Tester Feedback

Use this form to (publicly) submit your feedback and feature ideas. Others will be able to vote for and discuss your idea.
Faster Payment Processing for Accepted Bugs (Before Client Approval)
Hello TestIO Team Currently, testers have to wait 10 days after a test cycle ends for the client’s approval before payments are transferred to Cirro. In practice, this waiting period ( waiting up to six weeks ) doesn’t bring much value — clients almost always approve the cycle anyway, and it’s never the case that all bugs are rejected or everything changes after those 10 days. As a result: • Testers lose motivation during the final 10 days, knowing that accepted bugs won’t be included in the next month’s payout. • Payments are unnecessarily delayed, even though the work is already reviewed and accepted by the team lead. • Since payouts happen only once per month, this delay significantly affects income planning. On other similar platforms, once a bug is accepted by the team lead, it’s marked as payable immediately — even if the client’s review comes later. Bonuses or client adjustments can still be processed afterward. We understand that client contracts may require formal approval, but tester payments should not depend on that. Even in construction or other project-based industries, workers are paid for completed and accepted work regardless of when the client settles the invoice . The same logic should apply here — testers deserve to be paid for their accepted work without unnecessary delays . Besides, this change would also benefit team leads — with smoother payout cycles and happier testers, maybe some of them would even stop being so strict and grumpy sometimes. 😉 For example, if I publish 10 bugs on the 2nd of the month and the client approves the test only 10 days later, while payouts are made every 10th, it means I’ll receive payment for that work about 1.5 months later . That’s an unreasonably long delay — the work is completed and accepted internally, yet testers have to wait for client approval and then another payout cycle. In any normal work setting, waiting six weeks to be paid for accepted work would be considered unfair. Ideally, accepted bugs should be transferred to Cirro immediately after the test ends, and client bonuses or adjustments can be added later once the client approves the cycle. Alternatively, introducing two payouts per month would already make a huge difference and solve most of the motivation and cash flow issues for testers. Suggestion: Either: 1. Allow payments for bugs accepted by the internal QA or team lead to be processed immediately to the Cirro (before full client approval), or 2. Introduce twice-monthly payouts to make earnings more consistent and motivation higher. This would improve: • Tester motivation and engagement • Team lead–tester communication • Overall satisfaction and trust in the platform Thank you for reviewing! Best regards, Aleksandra
3
For testers lvl4,5 double review for “Not a Bug (intentional behavior) and “Other” rejections
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
0
Load More