A Verbal Agreement Has Participants, Not Readers

The defect was rejected. The defect was also correct.

Both of those were true, and the reason sits in a conversation that happened weeks earlier, between people who had no idea they were making a decision that would land on a tester.

What a Rejected Bug Actually Told Us

Development had delivered the requirement in a newer version. Testing had closed it against the older one.

The behaviour did not match the description, so a defect was raised. The defect was rejected, because the behaviour matched what had been agreed. Then the test cycle started again from the beginning.

Nobody in that sequence did anything careless. The tester read the requirement and tested what it said. The developer built what had been agreed. The agreement was made verbally, or in chat, and the description in Jira was never updated.

Two versions of the requirement existed. Only one of them was written down, and it was the stale one.

Why This Lands on Testing First

A test case is a derivative product. It is built from a description, and everything downstream of it inherits whatever that description contains — the test conditions, the data, the expected results, the run, the report.

When the source document is stale, none of that fails loudly. It all executes perfectly and produces confident, well-evidenced conclusions about a system that no longer exists.

That is why testing absorbs the cost of undocumented change first and most visibly. It is the function that consumes written requirements most literally. Everyone else in the chain has a mental model to fall back on; a test case has only what it was given.

And the cost is never one defect. It is the rejected ticket, plus the credibility hit that comes with raising it, plus the re-planning, plus the cycle you now have to run again.

The Mechanism, Stated Plainly

A verbal agreement has participants. It does not have readers.

Everyone in the room leaves with an updated model of the system. Everyone outside it keeps the old model — and, crucially, has no way of knowing their copy is stale. Nothing in the process emits a signal that says what you are reading has been superseded.

That asymmetry is the whole problem. It is not about discipline or professionalism. It is that information which exists only as memory can be retrieved only by asking someone, and you cannot ask about a change you do not know occurred.

The Same Failure, Two More Shapes

Once you recognise the pattern, it stops looking like an isolated incident.

Two people spent a week working on the same topic. Nobody had updated the statuses, so neither of them could see that the work was already in progress. The explanation, when it came, was that this had always been how things worked here — and the project manager did not enforce anything different.

A week of duplicated effort, and no individual mistake to point at anywhere in it.

The third shape is the one I have seen do the most sustained damage. The client reported defects in a spreadsheet. We tracked them in Jira. Neither side could say with confidence which status was current for any given bug.

Two parallel tracking systems with no defined synchronisation process is not redundancy. It is two truths, and truth does not survive being duplicated.

The Rule, and the Two Options

If it is not in the tracker, it does not exist. Not as a reprimand — as a description of how information reaches people who were not in the room.

For defect tracking specifically, there are exactly two workable arrangements. One system of record. Or two systems with a written synchronisation protocol: a named owner, a stated direction, a defined frequency.

There is no third option. "We keep both roughly in sync" is the failure, described optimistically.

What Actually Holds

Four habits, and only the last one works without anyone else's cooperation.

• Write the decision where the work is derived from. The description and the acceptance criteria drive the test cases, so a change agreed anywhere else has to land there. Whoever gains from the change is the person who writes it down.
• Treat the agreement as provisional until it is recorded. After a call, send the one-line version back to the ticket and let the other party correct it. It costs a minute and converts a memory into an artefact that can be cited later.
• Give every parallel tracker an owner and a direction. If a client will not leave their spreadsheet, define which system is authoritative and who copies which way. Do not negotiate the tool. Negotiate the direction of the copy.
• Re-read the requirement immediately before you execute, not when you wrote the case. This is the one defence available inside a broken process. Check the last-modified date on the description. If it changed after your case was written, you have found the discrepancy at the cheapest possible moment.

Why "We've Always Worked Like This" Wins

Because the saving is immediate, personal, and felt — and the cost is delayed, collective, and attributed to somebody else.

Not updating a status saves thirty seconds for the person who skips it. The cost arrives two weeks later as a duplicated week of work, and it lands on the project as a whole, which means it lands on nobody. Not updating a requirement description saves five minutes in a call. The cost arrives as a rejected defect and a repeated test cycle, and it is charged, in most people's memory of the incident, to testing.

That is the honest reason these habits do not spread on their own. The ledger is unbalanced, and it stays unbalanced until somebody with authority makes the record part of the definition of done rather than a courtesy.

Until then, the only thing you fully control is what you can prove you read, and when.

When a requirement in your project changes, what is the first artefact that changes with it — and would a tester on holiday that week ever find out?