Breakdown traditional QA silos and empower developers to own quality checks.
Software development doesn’t come without its challenges, and bugs tend to somehow creep in just when you thought a given feature was ready. Upon discovery of a bug, a bug ticket is usually created to capture, what it was, and any relevant information that’s needed to help the person fixing it.
Bug tickets for a long time were generally created by the QA engineer, usually because it’s something they discovered during testing. But as software testing evolves and less emphasis being placed on the tester to create all the bug tickets, it highlights the fact that not all bug tickets are made equally.
I’ve go ahead and bullet pointed the content that’s to follow:
- Memorable titles
- Clear description
- Clear steps to reproduce
- Screenshots/Recordings
- Expected vs Actual
- Communicate the bug
The title of a bug ticket will always be the first thing that’s visible when viewing it on the product backlog, and while you don’t need to try and solve PI when thinking of one, it’s important to find the right balance. So consider the following before your next ticket:
- Is the title too complicated?
Being able to recall it in the heat of the moment without revision saves time. - Does it provide insight?
“Image wrong bug” is too vague, it tells me nothing, and can be mistaken for so many areas where an image exists. But if we take the following example “404 image is outdated”, the reader now understands what type of images are affected. They also have an idea of who to reach.
Balance it out, keep it short and sweet and to the point!
This is the space where you provide the insight and context that the reader needs. We all have a different style for describing issues, but you’ll want to keep it factual so consider the following:
- Leave out the noise & keep it factual.
2–4 sentences should be more than plenty to describe and include all the context required. Remove the fancy terminology and filling words and the part about a system that has nothing to do with the issue. - Don’t skip it.
Lack of information within the tickets means that you’ll be continuously messaged by others because they lack the context. - Are they dependent on you for more context?
“Reach out to me” isn’t a description, you’ve now made yourself a dependency in order to fix the bug. Write down the background and context the reader needs in order to continue without you.
It might feel like a waste of time adding one in, but not doing so creates a dependency on you. If you leave them with more questions about the issue, then you’re doing it wrong.
The aim here is to write a bunch of steps so that anyone without prior knowledge of the tool should be able to come in and reproduce the bug by following your numbered steps, one by one. I’ve listed a couple of points to keep in mind:
- Always assume the reader/developer has no prior knowledge.
- Use a numbered list.
- Repeat the steps after you’ve written them down.
If you’re confused, so will the reader/developer.
Screenshots or recordings are a great way to capture information and they can be helpful for UI bugs. Here’s a couple of tips to keep in mind:
- Highlight the area with a box and arrows to draw attention to the issue immediately.
- Trim the recordings if needed, only capture what’s needed.
If the expected behaviour is known, then you should include that information. Eliminating the room for interpretation of expected will help in getting the bug ticket over the finishing line, so keep a couple of the following points in mind:
- Bullet point the expected behaviour(s).
- Reference other tickets and existing information as needed.
- If the expected behaviour varies depending on some variable, reference that information.
If you don’t know the expected behaviour, try seeking it out and come back and fill in the blanks.
All these bug tickets are useless if you don’t inform the team about them. Even tho they it may not be fixed on the same day, you should remember to inform the team of any bugs you find.
Some of the following points above may seem obvious, but we often become lazy with the information and creation of tickets over time.
These shortcuts create bad habits, and we eventually end up with three-worded titles and the expectation for them to being fixed. The key takeaway here is that the reader needs to understand and resolve the bug without having to reach out to the creator due to a lack of information.
Subscribe if you like what you’ve read ? Leave a clap 👏 and stay tuned for more!
