In this article, you will learn how to properly document your bug according to our rules and standards. In order to understand a bug, customers need sufficient information with high-quality documentation.

Your first step in the bug report form should be selecting the right Feature. If you cannot find the right Feature in the drop-down list, go back to the test overview page, go through all Feature descriptions and mark them as read. After that, you can go back to the bug report form and all the Features will be presented in the drop-down list.

Bug Form

After selecting the Feature, the whole bug form will be visible to you. A form for functional bugs, for example, looks as follows:

You should fill in every field of the bug form with the correct specific information according to our quality standards. More detailed information about every field and its requirements can be found below.

Severity

For Functional bugs only, you will see an extra field called Severity: Low, High, and/or Critical. The severity indicates the urgency of your report and depends on multiple factors. To learn about different severity levels, please visit the following article Functional Bugs.

The field Severity will not be displayed for other bug types.

Title

The bug report title should summarize the problem so that the reader gets a general idea of the bug just by reading the bug title. They should not have to read the whole report to understand what the problem is. Your bug report title should be precise and not too long at the same time. It should contain the concerned element (e.g. search field), what functionality is broken and the origin of the problem.

When you write a bug title, describe what is happening instead of what is not happening. Your title should never state that something does not work, otherwise the reader has no idea what is actually happening.

Titles must reflect the real problem. If the bug only occurs under certain conditions, the conditions must be included in the bug title. If you are, for example, not able to book a ticket when you state that you are a teenager, this is relevant information and must be included in your title.

To come up with a descriptive title, put yourself in the shoes of someone who never tested the website/app, who cannot picture what page you are on, what it looks like and what you did. Read your title from that person's perspective to see if you would understand the bug. If you don't get a good idea of the bug, adjust the bug title and repeat the process.

Exemplary bug titles

Wrong: Search does not work
Correct: Search is not triggered when clicking the search button

Wrong: The sort method does not work properly
Correct: When setting sort method X, products don’t change the order

What is wrong with the examples above: there are many possible scenarios in which these titles would fit because they are too abstract. The reader does not know what actions you perform and how the system responds to them. Hence, the reviewer has to read through the whole report to understand what the bug is and cannot distinguish this bug from others easily.

URL

Visit the page where the bug appears and copy & paste the URL from your browser's URL field into the field URL of the bug report form.

The URL must be complete so that it redirects to the correct destination.

If you test an app, please leave this field blank unless stated differently in the test description or in the test chat.

Steps to reproduce

Bugs have to be reproducible and they need a detailed step-by-step guide on how they can be reproduced. Each step should describe a separate action. Note that you don't have to number your steps as this is done automatically by our system.

The first step must contain an indication to access the URL of the landing page provided by the customer in the Access section if you test a website or an indication to open the app (with its name) if you test a mobile app. All further steps should describe your actions from the initial step up to the point when the bug occurs – what buttons you press, what links you follow, and what you enter. Your last step must describe the action that you perform that triggers the bug.

Your steps should be as general as possible. Only if your bug occurs under specific conditions, e.g. only for a specific product overview page, for a specific filter, for a specific input, etc., name this condition in your steps. For example, in your steps, don't describe the specific product overview page you visited, then the specific product that you added to the cart if the problem occurs for any product. This will help the reader grasp the idea of your bug and they will not get distracted by irrelevant details.

If you have to be specific, e.g. when you are asked to document what credentials you used to log in to your user account, use the names that are actual words and don’t just smash your keyboard. A bad example would be “asdlkfgjasdfkg lajsdhjasd” as this does not look professional to our customers.

Finally, make sure your steps contain the least amount of actions possible to perform. After reading each step, the person reproducing your reported bug should be able to complete them on the website or app. They shouldn't have to check the same step multiple times to remember what needs to be done.

Exemplary steps

  • Go to http://www.examplewebsite.com

  • Enter any search query in the top-right search bar (e.g. “San Francisco”)

  • Click on “Search Now” or hit the enter key

  • Scroll down and click on "Sort by"

  • Select the option "Sort by price: High to Low"

Exemplary BAD steps

