Your Expected Result Needs a Source

The bug report was excellent. Environment stated. Numbered steps. Expected and actual, side by side. Two screenshots. A link to the live order so anyone could open it themselves.

It was also invalid, and not by a small margin.

Everything in it was accurate except the one line the whole document exists to justify: the Expected Result. That number had not come from acceptance criteria, or a design section, or a business decision. It had come from a field name.

The Part Everyone Skips

Look at how a bug template is structured. Steps to reproduce, expected, actual, evidence.

Three of those four are observations. You performed the steps, you saw the actual, you captured the evidence. Anyone can check them by repeating what you did.

Expected is different in kind. It is not observed. It is derived — from something you read, something you were told, or something you assumed. And the template asks you to state it in exactly the same tone as the three verifiable lines, in the same font, in the box directly above them.

So it arrives looking like a fact and it is a claim. Nothing in the standard format asks the one question that would separate the two: where did this come from?

When Nothing Is Authoritative, Something Still Wins

Here is the condition that makes this dangerous rather than merely untidy.

On that project a documentation finding had already been rejected with a sentence worth repeating: the design document is a reference, not the source of truth. Fine — but then the obvious follow-up was asked. Then what is?

Three weeks later, no answer.

That gap is not a vacuum. Testers do not stop deriving expected results while they wait for a governance decision. Work continues, and every scenario still needs a number to compare against.

So the question resolves itself, quietly and badly. When no artifact is authoritative, the most legible string in the system becomes the specification. Not by anybody's decision. By default, because it is the thing physically closest to the tester at the moment they need an answer.

In this case the most legible string was three letters long, sitting in a field name, saying percentage. The value it labelled was not a percentage. That is the entire root cause of a perfectly formatted bug report.

One Line in the Template

The fix is a single field, and it goes directly under Expected Result:

Source of expected result.

Free text, one line, mandatory. It must name an artifact and a location: a numbered acceptance criterion, a design section, a decision recorded in the wiki, a named person and the date they confirmed it in writing.

The value is not in the auditing. It is in the moment of filling it in. A tester who is about to type "the field is called max percent" reads that back before submitting, and a meaningful proportion of the time the bug never gets raised. The line does its work in the two seconds before the ticket exists, not in triage afterwards.

And where the source genuinely cannot be named, that is not a formatting failure. It is the finding. A scenario with no citable expected result means the specification is missing, and that is the ticket worth raising — against the documentation, not against the build.

What Counts As a Source, In Order

Not all citations are equal, and it helps to have the ranking written down before you need it.

• A signed acceptance criterion or a numbered design section. Cite it by number. If two of them disagree, you have a documentation defect and you should raise that instead of guessing which one wins.
• A business decision recorded in writing, with a name and a date. A decision made in a call and never written down is not a source; it is a memory, and memories diverge exactly when the money is involved.
• Observed behaviour of another environment or a previous release. Legitimate, but state it as such. It proves consistency, not correctness, and it will happily preserve a defect across three releases.
• A field name, a UI label, or a column header. Never a source. These are the most available strings in the system and the least governed, which is precisely the combination that makes them dangerous.

The Arithmetic Was Already There

The last part is the one I want to keep, because it changes what a tester does when the documentation is silent.

Ten discount ceilings were configured. Read as pounds, they produce floor prices of £25, £25, £25 and £29 — round numbers, obviously chosen by a human being who wanted specific price points to exist.

Read as percentages, the same ten values come out at 56%, 58%, 63% and 67% of list price. Nobody sets a discount policy at 63%. That is not a rule; it is noise.

One reading is a decision. The other is arithmetic with no author. Fifteen minutes with the configuration data settles a question that three weeks of waiting for a governance answer did not.

So when the source of an expected result is missing, do not fall back to the nearest string. Ask which interpretation produces numbers that somebody would have deliberately chosen — because a real business rule leaves fingerprints in the data, and a misreading almost never does.

The Short Version

A bug report that cannot cite where its Expected came from is an opinion with screenshots. The screenshots make it more persuasive, not more correct — and the better formatted it is, the further it travels before anybody checks the one line that was never observed at all.

Open the last bug you raised. Can you name, right now, the artifact your Expected Result came from?