A good bug report helps the development team enormously to make targeted improvements to the application. These reports also enable the developers to classify the urgency of the bugs. These reports are written during the testing of an app or other digital software and provide detailed information about the bugs that occur.
In this article, we will show you what is important in a good bug report and which errors you should avoid in order to make it as easy as possible for the development team to correct errors.
Why a bug report at all?
During the testing of an app or other software, bug reports are created by the testers in order to provide the development team with a detailed report at the end. With the help of the bug reports, they can then correct the application in such a way that the user does not encounter any problems when using it.
But how should these bug reports be structured? What must be included in these reports? Is every bug a barrier for the user?
We will now answer all these questions.
Clear and precise title
- A good and meaningful bug report starts with the title. A good title should give the developers a first outlook on the problem. If the most important information is already included, developers can prioritise the bug right away. An effective bug title should be structured as follows:
<Area of the app>: Short description of the problem.
Example:
Check-Out: Payment process aborts when tapping on "Pay".
You should avoid the following things in the title:
Any kind of subordinate clauses, keep it short
No judgemental statements and do not use strengthening adjectives such as "very".
Mentioning individual devices or OS versions (this rather belongs in the description)
imprecise formulations such as "behaves incorrectly" or "faulty
Titles that are too long and detailed.
Set the type of ticket
For bug tickets, we distinguish between three types of tickets: bug, improvement and performance tickets.
Bugs are all functional errors, i.e. everything where the functionality is no longer given.
Performance and improvement tickets, on the other hand, have a non-functional character, i.e. something works, but simply not well or less well than it should.
Detailed description of the problem
You can divide this area into 3 steps:
You can go into more detail when describing the problem. Describe the bug as precisely as possible in complete sentences. You should pay attention to the following points:
- Use the W-questions to help you (Who, What, When...etc).
- Clarify the initial situation right at the beginning (problem XY occurs in area XY).
- Also mention special features (e.g. if the bug only occurs under certain circumstances/devices etc.).
Also describe here what you have tried to do to isolate the error, this can help the developers to rule out certain causes.)
Expected result
This is where you tell the developers what result you would have expected. This information can help the development team understand why we think the behaviour we noticed is a bug.
Reproduction of the error
So that the developers can check the bug again themselves, write down the steps that cause the bug. Number the steps and try to show each step individually. If the bug only occurs under certain conditions in testing, refer to it in the instructions
Account dates
If you had to create an account for the test, enter the data used at the time the bug occurred. However, make sure that you never disclose sensitive data. If you are unsure about this, it is best to talk to your test manager (if you have one) or your team beforehand. In the web test, you should also always include the URL.
Prioritise the bug
Prioritising the bug is one of the most important steps in creating a bug report. The priority level depends on how much impact the bug has on the customer experience and user satisfaction. How serious the problem is is usually defined by testers using their knowledge of the app under test.
We distinguish here between the following choices:
- Blocker (bug that prevents publication, e.g. login does not work)
- Critical (main functions do not work or only to a limited extent)
- Major (serious bugs that do not affect the general functionality and usability)
- Minor (rather minor errors that are not urgent because they do not restrict the main functions)
- Trivial (a rather superficial/minor error)
- Cosmetic (small display errors that the user does not notice at first glance)
OS versions
It is also important for the development team to know the software on the device on which the error occurs so that they can correct it accordingly. Therefore, always specify the OS version that the tested device currently has.
Devices
In order for the developers to be able to understand on which devices the bugs occur, we recommend always specifying at least 6 different devices on which the same bug occurs. Exchange this with your team or include more devices in the test in order to record as many devices as possible.
Reproducibility of the errors
Here you give an indication whether the errors can always be reproduced, whether they occur only once in a while or even only once.
Insert attachments
If possible, add at least one screenshot or screen recording to the bug report. This way, the bug can be visualised and better understood. You can then label these if necessary. You should also adapt the naming of the screenshot.
If the app crashes, you can attach a crash log.
With this help, you will hopefully be able to write a good bug report.
And with a little practice, it will certainly go by itself. So just use this article as a guide for your next bug report and you will certainly be able to write a very good report for the development team!
You are already a professional in writing bug reports and want to prove your skills? Then take a look at our career page! We are currently looking for app testers and test analysts.
