Tester Feedback

When calculating a tester's level in our ranking, only bugs reported in the last 90 days are considered. I have already noticed a practice of artificially inflating a tester's ranking by copying bugs from other testers (and sometimes their own) in recurring test cycles. As a result, the same bugs are counted multiple times in the ranking calculation, allowing testers to reach the Diamond level effortlessly by simply duplicating existing reports.

On the Test IO - home page "Top navigation bar", the tester clicks on "Activities" and sees the "Activity Dashboard". Further, tap the "Show details" under "Bugs" or "Bug Reproductions". In the result page under column "Type" the text is misaligned. OS: Windows 10 browser: Google Chrome.

On my repro I've got messages like(Rejected - Wrong reproduction type, Rejected - Instructions not followed). I rechecked my repro and I can't understand what's wrong. I'd like to get full description of the rejection reason. So I could understand what I'm doing wrong.

Hello, I was just reading this article where it was mentioned that some testers just assume they know the instructions when the are testing a recurring test cycle. So to improve quality of bug submissions and all, I was suggesting that before a user clicks I have understood these instructions, there should be a QA form, with multiple choice answers. Minor suggestion: dark mode would our eyes a favour 🙃 Regards, Prince Basten

Currently, when a bug is rejected and a tester disputes the decision, if the dispute is not reviewed before the test cycle is archived, the bug status remains unchanged, even if the dispute is later accepted. This delays fair recognition of valid bug reports and may demotivate testers. To improve this, I suggest incorporating AI into the dispute resolution process to ensure disputes are handled as quickly as possible while the cycle is still active. AI can help by: Automating Initial Dispute Review: AI can assess disputes based on predefined parameters, such as past similar cases, tester reputation, and project guidelines. Prioritizing Urgent Disputes: AI can flag unresolved disputes nearing cycle closure for faster human review. Reducing Human Workload: AI can handle straightforward cases while forwarding complex ones to moderators, ensuring efficiency. This change would improve fairness, maintain tester motivation, and enhance the overall quality of reported bugs. I hope you consider this improvement, and I would love to hear your thoughts on it. Best regards, DeoTechie.

Occasionally, either our reports or other testers reports should make an edit for the steps. It could be because after further research, the bug may be more specific than we expected. Thus, the negative reproduction appears. So I guess, it would be more efficient, if the testers who reproduced them would get notification, without the reporter needs to notify them at chat. Thank you.

Quite often in cycles there is a condition to use Markdown formatting to improve the quality of reports. We can use some of Markdown's features manually, but we don't have a Markdown previewer or editor. Therefore, testers need to submit or update their report to see exactly how the Markdown formatting was applied. Sometimes it takes 2 or 3 tries to correct all formatting errors. This is especially inconvenient when writing US-reports. As a workaround, we can use the capabilities of third-party applications, but sometimes the implementation of formatting in such applications is different from implementation on our platform and the text is formatted incorrectly. In addition, beginners very often do not know at all about the possibility of formatting a report. I suggest adding report preview functions and Markdown editor. For example, add two buttons: 'Preview' and 'Formatting'. Clicking on the 'Preview' button will allow us to view a preliminary report and, if everything looks correct, send it. This option will be convenient for formatting standard reports and will allow testers to use it when formatting manually. Clicking on the 'Formatting' button will open an advanced report editing window and allow testers to use the formatting functions with live preview. Perhaps my colleagues will offer other options.

Mistakes often occur during the execution of user stories. It is a good practice to notify team leaders about incorrect execution of such user stories. Unfortunately, such mistakes have to be reported in the test cycle chat, which leads to chat clutter and in the case of many messages, team leaders may not notice such a message. If there is a notification form on the user story page about incorrect execution of a user story, and in the team leader's interface such a user story is marked as requiring a response, then this will make the work of team leaders and testers easier, and also reduce the number of unnecessary messages in the chat. The ideal option would be to select the reason for rejection from a drop-down list, as well as the ability to write a short text message. In addition, there is an option to exclude team leaders from this chain altogether. If the tester is sure that he made a mistake, he himself can reject such a user story.

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)