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.
First of all, an issue like this definitely needs to be logged. I’ve previously written a blog post on the value of bug reports ( Value of a bug report – Quality Ramblings ). The only circumstances that I won’t report it is if the applicable story is still open and we can track it through that, or if it is agreed that it is not a bug. Although I do recall once agreeing to disagree so I entered the bug anyway and the dev manager just closed it. When a poorly written escalation came through, we had a record of the bug, steps and logs.
Anyway, I digress.
A valuable question is is whether this is a regression. If the behaviour isn’t new then I would fully expect it to be lower on the backlog than the high priority feature described in the scenario. If it is a regression then I’d be putting more emphasis on a fix. How quick and easy is it to perform the workaround of re-adding the return date? I’d assume not very given it sounds like we’re viewing the same form.
Right now I’d be making a case to fix it because it is annoying, but it is by no means a critical issue. The next question is the complexity of the fix. If this is a straightforward fix, which I suspect it would be, then I would definitely be advocating for a fix. If it wasn’t, I’d be advocating for waiting on whether customers complain. What would help would be any analytics that shows how many times users change/set the station per booking.
Finally when advocating to fix the issue I would use the story approach and emotive experience for the user. I’ve been there where I’m trying to arrange travel plans on the phone and the train app is being a bit of a pain. This is definitely the sort of behaviour that would leave a stressed out user wanting to replace this stupid f------ app.
(and yes I would use the f-bomb when verbally communicating as I’ve been around stressed Scottish travellers having difficulty with a train app and can 100% confirm that this would be customer behaviour!)