From bug to bug fix: QA tips
If something in our software isn’t working or looking quite as it should, we want to fix it. The tricky part is knowing exactly what needs fixing and when. Here are some problems that the QAs at Bulb ran into in our quest to make bug fixing a smooth process. We found solutions that make sense for us but we’re still working on making bug management better.
Bugs got stuck along the way
We found that bugs tended to spend too much time in the same part of a workflow. They would be reported but not looked at straight away because they didn’t seem urgent. Or we confirmed they were issues we want to fix but lost sight of them as other more important tasks came up.
Solution: QAs are involved in the whole journey of a bug
In some companies the QA role is isolated and limited to pointing out issues. At Bulb we’re very much an integral part of the product team and interact with everyone across the company. We started leveraging this collaboration to get bugs through the pipeline more efficiently, becoming sort of bug managers. This doesn’t mean things won’t move without our involvement, but we’re there to give the ticket a nudge when needed.
Some of our contributions:
Support on whether an issue needs reporting
We have guidelines for our Energy Specialists on when and how to report bugs. However not all scenarios fit the mould so we’re always available to advise on what to do with a potential issue.
Triaging the reported issues
As testers, we go through all bug tickets to confirm they’re reproducible and add any extra info. We then move them to the relevant JIRA board — each product pod has their own.
Advertising the bugs
We bring a list of bugs in order of priority to refinement sessions where we discuss them with the team.
Bugs were being prioritised ad-hoc
When a JIRA ticket is created, its priority is set by default to ‘Medium’. This wasn’t working to our advantage, as we ended up leaving most of them with this initial value. Tickets that were deemed urgent to fix would be picked up immediately anyway, so we ended up with a backlog full of moderate bugs not knowing where each stands compared to the others.
Solution: we use a priority matrix
Our issue tracking software was already giving general descriptions for the priority values but we needed something specific to our product. The vagueness led to lax prioritisation. We used a model and applied it to our needs. This task made us consider and put down in writing what really matters to our members when they self-serve (the core functionalities).
Backlog was too overwhelming
Any new plan we had for managing incoming bugs (like prioritising them based on our matrix) was daunting because of the high number of tickets we already had. They formed a big scary black box.
Solution: we made a clean slate our first goal
This doesn’t have to mean fixing all existing bugs, but forming an approach for the issues that are already piled up. It might mean setting time aside to do some spring cleaning on old tickets. It might mean completely scrapping the existing backlog before adopting a zero-bug policy.
For us in the Member Pod, it meant setting the priority for our existing 50 bug tickets by our new method. We split the tickets among everyone in the pod — product manager, engineers, designer, user researcher, QA — and took them through our matrix. It was a great team exercise and proved the concept, leaving each of us feeling like a key player in the quality of our software. After that point, we made sure to take every new ticket through the process.
We’re still facing some hurdles when it comes to turning bugs into fixes. We learned to make the most of the tools that are already available to us and customise them to suit our needs. We also reinforced our belief that collaboration is one of the most powerful tools we have, so we’re counting on it for future improvements.
If you’re interested in green energy and building quality products, we’re hiring. Come work with us! bulb.co.uk/careers
