Rate/Prioritise bug tickets
Ministry of Testing
Case Study:
Sometimes, people in my team create bug tickets and ask me to rate them. Those might be things like “button x is not fully visible on platform y with resolution z”. What would you do with things like this? The issue is pretty clear and our PO can change the priority as they want, so I’m not sure what’s left for me to do there. Is it my responsibility to look up the usage percentage of platform y and then rate the importance of this issue?
We do have usage data and the PO has access to it. The PO already asked me to prioritise bugs because I have better insight, I guess I should get access to this data then. How would I really interpret this though? I can’t say how much of an impact that has, especially if it’s not broken but it just doesn’t look nice. I’m also having issues with things like SEO issues, missing tracking stuff here and there. The SEO people of course see this as very important but it doesn’t have any direct impact for the customer, so it’s not so important I guess?
So right now we usually do something like this:
people (including me) create bug tickets
I have a weekly meeting with the PO to look at new bugs and give some insights and let them prioritise the tickets
What sometimes happens now is that people who create bugs come to me and say “hey, I found this thing, can you check it and see if it’s valid” or “hey, I created a ticket, can you rate it”. Usually I can say something like “okay, it’s described in a ticket already and it’s not critical, we’ll check it out in the next bug review meeting”. Now our PO also told me to just move stuff to the top of the queue if I see that it’s critical as they’re new in the project and don’t have that much of an overview yet. I’m trying to figure out where my responsibility stops and goes to the PO. In previous projects, I created tickets for issues and that was it, then it was up to the PO. Maybe give them a hint if I think it’s critical but no further prioritising. Any thoughts on where to stop? I don’t want it to look like I’m pushing work to people who are usually not responsible for things. I’m also a bit confused about this “can you check if it’s valid?” part. Those people already created tickets but it seems like they expect the “QA person” to see if that’s a real issue or to do some more investigation.
-- Anonymous
Recommendation 1:
If you can tie it back to how it impacts the customer and how that impacts the business, that ought to help the PO prioritise against all the other possible work. (Assuming everything else is described in the same way). It would be easier if the application is giving you usage data because then you might be able to say things like “because the button is not displayed at resolution x our sales numbers on device y have fallen by z%“.
Maybe with the SEO problems, you have a chance to get closer to their world. What impact does missing SEO tags have for the business? (e.g. An impact for the customer might be… SEO tags are missing > search engine cannot categorise and present relevant content to a potential customer > customer therefore doesn’t know you have a product/service that is of interest to them > missed sales opportunity > which could mean reduced revenue for the business).
-- Vernon Richards
Recommendation 2:
It sounds like there are a bunch of threads you can pull on there!
Rating bugs - It feels like you have a process to determine if something is a valid bug or not. If you can codify that thought process and share it, maybe you could get other folks to do that? I say that because while you’re investigating the behaviour they have already noted, you aren’t doing something else that could be more valuable.
The PO - This sounds similar to the situation above to me. It seems like you could help onboard/coach the new PO by sharing how you make that assessment. What are the factors that make issue 1 more important than issue 2?
Responsibility - It depends (on the team and how they make software) but I’m guessing you are probably the testing expert on the team. So first and foremost master that, figure out how to do the best testing possible on the product. Then once you have a handle on what that testing looks like, then you can think about how to spread that testing out across the whole development lifecycle (if you haven’t already). If testing is a search for quality related info, where else and how else can you find that information? What else impacts the quality?The key is to then frame those things in terms that your PO cares about.
-- Vernon Richards
Recommendation 3:
I have experience where I basically became "right hand" of the PO, even when the PO changed the role continued. Even though my colleague and I were giving base "rating" on how bad the bug is such as blocker or what not, eventually PO asked allways to go through backlog before sprint planning and highlight if there was something that I saw as important, problematic or high risk if not addressed to. I did not ever see that as "doing POs job", instead I provided useful information and also yes, actively recommended things to prioritise higher and not passively provide "data".
PO did eventual pull or remove from sprint with the team that I was part of but this was maybe yes unconventional role for "just a tester" but it was something that was great opportunity to become trusted and valued "partner" to PO.
And this from original poster caught my eye especially "I’m also a bit confused about this “can you check if it’s valid?” part. Those people already created tickets but it seems like they expect the “QA person” to see if that’s a real issue or to do some more investigation. (edited)".For that I would say for sure "why on earth that would be my job. Do you have steps to reproduce it? If not, is there other factors that make it valid issue to explore and look into further? There is no need for me to "validate" it. But I would be glad to sit down with you and go through it and see how it is so that next time you can validate it yourself".
-- Misma Silfver
Recommendation 4:
why not just catch up a chat with your PO and figure out about the responsibilies in that conversation. Maybe togehter with you line manager if it makes you feel more comfortable. Regarding the "could you please check if it is valid?" I encounter this also in my workplace. So when someone is not sure, if this is a valid bug or something else. I just sit down with them/have call or whatever and ask them to explaing to me, what they observed. Rather then pick up the tickets and try to figure out what it shall tell me. Surprisingly, the majority is happy to share with me. Sometimes it is a bug sometimes not, but mostly it is good time spent with collaboration, learning and bonding.
-- Andrea Jenson
Final output from Case Study:
For starters we'll add one of the SEO people to our bug review meeting (when it makes sense) so we get some better insights on these topics. As for the other topics, I'm talking with the PO and my team lead on how to improve things a bit.I think most of my issues come from the issue that I don't have a lot of time do deal with all those things. We're already too many devs and I'm just a single tester, this causes a high work load from new features which are getting thrown at me. Which brings me to the next topic, how to optimize the development flow in a Scrum team.
Reference:
Last updated