Tester Feedback

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.

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.

Its four months into the post-Cirro era and personally, payments are now slower than ever. More often than not, freelancers get paid bi-weekly, and if payments are going to be monthly the expectation is that they come in swiftly to accommodate the wait-time. Last year it was a lot faster than it is now. Here's what I propose: The payments request window should last a maximum of 3 days (10 days to initiate a payment request is quite unnecessary). Payments should be sent on the 15th of every month and the wait period to receive payment should be from the 15th - 23rd of the same month. Currently we work for 30 days and receive payments after another 21(+/- 9) days. This proposed timeline shaves off at least a week off of that without any dramatic disruptions to the current system.

Some tests have mobile apps and, in the app, the download link have a space, so it's not clickable. If every link was clickable, that would help us a lot.

Now devices usually are updated automatically, and in some test (e.g Streaming testing), when a tester joins a new cycle, then sees the OS of the device, it notices the device have updated to a new version, but the list of devices in the account section is not updated accordingly. The tester has to ask TL or contact support for this matter (request an update), but since tester needs to have the updated device OS to properly participate in test, the issue is sometimes TL doesn't want to update the list since it is not his/her function. It generates an issue to tester since he/she has to wait the response of customer support and therefore delays the time available for testing, and worst case, tester has to quit test.

Please show user story which is available without stating session

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)

It happens often that a tester can miss a test inviation and when the tester sees the notification there are no more slots in this test and it dissapears from the dashboard.Anyways after a while a slot can be avaliable and the test inviation appears in dashboard. I suggest that a notification will be sent (by email and Testnow app) to the testers who missed the invitation when a slot becomes avaliable and the invitation is shown in dashboard, in order to accept the test invitation immediately.

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