Alright, let’s see what to do when our error is triggered during a normal flow either in exploratory tests or during the execution of a set of test cases. How about an error received when inviting a friend to play along in a mobile game of chess? Well, friends, this is where we start working on the bug report!
First things first, record the flow leading up to the error and make sure you include all of the relevant actions you’ve performed before triggering the error: start from launching the app and record all the way to tapping the “Invite” button which triggers the error. It’s important for both the actions and the error itself to be visible in the bug report attachment. Bonus points for including a screenshot of the error along with the video recording! Let’s move on to the technicalities.
It’s important for moderators and developers alike to have the name of the error visible in the short summary (title) of the bug report.
Let’s compare two short summary examples that describe the same issue:
“An error is encountered when tapping invite”
or
“A “Failed to invite a friend. Error code 3x030” error is displayed after tapping the invite button”
Which one do you think is better? Yeah, the second short summary is giving way more details to the reader and thus makes it easier to find among lots of bugs coming in for review.
Next up, it’s critically important to include any settings you’ve changed inside the app before triggering the error. If your error is encountered only when opting to “Disable” access to your devices’ microphone, then it’s mandatory to include this piece of information in the bug report’s description!
Otherwise, the person responsible for reproducing your bug report and fixing it will consider it invalid, because they won’t be able to see the same thing you were seeing while testing.
For more details as to how to properly write a bug report, visit the Tester Work bug reporting guidelines or our very detailed Bug reporting lexicon.
Comments
0 comments
Article is closed for comments.