Good question. If we do have multiple bugsâŚit depends how bad it is as to what the most efficient next step is. Worst case the most efficient next step could be âstop testing and get people on a callâ. Especially if we feel weâre finding bugs that should have been captured earlier and question stability.
Prioritising multiple bugs is more about interactions and we find that priority is a natural conversation in our engineering teams.
So from the testing I did Friday I have a couple of examples of those that I could categorise:
The easy no brainer - Definite non-compliance to the story and easy fix
The big deal usability - UI presents a scenario that will be confusing to the user and is a big deal to fix
So âthe easy no brainerâ devs pick it up and just get on with it.
âThe big deal usabilityâ our instant reaction is to yell âProduct!â. Do we fix this as its a design flaw? Do we just tell the user about the scenario that can leave the UI in this state as it going to affect deployment timescales?
One of the things about our workflow that forces us to have these discussions os we created a sub-task called âstory bugâ. You canât close the story until all bugs have been addressed. You can either address them by fixing them, agreeing not to fix them or converting them to a standard bug and moving them to the backlog. We canât do that just from setting the priority in Jira, to come to those decisions we need to talk about it. Sometimes it can be done in a slack thread or if there is conflict weâll get on a call to make our cases.
No response. I used to create too many bug reports, and no other person would have time to even check them.
That depends on what effective means?
If I want to advocate for fixes, or support others in dealing with it, I talk to them about the most important issues(then the bug-report ticket might not be written, or might be very brief). And then I wonât waste time with bugs that will never be fixed.
Thanks for this-I like how you are not treating bug report as just âdocumenting whatâs brokenâ, but as a communication bridge-bringing in context, technical depth and even offering fixed when it makes sense. That kind of ownership really elevates the role of a tester.
Really appreciate how you broke this down especially the way you have tied the prioritization to actual conversations, thatâs so real.
I like the âeasy no brainerâ vs âbig deal usabilityâ distinction it mirrors what I
have experienced too, where not everything is about severity but more about impact and timing,
Sometimes the âfix it nowâ bugs arenât real ones crashing things, but the ones that just canât ship as-is without causing confusion to the user.
Also love the use of a âstory bugâ sub-task to keep accountability tied directly to the story. Thatâs such a smart way to ensure nothing slips through the cracks while still giving space to discuss trade-offs with the team.
And yeah-sometimes the most productive move is to stop and talk it out, saves hours of back and forth later. Thanks for sharing.
I think a lot of us have been there, especially early on, when we are reporting every little thing thinking we are helping, but it ends up overwhelming the system.
Sometimes the most valuable thing is not a detailed ticked-itâs a conversation or a heads-up about something that might become a blocker down the line. Itâs easy to fall into the trap of thinking a bug report has to be written to be valid, but often the real impact happens through interactions, not just documentation.