If You Can't Name One Expected Result, It Isn't a Bug
A 40% discount calculated on the catalogue price instead of the promo price dropped a cart to £0. The bug was cancelled, and the reason was sitting in its own Expected Result field.
The Expected Result field contained the word "or".
That is the whole reason the defect was cancelled. Not the impact, which was real. Not the evidence, which was solid. One word, in one field.
The Defect Was Not the Problem
A product with a catalogue price of £57. A promotion popup showing the customer a price of £22. A 40% custom discount applied on top.
The discount was calculated against £57 rather than against the £22 the popup displays. Forty percent of the catalogue price is more than the promotional price the customer is actually on, so the discount swallowed the line whole and the cart dropped to £0.
That is a genuine finding. Money, a live journey, reproducible, and no sensible person would argue the £0 cart is intended.
It got cancelled anyway.
The Field That Sank It
The Expected Result on the report offered a fork. Either the discount should be calculated on the price being displayed, or the UI should be changed to display the catalogue price.
Read those again, because they are both defensible.
Option one says the customer sees £22, so £22 is the price and everything downstream should honour it. Option two says the pricing engine is right and the display is the thing that is wrong. Different fix, different owner, different amount of work, and a different answer to what the promotion actually means commercially.
The report contained both. Which means it contained no expected result at all.
Why Two Expected Results Is Zero
A defect report makes one claim: the system did X, and it should have done Y.
The evidence in the report supports that claim only in relation to a fixed Y. Change Y and the same observation supports a different conclusion — sometimes a conclusion where the code is fine and the design is wrong.
Hand a triager two candidate Ys and you have not given them a defect. You have given them a decision about how the product should behave — and that decision belongs to whoever owns the product.
So the ticket sits, and it eventually gets cancelled. That is not obstruction. Cancelled is the only accurate disposition for something that cannot be actioned in the form it was submitted, and everyone involved behaves reasonably on the way there.
The disposition is correct. The routing was wrong from the moment somebody chose the issue type.
The Ten-Second Test Before You Submit
Write the Expected Result as one sentence. If you cannot do it without "or", you are not looking at a bug.
No "or". No "alternatively". No "either the calculation or the display". One sentence, one behaviour, one system, and it has to be a sentence you could hand to a developer as an instruction.
There is one honest caveat, and it separates a real specification gap from a report you have not finished researching.
If any artefact decides the question — an acceptance criterion, a design document, a configuration value, a business rule, the behaviour of a sibling product built last quarter — then you do not have a fork. You have homework. Go and find the artefact and write the single expected result it dictates, because a bug backed by a document is very hard to argue with.
The fork is only genuine when you have looked and nothing in the specification answers it. At that point the gap is the finding, and the £0 cart is the evidence for it.
Raising It So It Survives
Same observation, different container. It goes to the product owner as a question, and the shape of the question decides whether it gets answered this week or drifts.
- Lead with the observable, never with the options. The cart falls to £0 in a live journey. That is a fact, it costs money, and it is what makes anyone read the next paragraph. The candidate fixes are your analysis, not your headline.
- Present exactly two options, with what each one changes. Which system moves, who owns it, what the customer sees afterwards. Two well-drawn options are a decision. Five vague ones are a workshop nobody schedules.
- Recommend one and say why. You have more context on this than anyone else in the thread — you are the only person who has watched it happen. A question with a recommendation attached gets a yes or a no. An open question gets a "let me think about it."
- Ask for a decision by a date, and name what happens without one. A specification gap with no owner and no deadline is indistinguishable from a resolved issue after about a fortnight.
- Keep the evidence attached. The moment the answer comes back, you raise the defect with one expected result, and it is now unarguable: the product owner said the discount calculates on the displayed price, and it does not.
That last step is the point of the whole exercise. The question does not replace the bug. It manufactures the missing precondition that lets the bug exist.
What a Cancelled Ticket Actually Costs
More than a fixed one that took a while.
A cancelled defect leaves a record, and the record says this was looked at and it came to nothing. That is what the next person finds when they search, six months from now, having just watched a cart fall to £0. The impact gets buried alongside the ticket.
The specification gap survives too, because nobody ever received it as a decision. It was never assigned, never scheduled, never refused — it was routed into a process designed for a different kind of object and quietly disposed of by that process working correctly.
And there is a signal here worth naming. Reporting the symptom is what everyone does. Noticing that your own Expected Result has a fork in it — and reading that fork as evidence that the specification never decided — is a different level of the job. The fork is not an inconvenience in your write-up. It is the finding.
Open the last three defects you raised. Does each Expected Result name exactly one behaviour — or did you leave the choosing to someone who was never going to choose?