Tester Feedback

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.

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.

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

In the past, I have had some of my bug disputes rejected with Bug Dispute Manager giving clear and educative explanations why my dispute was rejected. However, this was not the case with the latest bug dispute I submitted which got rejected (latest as at the time of this writing). The dispute reply? It was: QUOTE The dispute was rejected I agree with the TL decision here (with both arguments). UNQUOTE QUESTION: + Can there be a structured way of directly addressing and replying to the questions or concerns of the tester raised in the dispute? + Can there be a 100% objective way of reviewing disputes (not subjective or one-liner "agreeing with TL" replies) A bug dispute is an appeal by an AGRRIEVED tester seeking an UNBIASED bug re-appraisal by a NEUTRAL party. Receiving scanty and subjective replies gives the inkling of a bias. As a tester, I sometimes spend hours on regression tests and getting bug dispute replies that lack the attributes of a neutral party, will gradually erode confidence in the dispute mechanism. I don't think test IO wants such impression on their bug dispute mechanism. In my opinion, a bug dispute review by a neutral party should NEVER be subjective, TL-biased or a one-liner approach (an aggrieved tester is like a plaintiff seeking fair arbitration or justice) It should rather ALWAYS have a way of explaining further the test IO guiding principle that justified the bug rejection. This is because tester has no where to go for further appeal after dispute is rejected, so please give a fair, objective, unbiased and sufficiently detailed reply and ensure each concern of tester was addressed and directly replied-to. FEATURE REQUEST: + Can a bug dispute form to include 3 fields be included into the dispute request mechanism? (e.g. "Category", "Pain-point", "Request")? [For the request, first field can be a selectable drop-down. Character count can be limited for the other two fields] Then Bug dispute managers should not be able to submit their reply until they responded within each request field. This way, dispute managers can focus on tester request and ensure that a COMPREHENSIVE reply is given in a STANDARDIZED format. There wouldn't have been any need to make this feature request if things were as they were prior to the last dispute reply I received. Were recent changes, additions (or removals) made to the bug dispute team? I'm wondering because this is the first time I received such a scanty, unhelpful (and unprofessional) reply in a rejected dispute. I would greatly appreciate if my feature request could be implemented. This would go a long way to boost my confidence and trust in this mechanism

Now it's onle no more than 15 seconds. But if you need to show order proccess it take more then 15 seconds. It also applies to other features.

ya maybe you guys can start to implement a new way of contact people and letting them know there tasks available. like maybe by text message. u can send them links to the job that they already qualify for for sure. because they have already meet the criteria to qualify like maybe based on there track record and the jobs they complete and the quality of those jobs they submitted will tell u if they qualify or not

I think it would be nice and cool if there were a way to earn bonuses on top of the payment already making. Things like if we're ur bug reports or info u suit is submitted right and the moderator doesn't need u to go back and fix and it's all good to go the first time submitted then u get a higher rank maybe a higher bonus pay like .2 cents at a time or a one time bonus of like .50 cents and once u get to a certain level u can even start losing pay for incorrect submissions. That way less work for u guys and gives us a motivation to do it right the first time and a chance to make more money