Tester Feedback

For some cycles, it is mandatory for users to use the Access Claim account to perform testing: Sometimes I am invited to cycles with more than 50 testers and there are less than 10 accounts provided in the Access Claim. Therefore, those who are online earlier can take the account and test first. However, I have noticed that some testers receive the account without releasing it after completing their testing session (user is offline but still claimed credentials). Some other individuals, who have released the credential, choose "NO" when asked "Are there still usable for other testers", which causes the accounts to change to "expired" status and cannot be used for that testing cycle anymore. Therefore, I would like to suggest that our Academy should have clear instructions on releasing accounts, choosing "Yes" when being asked "usable for others or not" so that the accounts can be used by other testers. Additionally, I would also recommend a friendly reminder from the Compliance Team for intentionally holding Credentials after a test session is complete and not releasing them to other users despite being asked by TL in chat, or a warning if the tester does this multiple times. I think this would help all testers get a chance to test if they join in cycles that require credentials (mandatory) to test. Note: If the credential after taken cannot be released to another tester for any reason, it should be clearly described in the "Instruction of the Test" or via Chat by our TLs.

While it’s true that most testers participate to earn payouts, it’s not always about the payout alone. Sometimes bugs are technically valid but don’t meet the required severity for payment. These bugs should still be acknowledged—not necessarily with payout, but at least through backend review or developer insights. Having a neutral way to record such valid but non-payout bugs would help avoid discouraging testers and ensure potentially useful findings are not lost. This approach would also prevent unnecessary negative impact on BRAP scores caused by rejecting technically valid reports. Suggestion: Implement a system to track and acknowledge valid bugs that do not meet payout severity thresholds. This could include a “neutral” status or tag that does not affect BRAP scores negatively but flags reports for backend or developer review. This would encourage testers to submit useful bugs without fear of penalty and improve overall report quality.

While the chat option is available in every test cycle to clarify doubts, severity-related expectations are sometimes not explicitly discussed or confirmed in time—especially in fast-paced cycles. This can lead to valid bugs being rejected simply because they are not deemed critical enough. To improve this process, I suggest: Clearly communicating severity expectations within the test scope, ideally with examples for clarity. Allowing bug submissions to include an optional note such as “Valid but not critical” for team leader or developer consideration. Implementing a “soft submit” or “review-only” tag for educational or informative bugs that may not qualify for payout but provide valuable insights. This would help testers better understand expectations, reduce frustration over rejections, and support a learning environment.

During a recent test cycle requiring Safari on macOS 15.5 with proxy enabled, I faced difficulty connecting the proxy via Safari. While Chrome and Firefox worked using the default configuration, Safari failed silently — likely due to macOS privacy restrictions. There was no option to change the environment; Safari was pre-selected. I initially recorded the bug using Chrome and marked Safari as the environment, fearing my bug would be rejected if I delayed further. Later, with help from the Test IO Discord server, I discovered a working workaround using the PreProxy app, even though existing documentation is outdated. With PreProxy configured, I was finally able to run the test on Safari successfully — no prompts, no issues. 🔗 Reference: Discord Fix Discussion: https://discord.com/channels/562544573952294912/624515360170835988/879362209489223721 Suggestion: Please consider: Adding an article or Academy lesson covering proxy setup for macOS Safari, especially using PreProxy. Mentioning known limitations with Safari and proxy. Clarifying how testers can proceed when no prompt or fallback is available. This would prevent confusion during time-sensitive cycles and support testers working with Safari environments. Note: This is a known issue and not a bug report. Just feedback based on real experience. I’m not implying this is mandatory — just sharing for consideration.

After earning a badge, when clicking on the notification in the mobile app, I am not redirected to the badge section. Instead, I have to manually navigate there, which affects the smoothness of the user experience. This issue does not occur on the web app—there, clicking the badge notification correctly takes me to the badge page. Suggestion: It would improve user experience and consistency if the mobile app notifications redirected users directly to their badge page, just like the web app does. Note: I cannot provide a screenshot or screencast at the moment, as no new badge has been awarded recently. I will share attachments as soon as a new badge notification occurs.

While writing a bug report on the Test IO web platform, I’ve observed the following issue when spending an extended period on a single report: The session timer stops updating after a while. The bug count in the “Bugs” tab does not reflect new submissions from other testers during that period. These updates only resume after the page is manually refreshed. From my experience, this tends to happen when the browser tab becomes inactive or remains unfocused for an extended period. This behavior can lead to confusion, such as: Thinking there’s still time left when the timer has expired. Not realizing that other bugs have already been submitted, which could potentially lead to duplicate reports. Suggestion: Please consider implementing real-time synchronization for session data (like the timer and bug count), or at least show a notification/warning when updates have been paused due to tab inactivity. This would ensure testers stay fully informed during longer bug entries and reduce avoidable issues. Where: Test IO web app → While writing a bug report When: After prolonged editing and browser tab inactivity What: The Timer and bug count stop updating automatically Note: I cannot provide a screenshot at the moment as no test sessions are currently available. I’ll attach one as soon as a cycle goes live.

Sometimes while testing, it’s unclear whether a particular issue is in scope or not. While the team chat is an option for clarification, responses aren’t always timely or accurate, as not all testers feel confident answering such queries. This uncertainty can lead to: Missed bugs due to hesitation. Time wasted waiting for confirmation. Potential out-of-scope reports being submitted. Suggestion: Please consider adding a simple scope checker tool in the web or mobile app. It could allow 1–2 quick questions per tester per cycle where they can get scope validation from a reliable backend source or a predefined ruleset. This tool would not replace reading test instructions (which should always come first), but it could serve as a backup layer of clarity — helping testers move with greater confidence and precision. Where: Test IO web/mobile app → During test cycles When: While unsure about a bug’s scope What: No existing feature for quick scope verification Note: This is a feature request — such a scope checker does not currently exist, to my knowledge.

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.

Every time a tester subscribes to a cycle, this email is sent. Honestly, this email is wildly tired. The interface clearly shows that the tester is subscribed to the cycle. Remove this email because it just bothers or make a setting so that can turn it off. This is one of the dumbest emails around.

During testing, the customer first rejected the report with the status "Rejected - this bug is not relevant to the customer and will not be fixed." The second time, another tester found the same bug that was previously rejected by the customer, but the tester itself did not participate in the first cycle. Since the bug itself is not displayed in the "Known Bugs" column. Thus, a repeated bug will be rejected by the team leader. A proposal, so as not to take time from team leaders, to update the "Known Bugs" column constantly when the report receives the status "Rejected - this bug is not relevant to the customer and will not be fixed."