Tester Feedback

Hello, Currently, testers face a limitation: they can't leave feedback once a test cycle ends. This poses a problem because testers often prioritize bug hunting over providing feedback, leaving them with insufficient time to share their insights before the cycle concludes. Why Implement This Change? Testers' Focus: During busy test cycles, testers are primarily focused on identifying and reporting bugs, which can lead to neglecting feedback submission. Insightful Input: Allowing feedback submission after the cycle ends enables testers to provide more thoughtful and insightful input as they become increasingly familiar with the app/website through testing. Proposed Solution: Extended Feedback Time: Users should retain the ability to submit feedback even after a cycle ends, possibly until the test is archived. Eliminating Rush: This approach eliminates the rush to provide feedback, allowing testers to allocate more time for thoughtful responses as their primary focus shifts from bug hunting to feedback provision. Implementation Benefits: Relevant Feedback: This improvement leads to the submission of more relevant and valuable feedback for the customer, enhancing the overall quality of the product/cycle. Tester Empowerment: Empowering testers to contribute effectively to the improvement of the app/website without compromising bug reporting priorities enhances the efficiency and effectiveness of the testing workflow. Thank you.

In repetitive test cycles, I as a tester would like to know which are the comparatively newly added features by looking at the known bugs count. This will help me target newer sections of the app or features which haven't been thoroughly tested yet

The new filter menu is convenient and has more filtering options, but there is no indicator for the number of reported bugs for features and types. Some test cycles have a limit on the number of bugs, for example only 10 Low bugs. Therefore, to determine the number of bugs already reported, testers need to apply a filter and see how many bugs have already been reported. This is inconvenient, especially since sometimes testers delete their reports and thus the number changes. In the previous filter menu, the drop-down menu showed the number of reported bugs with features or bug types. I suggest adding a bug counter to the filter menu.

I add reproduction for an issue, I delete it and when I add a reproduction again it does nothing (the page just refresh and nothing happen)

1.We have to wait hours for the team leader to respond. Since the team leader is currently unavailable and does not see the message. When the tester sends a message in the chat, the team leader automatically receives a message on his email. To avoid spam, enter the form via @TL. Thus, random chat messages will not be spam for the team leader.

Gamification can be an effective strategy to enhance user engagement and encourage desired behaviours within our platform. Here's a description of how the gamification system could work: Testers' Profiles: Each tester on the platform would have a profile that showcases their accomplishments and participation. The gamification system would add various elements to the profile to showcase their achievements and progress. Experience Points (XP): Testers would earn experience points for completing tests, providing valuable feedback, and actively participating in the platform. XP would reflect their overall engagement and expertise level. Similar to the Seasonal Ranking but without getting reset. Along with the Badges, Achievements: These should be displayed by default or by the tester’s desire on profiles. For instance, the system picks the most given badge on the tester’s profile image, or the tester can select the one they want to stand out on their profile (displayed similarly to the current Great Testers badge). Skill Levels: The gamification system could assign skill levels to testers based on their proficiency and performance in different testing areas. This would help clients identify testers with specific skills and expertise. Cross-Device Integration: The gamification system should be accessible and visible across different devices to ensure seamless engagement for testers. Web Interface: Testers can view their profiles, badges, achievements, and leaderboard rankings through the platform's web interface. They can track their progress, compare themselves with peers, and aim for higher achievements. Mobile App: testNow would allow testers to view their progress. Push notifications and alerts can also inform them about new opportunities or updates related to the gamification system. Overall, this gamification system would be a motivational tool to engage testers, recognise their contributions, and incentivise good practices within the crowdtesting platform. It would create a sense of achievement, healthy competition, and a community-driven environment that encourages testers to actively participate and abide by the platform’s rules. Note: other data for TLs should be considered added up to the abovementioned items should be added for TLs.

As a tester, I would like to see the test cycle ending time also in the dashboard invitation (before the cycle starts) to avoid entering a test cycle which is not fitting to my time schedule.

When the tester enters the Bugs section, it sees the contents of the reports in brevity. It saves time. But the tester does not see if a reproduction is necessary for the report. Highlight those reports that require reproduction. It often happens that there is no reproduction because the tester does not have time to review each report. Sometimes TL asks testers to add reproductions. But this is also not always possible. Especially when a lot of reports. There are rejected the report due to the lack of reproductions. It would be helpful for the tester to see reports that require reproduction. That would be more convenient.

Sometimes the testers make a mistake and choose a different browser than the one in which the bug occurred. After submitting the report, it is no longer possible to change the browser, so the tester must either submit a new report or try to reproduce the bug in the browser that was mistakenly selected. In the first case, it takes time, especially since it may happen that later a duplicate of this bug will be provided by another tester. Thus, the tester loses money for a valid bug. In the second case, this is not always possible. For example, the bug only happens in Safari. Therefore, the ability to change the browser in the report will improve the user experience and reduce the suffering of testers.

I miss the tab of Bug Fix Confirmations activities, sometimes I want to see the status and which I did. Since there are Bug Report Confirmations there