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 documentations.
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.
After selecting the Feature, the whole bug form will be visible to you. A form for functional bugs, for examples, looks as follows:
You should fill in every field of the bug form with the specific information and according to our quality standards. More detailed information about every field and their requirements can be found below.
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.
The bug report title should summarize the problem, so that the reader gets the 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.
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: Sort method does not work properly
Correct: When setting sort method X, products don’t change 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 action 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.
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 describes 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 the URL of the landing page if you test a website or the app 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 described 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.
- 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
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”.
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 for 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.
As of now, you can leave this field empty. It's a deprecated feature that we currently don't use. It will be removed in the future.
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.
It’s important for us and our customer 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.
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 your 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 for 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!
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
- Tester clearly did not read or follow test instructions
- 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.