Tester Feedback

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.

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.

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

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.

There are some tests that share bug lists and, then, some tests from other cycles appear. Can you add a sign when the bug is from one cycle but appears in another? It can ease reproductions by a lot.

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)

When closing the tab or application on some sites, "Are you sure you want to close this tab without saving the written texts?" question should be added.

The minimum payment for reproductions should be € 1.

I have an idea about notifications on the website, maybe dev team can add a sound signal on the website for notifications like in some web messenger? If test.io tab in a browser is open, when tester gets new notification (invitations, test archived, bug forward to customer or rejected etc.) with some notification sound. And tester can set what notifications he wants to get with sound in notification settings. This will allow testers not to miss any notification. Especially new invitations.