Tester Feedback

Dear Team leader, I hope this message finds you well. I wanted to share a suggestion that I believe could improve our testing efficiency and reduce frustration among testers. Currently, when the number of seats for a test is full, all testers often explore the same areas randomly. This can lead to duplicate bug submissions, which is both time-consuming and discouraging, as significant effort is invested in discovering issues that later get marked as duplicates. To address this, I propose assigning specific areas to testers or dividing testers into teams, with each team focusing on a designated section of the application. This approach would: Minimize duplicate submissions. Ensure broader coverage of the application. Enhance the overall testing experience for everyone involved. I believe this could streamline our process and make testing more productive and rewarding. I’d be happy to discuss this further or provide additional insights if needed. Thank you for considering my suggestion. Best regards, Bednegoh Seme

In test cycles there are sites that are tested repeatedly and the list of known bugs is very large. It takes a lot of time to get acquainted with them. It is simply impossible to remember, especially when you take part in several test cycles. The bug title does not always contain enough information to immediately understand it. You need to see the steps and screencast. It takes a lot of time. Sites with so many known errors should be paid higher. Now I take part in the test cycle # 40484 (319 known bugs)

The minimum payment for reproductions should be € 1.

It's been a long time that I get invitations after other testers have already submitted required number of bugs (they always get invited before me). I also can't submit reproductions as there would be not slots for those as well.

Its four months into the post-Cirro era and personally, payments are now slower than ever. More often than not, freelancers get paid bi-weekly, and if payments are going to be monthly the expectation is that they come in swiftly to accommodate the wait-time. Last year it was a lot faster than it is now. Here's what I propose: The payments request window should last a maximum of 3 days (10 days to initiate a payment request is quite unnecessary). Payments should be sent on the 15th of every month and the wait period to receive payment should be from the 15th - 23rd of the same month. Currently we work for 30 days and receive payments after another 21(+/- 9) days. This proposed timeline shaves off at least a week off of that without any dramatic disruptions to the current system.

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.

The dispute are supposed to be the final stop at redeeming a bug decision, so it’s disheartening when the dispute manager doesn’t review the cycle (overview, instructions, bug lists and chat) so they understand the context of the test. On more than 1 occasion, I have encountered situations where the dispute manager’s response is out of context or irrelevant to the bug. So I would suggest we are able to respond to the dispute manager to review their decision A recent example involves a cycle where we were given a link to an html to be opened on browser and then sent the same html as email. The aim was to compare the 2 html and report any visual or content issue that differentiates the 2 htmls Also, in this cycle, each feature was a different client as clarified in the chat and from past experience with the cycle. So I submitted content bugs for missing phone number links which were present in the html on browser but TL rejected as functional. So another tester and I opened a dispute. In mine, I made the argument as to why it was content not functional, according to the academy and linked a video of comparing the html on browser with the email clients. The other tester also argued using academy, why it was a content and then linked the html browser link. My dispute was rejected as a UX and a duplicate, but the other tester’s own was accepted as a content bug. If my dispute manager had reviewed the cycle they would not reject for such reasons.

Lately the platform has been massively spread and a lot of testers have joined . Most of the testers accept tests and dont work in them , stopping another one from working . Lately we all have seen "all seats have been taken" message , even if the test has 1 minute that was available. More testers that want to work see their dashboard empty because irresponsible testers accepts tets and don't work in them . So I suggest giving a warning to testers who accept tests but don't work in those tests

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.