Tester Feedback

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.

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.

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.

The Edit button for Bug Reports should lead to an updated Bug Form that's designed to include the option to change an incorrect Bug Type to the correct Bug Type without having to submit another Bug Form just to make that one simple adjustment. Issues: •When the Bug Type is switched from Content or Visual to Functional or vice versa, all attachments and typed-up material (Title, Steps, Actual, Expected) about the bug gets erased on the unsubmitted Bug Form, resulting in a blank form. •When the TL requests that a new Bug Form is created with the same material from the original Bug Report but with the correct Bug Type, the substitute Bug Report may get approved but the original Bug Report that cannot be canceled gets rejected for the wrong Bug Type, which lowers the tester's rank. •Alternatively, when the test cycle ends while the Bug Report is still under review, the tester loses their chance to change the Bug Type, even though the tester is entitled to respond to the TL request within 24 hours and entitled to receive three "TL requests" to make improvements to avoid rejection. However, Edits are allowed after test cycles for every other section of the Bug Form, just not for the Bug Type section. •When such a Bug Report is subsequently rejected, the tester's rank lowers and there is no payout, even if the found bug was a good catch without a similar bug. This rejection also prevents the customer from learning about potentially important bugs to make the fix. •When a dispute is filed, there is usually not a resolution if the tester indeed selected the wrong Bug Type, wasting hours of hard work on the Bug Report, even though other reports that confuse Content for Visual or confused Functional for Content tend to be given leniency and approval. Here is a proposed solution to these issues. On the updated Bug Form design, please replace Bug Type buttons with a Bug Type dropdown list like the following. Bug Type: •Functional - Low (Screencast) •Functional - High (Screencast) •Functional - Critical (Screencast & Crash Report) •Content - Text/Image/Etc. (Screenshot) •Content - Dynamic/Interactive (Screenshot & Screencast) •Content - Upgrade to Functional (Screencast) •Visual - Text/Image/Etc. (Screenshot) •Visual - Dynamic/Interactive (Screenshot & Screencast) •Visual - Upgrade to Functional (Screencast)

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

Please allow testers with large touch-screen All-in-one Desktop Computers the option to test Mobile Websites that are uniquely accessible through their default Split Screen feature. After all, the Academy supports testing in combination with other features to spot differences. Screen-splitting the browser window of a fully-maximized Traditional Website down to its typical half size will make it behave like a normal Full Screen Mobile Website. A long-established Traditional Website may require more time to bug hunt when it is less likely to contain bugs than their newer unidentical-twin Mobile Version. Accessing a Mobile Website through a touch-capable Desktop Computer and testing it with a mouse is much easier than through a touch-exclusive Smartphone, the latter which requires additional screenshots of its time/date. Mobile Web Designs tend to function identically and consistently on both Computers and Mobile Devices, so any bugs found through a Split Screen are real, not forced. This workaround using an All-in-one Computer feature can boost the ability to report the bugs encountered by Smartphone and Tablet users, which would interest many of our customers with Mobile products.

Tester should be allowed to delete user story (pr ability to modify) //If required you can keep some tiemframe. say , user can edit it withing 1 hour of submission or something like that

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.