What is wrong with the examples above: The first step must contain an indication to access the URL of the landing page, not just the URL itself. The third step is not enough detailed and contains too many actions in a single step. The second and fourth steps are not necessary to understand the bug.

Actual Result

The actual result is one of the most important fields of a bug report because here you explain what the problem is and all further details that are needed to understand the bug.

What actually happens after following your step-by-step guide should be described as detailed as possible. Try to be very precise and don't be too general by e.g. saying products remain mostly in the same order after applying sort method X but instead describe specific examples of the products that are not in the correct order. Add any information in this field that is relevant to the bug, e.g. examples, further conditions, or exceptions. Just make sure to structure your information to help the reader understand your thinking process.

Important notes: The actual and the expected results must never be just the opposite of each other. Your expectation and what actually happens instead differ greatly.

Similarly, the actual result must not be the same as the report's title. While the title is a summary of the problem, the actual result should be a detailed description of it and should include further details such as scenario information and examples.

Exemplary actual result

Wrong: Town name search function doesn’t work
Correct: After you click on “Search now”, nothing happens. No search results are displayed on a new browser page and the user doesn’t get any message or notification about what went wrong. The button “Search now” does not show any implemented functionality.

Expected Result

Describe what you expect to happen after performing your last described step. As always, details are the key. Think about what should have happened if you had not experienced the bug - if everything worked correctly.

Exemplary expected result

Wrong: Town name search function works
Correct: After entering the town name “San Francisco”, available hotels in San Francisco should be displayed. If there are no such hotels, a corresponding message should be displayed, e. g. “There are no hotels available in your town”.

Attachments

At least one attachment must be uploaded for every bug report. To learn what kind of attachment must be attached for your bug and what rules apply, please visit the following article: Requirements for bug report attachments.


Used environment

It’s important for us and our customers to know which device you used when you experience the bug. When testing a website, click on the browser icon next to the device that you used. When testing a mobile app, select the device that you used for testing and that has the app installed.

You may only use the devices for testing that are listed in this section. Your device, browser, and/or OS version must match the device that you show in your attachment. If you want to select multiple devices or browsers, you must provide multiple attachments, one for each selected option.

Make sure you select the right environment during the submission process because this is the only piece of information that cannot be changed afterwards – neither by you nor the Team Leader. Unfortunately, your report has to be rejected if you select the wrong environment, but you can resubmit your bug if the test is still running and if no other tester has already submitted the bug properly in the meantime.

You would like to test with a device that is not in the list of available devices in your profile? Simply send us a request via the Support chat and we will add your device to your list provided it is relevant to our customers.

Note: When you remove the device that you were invited for from your device list in your tester profile, you can no longer submit reports in this test. The environment section of the bug form will be empty and the form cannot be sent. Deleting a device in your profile cannot be reversed after you've accepted a test invitation!

Improving your report

After you submitted your report, you can still edit all fields except the bug type and the devices/browsers selected. You must always submit complete bug reports that are ready to be reviewed and only use the Edit option in case you've made a small typo mistake or wants to rephrase your words to improve the report quality. Remember placeholders are not allowed, so do not submit incomplete reports to edit them later.

Straight rejection rule

Please invest enough time into documenting your bugs as Team Leaders will not improve your bug reports to reach the required level of quality - It's your job and responsibility. If you are no longer a greenhorn tester, Team Leaders will have to straight-reject bug reports if one or more of the following cases are true for your bug report:

  • Several grammar mistakes (not just a typo)

  • Repeated improper feature choice

  • Overall bug report description is not understandable

  • Unclear bug report title

  • Important steps are missing

  • The tester clearly did not read or follow test instructions

  • The tester submitted a clear placeholder report and then edit it

  • Inconsistent evidence – when the discrepancy between steps and screencast is too large.

  • Incomplete evidence such as missing attachments including missing crash logs.

If one of your bug reports is rejected for low quality, you are allowed to submit it again with proper quality unless another tester has already done it in the meantime. In this case, your bug will be a duplicate and will be rejected.

Related articles:

Did this answer your question?