Bug reporting guidelines

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 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 that 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 time zone when you reproduced the issue;
• Country;

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

4. Section

The Section/Component field refers to either the in-app location where a bug is identified or the specific element which is defective.

The Section/Component field must be filled in with the exact location where the bug starts to occur. In case the specific screen/section where the bug is encountered is not present within the Section field's list, select the option closest to the point where you've accessed the affected location.

• Not good enough: “Tapping the 1st banner in the “Travel” page will redirect the user to the home page” – Section = Homepage

In this example, the selected section is incorrect because it’s not the screen where the issue is encountered. The issue is the fact the 1st banner in the Travel page redirects to the Homepage, which means the correct section is the Travel page, where the issue is encountered.

• Good: “Tapping the 1st banner in the “Travel” page will redirect the user to the home page” – Section = Travel

5. 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 Favorites 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 “Favorites” section, the product is still displayed in the “Favorites” section.”

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

6. 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 Favorites 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 “Favorites” shouldn’t be displayed after removing them.”

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

7. 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”

 

8. Attachments

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

• Bugs that 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 that 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 that don’t require performing multiple steps can have a simple screenshot attached.

 

Tip to consider for the Short summary (Bug Title) and for the Actual results

When thinking about the few keywords to describe your issue for the Short summary try to pick them in such a manner that, when read together within the Bug Title, the following questions are answered:

• What happens? (What is the issue that occurs?)

• When does it happen? (When does the issue occur?)

• Where does it happen? (In what section/part of the page or application does the issue occur?)

Example:

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

• What happens? > Products are still displayed.

• When does it happen? > Products are still displayed after removing them.

• Where does it happen? > Products from the “Favoritos” section are still displayed after removing them

The above questions can also be used when writing the Actual result, as they can help elaborate on the more specific details of the Bug’s occurrence, that perhaps could not be included in the Short Summary:

Example:

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

• What happens? > Product is still displayed.

• When does it happen? >Product is still displayed after removing it.

• Where does it happen? > After removing a product from the “Favorites” section, the product is still displayed in the “Favorites” section.

 

For more details, please check out our video tutorial!