One of the main tasks of the tester is to create bug tickets. We create new ones every day (or almost), and everyone has to read it. I therefore offer to answer this following question :
“How to create a good bug ticket ?”
The main characteristics of a good ticket are :
- Be specific in the reproduction steps : imagine that someone who doesn’t know anything about the system reads your ticket. This person should be able to reproduce the bug.
- Be specific in the expected result : what is implicit is a source of misunderstanding. To do this, write down clearly what the system should do.
To meet these needs, I always standardize the template of my bug tickets. It roughly looks like this :
- (Optional) Summary
- Procedure (step by step + current result)
- Expected result
- (Optional) Additional details
The title should be short (5-6 words maximum) but clear enough to understand the problem. For instance, we would prefer a “Title of graph FOO not aligned horizontally” to a “Bug on graph FOO ”. In the first case, we understand that it is a design problem (and therefore potentially, at low impact), while in the second case, we do not know whether the problem is critical or not.
The procedure is the essential point of the ticket. It will save the developer valuable time since he will know exactly how to reproduce the problem. For this, I recommand not to be stingy with details. Prefer a procedure like this:
- Click on the button settings
- Swipe on the right to reach the Profile tab
- Fill « Frédéric » in the field ’Name’
- Validate ==> find that the displayed name is « Fr_d_ric »
instead of that kind of procedure :
- If I change the username to « Frédéric », it is not well displayed
From experience, these few minutes lost in writing the ticket will be hours saved. In the above case, after reading the procedure, the developer can already understand that the problem comes from the accents. He may not even need to reproduce the problem himself, and he will know very easily where to go to fix the issue in his codebase. Do not hesitate to include screenshots (or records) of the problem: there will be not doubt for the developer to understand what you saw, and it also saves time when presenting the ticket in a meeting (backlog refinement, etc …).
I say it again, but what is implicit is source of misunderstanding. Write down what is the expected result, even if it is obvious in 90% of cases. Experience shows that the solution you imagined is not always the one implemented by the developer.
A ticket cannot be complete without an associated configuration. Always indicate which phone you have used, its OS, which web browser, which version of your application … This information may be useless for the developer in many situations. But if you have not indicated it, and you need it, you will curse yourself when you have to repeat the procedure on 5 different devices to find the culprit …
Finally, a ticket has a priority field. Each company uses its own way (mandatory / major / minor, high / medium / low, 1/2/3, etc.). Adapt yourself to the company practices to be consistent with other tickets.
In some cases, you can add a description at the beginning of the ticket. This can be useful to give context, to explain a title or a procedure that is not clear enough, etc. In the same way, I sometimes add a step “Additional details” when I want to raise a point that does not fit anywhere else ( the problem occurs only on specific graphics, doing the same procedure with replacing such step by another one gives such result, etc…).