When submitting an issue in the Tester Work Tracker you need to remember that one of the most important parts about your bug is that moderators need to be able to easily find it and confirm its location.
Just like in real life, a rare sighting of a “mysterious new insect species” will be looked upon with skepticism at best and dismissal at worst.
That is why it is very important that you familiarize yourself with the app you are testing, knowing all the ins and outs of this new “habitat” so that you can easily track the location of a bug and know how to find it again and again.
Incorrect steps can oftentimes invalidate an entire bug if the moderator cannot follow your instructions and reproduce an issue on our side. At the very least, incorrect steps will earn you an “Information Request” from a moderator or the bug will be edited and your ranking will be decreased.
We urge you to take a few extra moments to read the following general rules and suggestions that will help you in the long run by having as few modified bugs as possible.
To make sure you remember this information every time you create an issue report, you can follow this simple ABC guideline (All, Brief, Conclusion)
- Rule A. All the steps are required
A good tester should always try to describe the entire process required to reach an issue in such a way that any user can find the issue regardless of any prior knowledge of the app or lack thereof.
If someone asked you on the street for directions you would not start by telling them to turn right at a monument 1 mile away. You would start from the point in space you are in. From the perspective of a Moderator reviewing your bug, your steps need to start at the beginning.
The first step should usually be a variation of: “Install and launch the app” or “Access the URL https://example.com/”.
(In certain circumstances the first step can also be “Install version XYZ of the app on the device”. This step can usually be omitted due to the fact that it is mostly implied, but you can use it when the app crashes at launch and the build version is relevant)
From that starting point of the app interaction, build the other steps in the order required to reach the screen/location where the bug occurs.
Additionally, please avoid skipping steps. If a button needs to be tapped in order to reach a certain screen please mention it in your report, do not take shortcuts like “launch the app and progress to the end screen”
- Rule B. Keep it Brief and simple
Each individual action should be defined by a single step. Do not be afraid to have multiple steps - having more steps does not mean that a bug is less important. Rather than bundling up multiple actions or trying to describe way too much information in one sentence, try simplifying the data into easy to read, easy to understand directions.
Rather than saying “Go to the Home Screen by tapping the button in the corner, then access the side menu, and notice that the app crashes”, try unpacking the information:
“Step 1: Tap the button in the corner to reach the Home Screen
Step 2: When reaching the Home Screen access the Side Menu
Step 3: Notice that the app crashes”
This makes the steps easier to read and also helps you avoid grammatical errors and improper formulations while getting tangled in a sentence longer than necessary.
- Rule C. Always have a clear Conclusion at the end.
This is an often-overlooked element on our platform and we encourage you to keep it in mind.
At the end of your steps, there should always be a final conclusion, a last step that describes the issue.
This step should have the following format: “Notice that the [issue occurs]” (example: “Notice that the app crashes” / “Notice that the text is improperly translated” / “Notice that the text spills out of its designated area”)
When thinking about the structure of a bug, you should consider the steps as an entire story with a beginning and an end, a story that encapsulates the entire information required to find and describe the bug.
Comments
0 comments
Article is closed for comments.