What Is (and Isn't) a Bug

"That's not a bug, it's a feature" is a joke because the line is genuinely blurry — and a QA engineer stands on that line professionally. A bug is not "something I don't like." It's a gap between what the software does and what it should do — which means every bug claim quietly contains a claim about the "should." Getting the should right, and routing the things that aren't bugs to where they belong, is what makes a tester's reports trusted instead of argued with.

The tailor one more time, because the dispute is instructive. A suit that doesn't match the order form is a defect — the workshop erred. A suit that matches the form perfectly but doesn't fit the customer is a requirements problem — the form was wrong. Either way the customer can't wear it; but the fix starts in completely different places, and confusing them wastes everyone's week.

Expected vs Actual — and Where "Should" Comes From

The definition is the comparison you've run all book: observed behavior versus required behavior. The subtlety is the hierarchy behind "required." First, explicit requirements — the story, the acceptance criteria, the spec; when they speak, they rule. When they're silent, reasonable expectations take over: how the rest of the product behaves (consistency is a requirement nobody writes), how similar products behave, what a sensible traveler would assume, platform conventions (the back button should not double-charge anyone). This hierarchy is what lets you file a bug against behavior no document forbids — "the error message vanishes after one second, too fast to read" violates no written line and is still a defect by any reasonable expectation.

Error, Defect, Failure: the Chain

ISTQB gives the anatomy three precise words, and interviews love them. A person makes an error — a mistake in thinking: Omar misreads the time-zone handling. The error plants a defect in the code — the flawed line itself, sitting there whether anyone ever runs it. And when the defect executes under the wrong conditions, it produces a failure — the visible wrong behavior: the shifted check-out date a traveler actually sees. The chain explains two everyday mysteries. Why can a defect hide for years? Because failures need conditions — FW-312's defect was harmless until a traveler in the right time zone booked. And what do you actually observe as a tester? Failures. You see failures, you report the evidence, and the developer hunts the defect behind it. (In casual speech, "bug" covers the defect and the failure both — fine everywhere except the exam.)

ErrorOmar misreads the time-zone rule

→

Defectthe flawed conversion, dormant in code

→

FailureFW-312: the date a traveler sees is wrong

"Works as Designed" — When the Spec Itself Is Wrong

Now the tailor's second suit. Sometimes the software perfectly matches a requirement that is itself wrong — the developers built exactly what the form said, and the form said something users hate. The dismissive phrase is "works as designed," and a beginner hears it as case closed. A professional hears it as rerouted, not closed: the product still has a problem; it's just a requirements defect, not a code defect, and it goes to Petra as a story question rather than to Omar as a bug. The phrasing matters enormously — "the spec says X, users clearly expect Y; should the spec change?" opens a conversation; "your requirement is wrong" starts a war. Same content, different week.

The Suggestion Boundary

Last routing lane. "This button would work better in blue," "the filters could remember my last search" — real observations, possibly valuable, and not defects: no expectation, written or reasonable, is violated. These are suggestions — improvement ideas — and they go to the product backlog as feedback, not to the tracker as bugs. Filing suggestions as bugs is a classic junior credibility leak: it forces someone to triage-and-reject them, trains the team to skim your reports, and buries your real defects in noise. The professional habit: notice everything, route ruthlessly.

One Afternoon, Three Verdicts

Here's the skill assembled, on one realistic afternoon at Fernway. Observation one: the cancellation fee rounds down, in the traveler's favor — you check the spec: it says round down. Matches spec, matches reasonable expectation (nobody complains about paying less): not a bug; you note it and move on. Observation two: the date picker shifts the check-out date for certain time zones — violates the story and every reasonable expectation: defect; it becomes FW-312, next topic shows the write-up. Observation three: "search feels slow" — no requirement says how fast (remember Chapter 3): a missing-requirement problem; it goes to refinement as the question that produced the 2-second criterion. Three observations, three different routes — and zero arguments, because each landed where its kind of problem gets fixed.