In order to increase your chances of getting the maximum payout for a bug, your report needs to be clear and complete! Paying attention to grammar and providing all of the required details will benefit your tester rank and payout.

Bug report components

1. Short summary (Bug Title)

 

The short summary of a bug report is the most accessible way of figuring out what the reported issue is. This is the first impression and it usually influences the overall quality of the bug report.

 

The short summary must be short and must describe the issue in a few keywords.

 

Examples:

 

    • Not good enough: “Incorrect products displayed in Favoritos”
      • This example shows an incomplete description of the issue.
      • Why are those products incorrect? What actions have you performed before seeing they’re displayed there?

 

    • Good: “Products from the “Favoritos” section are still displayed after removing them”

2. Default issue type fields (Device, OS version, Reproducibility, Component, etc.)

 

The default issue type fields outline the technical details of the reported issue.

 

It’s mandatory for all of these fields to be accurately filled in a bug report:

    • The component selected by the tester must be the one shown in the attachments section of the bug.
    • The mobile device field must be filled in with a device which is in scope for the test cycle.
    • The severity of the bug report must accurately depict the impact the bug has on the user’s interaction with the app. For example, a critical bug is an issue which blocks the user’s interaction with the main functionalities of the app.
    • The Reproducibility of the issue represents the number of times you’ve encountered the bug following the exact same reproduction steps.

 

There are exceptions when some of the fields may be left empty, such as the “Mobile device” field for a bug reported on a Desktop testing cycle.

3. Custom issue type fields

 

The custom issue type fields are the additional fields required for submitting a bug report on certain projects. The most common examples of custom issue type fields are:

 

  • Credentials: please provide the email address/username & password (for your test credentials & for credentials provided in the test spec document) OR only the email address/username (when the sign in is done with your personal account)
  • Timestamp: please provide the time and timezone when you reproduced the issue
  • Country

 

It’s mandatory to fill in these fields with the relevant information in your bug report.

4. Actual results

 

The Actual Results field represents the behavior encountered in the app when/after performing certain actions.

  • The Actual results field should be different and more explicit than the Short Summary, but it can also be the same if the issue doesn’t require lots of explanations.
  • The Actual results field needs to describe the actions taken before encountering the issue as well as the issue itself. An actual result that only points out the issue is not good enough.

 

Examples:

  • Not good enough: “The Products in Favoritos are still displayed”
    • This Actual results example isn’t good enough because it doesn’t describe the actions performed before encountering the issue.
    • You should answer the question: Why is it an issue that the Products are still displayed? -> Because you previously removed them. You must include the action taken before encountering the issue.

 

  • Good: “After removing a product from the “Favoritos” section, the product is still displayed in the “Favoritos” section.”

 

We advise being as specific as possible in filling the required fields.

5. Expected results

 

The Expected Results field represents the behavior the app is expected to show. If you’re tapping on a picture on the Facebook Newsfeed, the expected behavior is for the picture to be enlarged/zoomed in.

 

  • The Expected results field needs to describe the actions taken before encountering the behavior, not only the behavior itself. An Expected Results field that only points out that “X thing shouldn’t happen” is Not good enough.

 

Examples:

 

  • Not good enough: “The Products in Favoritos not displayed”
    • This Expected Results example is not good enough because it doesn’t provide any details as to what is expected to happen.
    • You should also answer the question: “Why shouldn’t the Products be displayed anymore?”

 

  • Good: “The Products from “Favoritos” shouldn’t be displayed after removing them.”

 

We advise being as specific as possible in filling the required fields.

 

 

 

6. Steps to reproduce

 

The steps to reproduce are a key component of the bug report. These instruct the reader as to how they should reproduce the issue.

If the steps to reproduce are not clear enough, the moderator will not be able to reproduce the issue and it will be rejected.

 

  • The steps to reproduce need to provide full visibility on the actions the tester has taken up to the encountered issue.
  • The steps to reproduce need to have only 1 action per step.
  • The steps to reproduce need to end with a step similar to the Short summary, so that the issue is clear.
  • “Observe” is not a complete/valid step.
  • Steps to reproduce can’t be actions described from a first-person perspective: “1. I open the app. 2. I observe this”

 

Examples:

  • Not good enough:

“1. Launch the app and log in

2. Observe”

 

  • Good:

“1. Launch the app

2. Login

3. Observe the Home Screen is shown instead of the Welcome screen”

 

7. Attachments

 

It’s crucial for you to provide proof for the bugs you report in the tracker.

  • Bugs which require multiple actions to reproduce must have a Video attachment!
  • Video attachments should never have any background audio except for when the bug is related to the audio functionality of the app.
  • Touches and gestures must be shown while screen recording.
    • iOS: Enable AssistiveTouch
      • Go to iOS Settings > General > Accessibility > AssitiveTouch
    • Android:
      • Open Settings on the Android device.
      • Go to About phone
      • Scroll to the very bottom of the menu and select Build number repeatedly. After the 7th or 8th click you should see a message telling you that you are a developer.
      • Click back to return to the main Settings menu.
      • There should be a new ‘Developer Options’ option above to ‘About phone’ option. Select ‘Developer Options’.
      • Under the ‘Input’ heading there is a ‘Show touches/taps’ option. Selecting this will show all touch events on the screen including pinch to zoom gestures and so on.

 

  • Video attachments can’t show internal Tester Work or Global App Testing communication (emails) or documents (google spreadsheets, docs). We advise closing all your background apps which aren’t related to the testing project and avoid showing personal details unless specifically instructed otherwise.
  • Crash bugs must have crash logs attached!
  • Connectivity bugs must have a Speedtest.net connectivity test performed in the video attachment!
  • Truncated text/incorrectly translated text/pixelated display/general display issues which don’t require performing multiple steps can have a simple screenshot attached.
})(jQuery)