DEV Community

BugIt
BugIt

Posted on Originally published at bugit.hashnode.dev

Is it a bug, or is it the spec? Settle it before you file

#qa #testing #softwaredevelopment #bugs

Some of the longest ticket threads in any tracker are not about code at all. They are about whether the behaviour is wrong in the first place:

"This is working as designed."
"The design is wrong, then."
"That is a feature request, not a bug."

A tester who checks the requirement before filing saves that whole exchange. Here is a quick way to do it, and what to write when the answer is unclear.

Three possible answers

When something surprises you, it falls into one of three cases:

  1. The product contradicts the spec. That is a bug. Link the requirement in the ticket.
  2. The product follows the spec, and the spec is wrong or missing a case. That is a spec problem. File it, but say so, and route it to whoever owns the requirement, not only to a developer.
  3. There is no spec for this. That is a question. File it as one, and say what you expected and why.

All three are worth reporting. They just need different wording and often different owners.

Where to look

Specs live in more places than anyone admits:

  • The ticket or story the feature was built from, including its acceptance criteria.
  • The team wiki: Confluence, Notion or similar.
  • The repository itself: a docs/ folder, a design note, an ADR, a README section.
  • The design file for anything visual.

Search for the feature's name and for the field or screen involved. If you find two sources that disagree, that is itself worth reporting.

How to cite it

Quote the line, not just the link:

Expected: "Annual plans apply the coupon discount to the yearly price" (Billing spec, section 4.2, link).
Actual: the coupon shows as applied, but the total is the full yearly price.

Now the expected result is a requirement, not an opinion, and the "working as designed" thread does not start. If the spec turns out to be wrong, the quote shows exactly which sentence needs changing.

When the spec is silent

Say so explicitly: "No spec found for coupon behaviour on annual plans; checked the billing spec and the plan change story." Then state what you expected and why ("monthly plans apply it, so I expected annual to as well"). That turns a vague complaint into a decision someone can make in one reply.

How BugIt helps with this

BugIt is a QA agent that runs inside the AI assistant you already use: GitHub Copilot Chat or Claude in VS Code, or a plain terminal. BugIt checks the spec before it calls something a bug. It reads your spec in Confluence or in Markdown files in your repository, and Notion is experimental.

You read the draft and decide how to file it, and nothing is filed until you type FILE IT.

The 30 second film:

BugIt checks the spec before it calls something a bug

Try BugIt

Top comments (0)