In testing, deciding which bug to tackle first can sometimes feel overwhelming, especially when time is limited and the team is juggling multiple priorities. This activity helps you think through the factors influencing whether a bug should be fixed now or later. There’s no right or wrong answer; it’s more about building confidence in prioritisation and potentially helping others by sharing your approach and decision-making process.
The task
You’re part of a team working on a booking system for a national train service.
You have found a bug:
“When a user switches between two stations on the booking page, the return date field resets unexpectedly. It doesn’t break the booking process, but it causes frustration because users have to keep re-entering their return date.”
Your product owner is pushing to release a new journey-tracking feature this sprint. The team can only fix one or two bugs before the release.
Step 1: Identify the factors that could influence this decision
You could consider these factors before making a decision:
How users might experience the issue
What the team is focused on this sprint
Who you could speak to before logging it
What else might be influencing decisions in your team
Step 2: Assess the bug’s impact
Based on the factors above, how would you assess the impact of this bug? You might consider:
How might this affect different types of users?
Could it lead people to abandon the booking?
Does it affect a core journey or a minor interaction?
Whether there’s a simple workaround
You don’t need to be exact; focus on how you’d think it through.
Step 3: Make and communicate your recommendation
Would you prioritise fixing this bug now or later? Write a brief message to your team explaining your decision, including any key factors you considered.
Consider how you might communicate its importance to your team. Maybe you could use one of these approaches:
Describe the issue from the user’s perspective
Share a visual or example to clarify the impact
Ask a developer for input before finalising your decision
I’m interested to hear how you’d approach this scenario!
Hi @maddykilmurray,
I’m fairly new to software testing so correct me if I am wrong, but I think that if this booking system is going to be used frequently by users and this is something that is reproduceable all the time or at least 50% of the time i.e. “switching between two stations on the booking page, returns the date field resets unexpectedly.” I think that we could classify the bug as a medium/high bug.
Since it is most likely to happen and although the users can re-enter their date, we are also leaving room for human error. i.e. they could input the date wrongly, and cause frustration in the users in the long run.
This is a good one, as some bugs may present initially as a small thing, but has the potential to snowball quickly!
Thoughts:
The user experience for the customer, potential loss of business for the company if customers move to another platform - impact to the company esp if there are other options out there
Buddy test with another team member to compare results/ reproduce on other devices/operating systems
Demo the bug on a call with a developer and/or the Product Owner to demonstrate the frustration the customer could encounter/ video the experience to add on Jira ticket
I would push this to be fixed sooner rather than later, as it impacts the user base broadly, and there’s a financial element to it - risk of the booking not being followed through to payment - financial impact to the business.
I like this, it just made me think a bit this morning! Here are my thoughts:
The main factors I would consider would be:
How frequently the user encounters this issue and how it affects their booking experience (Data team would help to give drop-off rates during date selection & if there is more business observability available, that would help too)
Emphasise the business metrics, potential impact on booking completion rates and customer satisfaction
Leveraging real user monitoring or similar capabilities to review heat map that may show an increase in users clicking the date field (suggesting re-entry)
Collecting inputs from the Customer support team(increase support tickets or not), UX team(friction in the booking funnel → leading to frustration)
For the narrative, I would consider something like this to have the buy-in:
Since booking flow is one of our core business drivers, and as we are shipping the journey tracking to enhance the booking experience in general, fixing this complements our investment in time, as for the user, we are removing a friction point and also delivering value. And the issue in general seems less complex, could be just a state management issue where we need to preserve date on station change.