We write good bug reports. Recommendations
Imagine – you are a developer, and a tester brings a bug that was found during a regression. I would like to fix this bug and you ask me to open a ticket. You can already imagine how you will hire him, link pull requests to him and set estimates so that the product manager does not have questions.
After a while, a new ticket appears, but inside there are only a couple of lines and a screenshot. Sighing, you try to reproduce the bug using this data, but there is no error. You try several times, but in the end you write to the tester that the bug cannot be reproduced and a new cycle of clarification begins. Waste time that you could spend on solving new problems, fixing other bugs, watching anime, refactoring.
My name is Evgeniy Domnin, I am a QA and I will try to share my vision of what makes a good bug report. Sorry for the long introduction, let's get started.
Heading
Try to answer three questions in the ticket title
Where does it happen?
What's happening?
Under what conditions?
An experienced developer will only need to look at the title to understand what's going on. For example,
Login Page: Field not highlighted when entering incorrect password
Environment
I came across the fact that in the ticket testers often forget to specify in what environment this happened. This is especially true in UI-related tickets, where the website address or request is not visible. Always indicate this. If there is a separate field in the ticket, super, indicate there, if not, write in the playback steps, for example,
Login to the stage using an admin account
Speaking of steps
Reproduction steps
One of the main sections, instructions for reproducing the bug. I will highlight two subsections that we will pay attention to. This is the design of the steps (visual) and the content (data inside)
Visual part
Maintain structure
There are different variations of a bug report, but classically it should contain the following subsections:
Steps
Expected result
Actual result
Use this structure and stick to it always. then this is exactly the case when uniformity will help structure your thoughts when describing
Use a numbered list
Separate steps using a numbered list. Sometimes testers write in detail, but in one continuous text. Don't be like that. It will be much easier for everyone to read with division.
If possible, write without grammatical errors.
Now on to filling in these steps.
Common sense when describing
You shouldn't break down each movement into a separate point unless it is key to reproducing the bug – this is quite difficult to read and use in work. Don’t be afraid to add several actions at once to one item. What do I mean?
Badly:
Go to
test.com/loginClick in the login field
Enter login
Click in the password field
Enter password
Fine:
Go to
test.com/loginand log in with any account
We do not break down the points and steps into what the developer would already do, going through the standard flow. When I started, I got stuck a little on this point; it seemed to me that every movement should be under the point. You shouldn't do this.
Avoid ambiguity
Always supplement the steps with a request that needs to be looked at at a specific step, write a specific button that needs to be clicked (if it has the same name)
Add test data
Write your login information, if there is an error in your account, do not be lazy to add a test payload, which helps reproduce the error
Go through the created steps again
It happens that you indicate steps immediately after the bug appears, but it may turn out that some step is missing for complete understanding or the bug will not be reproduced again and you will need to look for more precise steps
Expected result
The expected result is a separate block, where we describe (unexpectedly) the result that is expected when reproducing the steps. There are no special recommendations here except that this block should exist – it is important for the developer to understand what behavior the functionality should lead to. Formulations like “everything should be normal” are not suitable, write specific behavior
Actual result
Here we write what actually happened when we went through the steps. Specificity is also important here. You shouldn’t write that everything was broken (although it probably was). It’s worth describing what indicators indicate that everything is broken. For example,
500 error returned on request GET /accounts and the UI is blocked. The user cannot exit the page or click on elements. Refreshing the page results in a repeated request and an error.
That is, we describe the real effect and its impact on the user’s flow
Additional files
A separate section that is worth mentioning. The section where you attach additional information that describes the bug. I know some developers who are not fans of reading the reproduction steps, but immediately look at the actual result and additional materials that reveal it.
Screenshots of the error
It's better to see once than to hear a hundred times. A great way to clearly show what exactly is happening and where. Always try to attach a screenshot
Request
If there is a request in which an error occurred, it is always worth including it in the ticket. However, there are many different parameters in the request. I highlight the following important points to note:
Error URL
Actually, the request itself can be taken from the Network section in the browser that is being tested
Method
GET, POST, TRACE, OPTION and so on – there are a lot of methods, as well as requests with the same URL, but different methods. Don't forget to indicate it in the ticket
Error code
Also an important point. Most likely you are not missing it, but do not forget to note what code was returned from the server
Payload
This is the request payload, that is, the data that we sent in our request to the server. Not every request has this (for example, HEAD or GET do not have them), but there may be reasons for the error
Response
Response from the server. In some cases, the entire error ends up there, where it even says where the error occurred, and sometimes only the default stub that is configured on the backend for this type of error. Be sure to indicate – save a lot of developer time.
Logs from the console
Sometimes there are errors that are in the console and can be added to the ticket. You may have done this before me, I’ll just note that a large block of text can always be saved to a file like .log and add to the ticket. Improves the readability of the logs and tickets themselves.
This is all good, but…
This is all good, but where do we have so much time to design it all beautifully? Deadlines are running out, the manager is swearing, there’s a blocker on the production, and I’m being asked to sit and write everything down? I’ll just write a PM to the developer and that’s it.
This is a logical argument that might arise. In fact, I have no illusions about the ideal world of a tester, where there is plenty of time for testing, everything goes according to processes and detailed and high-quality documentation is maintained. I understand everything, often this is a period of time pressure, burning…ahem, eyes and attempts to get everything done.
Small errors tend to accumulate, take more time to switch contexts, and also lead to poor practices. If we start introducing improvements gradually and see how they work, we can arrive at a process that is more stable, standardized, and predictable for participants. The project will understand what is happening with the product without dragging everyone around, and after seeing a high-quality report, the developer will not have to clarify the conditions for reproduction with the tester and will not distract him from testing, and stakeholders will, in turn, understand how the product is moving.
This article is more aimed at beginners who are about to or have already started their journey in testing. I believe that small steps lead to big results, and the recommendations from this article lead to better bug reports.
If you have questions, suggestions, disagreements, indignations – write in the comments, it’s interesting to hear your opinion!
