Tester Feedback

Right now, we can not know that the TC requires proxy/VPN before we accept and Test Cycle starts. I sometimes can not reach any wifi and have to test with cellular data. Because I do not know the requirement before accepting the TC, I can not be beneficial in such Test Cycles. I have to wait till reaching a Wi-fi. This situation is "similar for VPN" also. Testers may prefer test cycles without VPN because of technical difficulties or personal prefers. It is better to provide the requirement about Proxy and VPN before accepting the TC (maybe with the email invitation) so that the testers know these requirements before accepting them.

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.

Reproduction is the only reason if our bugs acceptable or not as an information to be forwarded to customer. But sometimes the bugs condition 'quite unique' and only ONE/Not-At-All positive reproduction that could be seen. Unfortunately, the testers couldn't really see them, and turned out: For negative reproduction: Some Testers want to confirm them via cycle chat, that's not simple (delay respond or not respond at all from respective testers). For positive reproduction: Testers could have a "blind trust" that mislead them to keep the bugs report, even when the reproduction is invalid. Thus, with all those concerns I suggest for testers to have a "right to see" reproductions of their own bugs, as information to decide validity of their findings. That's I believe will help to improve performance scores of the testers. Thank you.

Please show user story which is available without stating session

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.

I want a message like: "Rejected - this is a duplicate to # 12345." I could click on part of the text # 12345 and the system will automatically open the page with error # 12345. Thus, I can immediately and easily open this error, and not search for it manually by the number

The current hourly digest template is absolutely not informative and there is no benefit from it. The link provided in the digest leads to the Payouts page and is absolutely useless. After receiving such a digest, I do not know which cycles were archived and what payments were made. I propose to indicate the numbers of archived cycles, payments in these cycles, and also add links to these cycles.

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.

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."