Welcome to our first newsletter of 2018. We hope these pieces have helped to keep you updated with tips and tricks and best practice advice on how to use the Tester Work Platform (more) effectively, how to report better bugs and how to get paid more in the long run.
For the 4th issue of our newsletter, we will be checking out the last possible rejection reason available – “Poor Quality Report”.
This resolution focuses almost exclusively on the information provided or requested from the tester. If there is information or evidence required, this needs to be included. Sometimes a client specifically requests that something must be included in the report. If this is missing, the issue will be rejected.
- Read the tester spec. This makes us sound like a broken record, we know, but really, all the information you need to test will likely be in that document. Evidence does not refer simply to a video or a screenshot. Some cycles will have additional requirements in addition to the standard requests. You may be requested to provide a specific log or attachment, in addition to the video or screenshot. Other times you may be requested to add login-credentials, title tags, etc.
- Provide the right evidence for the right situation. Often times we see testers provide screenshots for dynamic issues. This is wrong. If an issue needs to be observed in action to be understood, a video needs to be provided. A flickering screen? Stuck in a loading loop? Application crashes? A button doesn’t work? Provide video evidence. Screenshots are intended for static behaviors that do not require user input to trigger. Some examples include text typos, overlapping* or misaligned images, etc
*Note that a static issue will require a video if the user needs to force the behavior to occur. Example, if a text field starts overlapping another field only when the user taps on it, it is no longer a static behavior.
- Ensure the report is clear and easy to understand. Sometimes the report is simply poorly written and is misunderstood. Ensure the sentences make sense, are written in proper English and can be easy to follow. If the description of the issue is too complicated or not clear enough, it can be misunderstood for another issue, or it simply cannot be reproduced.
In Closing: General tips
The tips and suggestions provided thus far are intended for specific situations, however, there are things you can do to generally improve your testing experience and thus magically increase the number of issues successfully reported.
Sometimes it’s better to be over-cautious. If you are not sure if some kind of information is required, or what type of evidence is needed, it is best to over-deliver.
Unsure if the behavior is static or dynamic? Add a video just to be safe. Unsure if the login credentials are required for your specific issue? Add them anyway. It is much easier and faster for our team to remove a piece of information from a report than to mark your issue for investigation, wait for your update, re-check, and accept/reject.
Ask questions. If you are having difficulties understanding something, contact us. Our Zendesk is available for questions and queries. We will try and provide any assistance you need. Simply open a ticket, explain your issue and we will get back to you with an answer as soon as possible.
We hope you found this issue helpful. We want our newsletter to be valuable to you so please share your feedback or suggest future topics. You can also check the previous newsletter issues here.