Bug or omission in the spec: triaging disputed defects
A tester files a bug: a repeat payment extends the subscription from the payment date rather than from the end date. The developer replies that the spec says nothing about it. Both are right, and the ticket spends a week bouncing between them.
A disputed defect is a divergence about which nobody can say whether it violates a requirement. The tester and the developer argue over it, but the subject of the argument is not the code, it is the spec. Which is why it should be triaged by whoever is responsible for the spec.
Russian speech calls all of this «баг», and that is half the problem. English practice separates an error in code from a defect — a divergence from a requirement. While there is only one word, the ticket goes to development by default, and nobody asks what was actually written.
The first question of triage: what is written
Before any discussion, open the spec and find the line the behaviour violates. The result comes in only one of two forms: a quotation, or the phrase “the spec does not describe this”.
It seems obvious, but most arguments skip this step: each side paraphrases the spec from memory, and the paraphrases disagree. As soon as the line is found, or its absence is established, the argument usually ends by itself.
A rule for the defect text. A disputed defect must carry a link to a requirement or an explicit note that there is no requirement. A defect without that line is not triaged but sent back to its author. This is not bureaucracy: without it there is nothing to compare against.
Four kinds of divergence
Once the first question is answered, the divergence falls into one of four kinds. The kind determines who deals with it next.
| What the spec says | What it is | Who decides |
|---|---|---|
| Clearly says one thing, the system does another | Implementation error | Development, with a link to the requirement |
| Says nothing | Omission | The analyst together with the product owner |
| Says two different things in two places | Contradiction | The analyst: name the authoritative source and remove the other |
| Clearly says what was built | Expectation, not a defect | The product owner: a new task or a refusal |
A contradiction is the direct result of a requirement living in two places; that break is described in the piece on traceability. An expectation is a change of requirement that arrived through the bug tracker; it is handled like any other mid-flight change.
Omission: whose is it
The most common kind and the most awkward. The spec is silent, so everyone is right in their own way: the developer built one sensible option, the tester expected a different sensible option.
Omissions almost always live at boundaries: repetition, zero, an empty value, simultaneity, an action after expiry. These are edge cases nobody went through when the spec was written. The subscription example misses one: what to do if the user pays while the current period has not yet ended.
Choosing between “extend from the payment date” and “extend from the end date” is not a technical choice. It is a business rule: it decides how many days the user gets for their money. It is not the tester’s decision, nor the developer’s.
A developer who picked an option on their own did not make a mistake. They made a decision that belonged to someone else. Even if it is a good decision, until it is written down it is an assumption, not a requirement. A month later the next task overwrites it, and nobody notices.
How to close a disputed defect
Triage ends not with a code fix but with a record. One record per defect:
BUG-417 repeat payment extends from the payment date
kind omission
spec REQ-114: repeat payment not described
decision extend from the end of the current period
decided product owner, 2026-09-22
changed REQ-114 rev. 3, acceptance criterion added
next TASK-2103
test_REQ_114_renewal_extends_from_period_endThe key line here is “changed”. An omission closed without an edit to the spec comes back: the next developer reads the same silence and picks an option again, possibly a different one.
Arguments that settle nothing
Some points come up in every dispute and never once resolve it.
- “It has always worked this way.” If it used to work differently, that is a regression, and there is nothing to argue about. If it always worked this way and was never described, it is an omission that simply bothered nobody for a long time.
- “That’s how the other system does it” or “that’s how competitors do it”. That is an expectation. It may well be right, but it becomes a requirement only after a decision and a record.
- High priority as an argument. Severity speaks to consequences, not to who is right. A critical omission is still an omission: it too is decided first and fixed second.
A disputed defect is a question to the spec, asked too late.
What the count shows
If every triaged defect gets its kind recorded, within a month you have a figure you cannot get any other way: the share of omissions. It says nothing about testing and a great deal about the specs being taken into work.
When omissions are many, the thing to fix is not testing but the entry point: spec readiness. The list of edge cases that keep recurring for you is a ready-made item for the Definition of Ready.
A fifteen-minute check
Take the last ten closed defects and sort them into the four kinds. Separately, count the omissions closed without an edit to the spec. Each of them is a defect that will come back.
What next
The defects are triaged, the spec is corrected, the code is fixed. Next comes the release, and the last check happens not on a test environment but on real users: what to watch in the first day after the deploy.