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
4
·
Product
·
under review
Update Bug Form to make Bug Types editable by expanding Bug Type Dropdown to replace Low/High/Critical Buttons
The Edit button for Bug Reports should lead to an updated Bug Form that's designed to include the option to change an incorrect Bug Type to the correct Bug Type without having to submit another Bug Form just to make that one simple adjustment. Issues: •When the Bug Type is switched from Content or Visual to Functional or vice versa, all attachments and typed-up material (Title, Steps, Actual, Expected) about the bug gets erased on the unsubmitted Bug Form, resulting in a blank form. •When the TL requests that a new Bug Form is created with the same material from the original Bug Report but with the correct Bug Type, the substitute Bug Report may get approved but the original Bug Report that cannot be canceled gets rejected for the wrong Bug Type, which lowers the tester's rank. •Alternatively, when the test cycle ends while the Bug Report is still under review, the tester loses their chance to change the Bug Type, even though the tester is entitled to respond to the TL request within 24 hours and entitled to receive three "TL requests" to make improvements to avoid rejection. However, Edits are allowed after test cycles for every other section of the Bug Form, just not for the Bug Type section. •When such a Bug Report is subsequently rejected, the tester's rank lowers and there is no payout, even if the found bug was a good catch without a similar bug. This rejection also prevents the customer from learning about potentially important bugs to make the fix. •When a dispute is filed, there is usually not a resolution if the tester indeed selected the wrong Bug Type, wasting hours of hard work on the Bug Report, even though other reports that confuse Content for Visual or confused Functional for Content tend to be given leniency and approval. Here is a proposed solution to these issues. On the updated Bug Form design, please replace Bug Type buttons with a Bug Type dropdown list like the following. Bug Type: •Functional - Low (Screencast) •Functional - High (Screencast) •Functional - Critical (Screencast & Crash Report) •Content - Text/Image/Etc. (Screenshot) •Content - Dynamic/Interactive (Screenshot & Screencast) •Content - Upgrade to Functional (Screencast) •Visual - Text/Image/Etc. (Screenshot) •Visual - Dynamic/Interactive (Screenshot & Screencast) •Visual - Upgrade to Functional (Screencast)
3
·
Product
·
under review
Load More