I propose to hide the customer's name, as well as hide the list of known errors before the testing cycle and exclude the possibility to see the URL in the instructions.
closed
AV-Master
Now the tester can, by the name of the customer, or in the list of known bugs, find the target site to be tested.
Knowing the site URL, he can test before the start of the test cycle and gain an advantage over other testers.
I believe that opportunities should be equal for everyone.
Imagine running competitions where some athletes run out before the start and receive awards. Absurd.
Tetiana Yezerska
closed
Thank you for your suggestion. We understand your concern about maintaining fairness in the testing process. However, we currently do not see hiding the customer's name, the list of known errors, and the URL as a viable solution.
Numbers of pre-testing has been significantly reduced from that time the suggestion is created, and we closely monitor the situation to ensure fairness among all testers.
Implementing the suggested solution may have unintended consequences and potentially create more challenges.
Rest assured, we continuously strive to improve our platform and maintain fairness among all testers. We appreciate your feedback and will monitor the situation. If you have any other suggestions or concerns, please feel free to share them with us.
Tetiana Yezerska
closed
Thank you for your suggestion. We understand your concern about maintaining fairness in the testing process. However, we currently do not see hiding the customer's name, the list of known errors, and the URL as a viable solution.
Numbers of pre-testing has been significantly reduced from that time the suggestion is created, and we closely monitor the situation to ensure fairness among all testers.
Implementing the suggested solution may have unintended consequences and potentially create more challenges.
Rest assured, we continuously strive to improve our platform and maintain fairness among all testers. We appreciate your feedback and will monitor the situation. If you have any other suggestions or concerns, please feel free to share them with us.
Tetiana Yezerska
Merged in a post:
Add a rule to the academy about the need to synchronize the time before the start of the cycle.
AV-Master
It is necessary to make a rule to the academy that the tester must synchronize the time before starting the cycle. Cases of pre-testing have become more frequent. Then the tester makes excuses that the time was not synchronized.
Tetiana Yezerska
Merged in a post:
Measures to avoid pretesting in tests
l
lionTT
Hello to the whole community of TestIo, the following feedback is for testIo to take action against pretesting on the platform.
We all know that on the platform, users compete in tests to publish bugs and reproductions in tests, that's what makes testIo interesting. But, there is a problem and it is pretesting.
This is something I have reviewed and analyzed in all the tests I have done and that some testers already have the bug reports and the steps that they must perform to reproduce the bug and upload it when the test starts. I even see videos with the time in xx:00 or xx:01 when the test just started with a lot of steps.
Some testers abuse pretesting to just earn the money, skipping the quality of the bugs reports and everything, this is clearly not fair for the testers that are doing quality bugs and waiting for the test to open for testing
Why is this happening?
One of the main reasons is the test title. It gives a clear idea of the page that we are going to test, and of course this is used by some testers for pretesting. On some occasions, URLs can be directly found in the overview of the page that we are going to test, so pretesting can be expected in those cases.
If you see that the test opens, and there is already a bug posted in like 1-2 minutes and the steps require a lot of steps to do it(example account creation) that may be pretesting of a tester that had already everything in a note and did copy and paste everything and did the video really fast because the tester already knows where the bug is before the test opens.
How does this affect us?
As the platform is of competition between users, clearly this is not fair at all for the testers, and to some if we wait directly for the test to begin to do the testing, we do not do it when the test has not even started yet and they have the bugs ready for publication even when the test haven't started.
An example, if you found a bug and you have taken approximately 10 minutes since it is required to create an account on the page and confirm it, another tester has uploaded the same error already with the account created by the pretesting when the test has 2 - 4minutes open.
What solutions could be created to avoid pretesting?
I have thought of some solutions that favor us all and could make the platform more fair and when publishing bugs, and those are:
- Partially hide or censor the test title, hide any clear information that may help the pretesting and hide customer name and make the list of known bugs blocked until the test starts.
In this solution it would be to hide any information that can give a clear idea of what we are going to test, it would be to hide title of the test and information that is related to the web page or the APK that we are going to test within the overview to avoid pretesting(searching it online). When the test starts, it can show all the information and title fully.
Also hide the known bugs list and the customer name, because in known bugs there is information to help pretesting before the test starts by finding the URL or the link that we are going to test.
- Make the link or URL that we are going to test visible in the overview until the test starts.
The tests have a limit of 1 hour to open, a solution could be instead of hiding the link or the URL that we are going to test, it should show the link until the test opens. So we can all start to find bugs on the page without worrying about possible pretesting and post them when the test starts.
- Make a limited time to post bugs after the test has started.
An example, the test has started, but we will not be able to publish bugs after approximately 5 - 10 minutes. The page or link that we are going to test will be available since the test started and we all will be able to go looking for bugs without worrying about someone who has done the pretesting, since there is a 5-10 minute bug block to publish bugs.
These are my ideas that I have thought for feedback, if you have opinions or better ideas, please comment them.
Remember that if you like this feedback please leave an upvote so testIo can see this.
Thanks for reading and let's make TestIo even fairer for everyone.
Tetiana Yezerska
Merged in a post:
It is necessary to add seconds in the “when” column when the tester has created a report. No pre-testing on the platform.
ted
This proposal aims to remove pre-testing from the platform.
The cycle starts at 10:00 PM. After 12 seconds from the beginning of the cycle, the first report has already been added - 10:00:12 PM. We open this report, and see a well-documented report, complete steps, a good description, and a title. We open the screencast and see that the screencast length is 8 seconds. And the tester then has 4 seconds left to write a good report, which causes doubt.
I suggest adding seconds to the "when" column. After the report was created, the system clearly showed the full time of this report. For example, 10:00:45 PM, then 10:01:22 PM.
And when we, as testers and team leader, see such reports, these reports will raise doubts and will be rejected. No pre-testing on the platform.
P.S. Please note that any “screen recorder” has its own technical characteristics. When the tester records video, the computer processes this screencast, that is, it takes a little time to get the finished screencast.
Tetiana Yezerska
Merged in a post:
Testers should be invited to Demo or Sales tests only few minutes before the cycle starts to prevent them from pretesting
Ashley
There is a big problem of testers pretesting in live or demo tests. I would assume they can figure out the test url from the title and start pretesting 1 hour in advance when they are usually invited. This is unfair to other testers. I strongly suggest to send out invitations after the test cycle starts or few minutes before to prevent them from pretesting.
AV-Master
This decision will be unfair for those testers who are not at their workplace when they receive the invitations. In addition, sometimes it is necessary to prepare devices for testing. There is another proposal to solve this problem.
Tetiana Yezerska
under review
l
lionTT
I hope testio reviews this, we have to stop those pesky pretesters!
E
Ervin
This request should have been implemented first.
This request does not interest the administration and this request will be ignored.
Even if you get 200 votes, give a fuck about everyone.
N
Ndirangu
I would rather suggest that all sites be secured with a password
l
lionTT
Ndirangu: That could work too. Customers can add a password to access the site while the test is running so when the actual test starts it give us the password to access the site ans start testing. I have seen this with some staging websites too.
Load More
→