The Cheapest Bugs Are Still in the Requirements

There is a requirement called "Case Access".

There are more than a dozen of them. Nobody in the room can say which one is being discussed, and the meeting has to settle that before it can start.

A Name Is an Identifier or It Is Nothing

That is not a documentation nitpick. A requirement's name is the handle every other artefact grabs it by — the story link, the test case title, the defect summary, the thing somebody types into search six months later.

An identifier that does not identify pushes a small cost onto every one of those, forever.

And the name is usually the first visible symptom of a deeper habit. In that project, requirements were written without a name that carried content, without the user action, without acceptance criteria, and without separated declarative and development notes. The reason given was that this is how it had always been done.

Each of those elements has a job, and a requirement missing them is a wish rather than a specification.

• Put the content in the name. Not the object, not the area — what changes and for whom. A tester should be able to tell two requirements apart without opening either.
• State the user action. Who does what, in which interface. Without an actor and an action there is no scenario to write, so the tester invents one, and their invention becomes the de facto specification.
• Write acceptance criteria that can fail. A criterion that cannot produce a red result is a description. This is the single element that decides whether the requirement is testable at all.
• Separate declarative notes from development notes. They answer different questions — what the platform is configured to do, versus what code was written — and merged into one paragraph, neither survives.

A good requirement is not a document. It is a contract, and every clause is there because someone downstream needs it to do their job.

The Contradiction Nobody Else Was Positioned to Find

Now the timing.

On that project, testing was engaged at the very end of the requirements work. Requirements written, signed off, developers already coding. The tester read them and found contradictions between them.

Notice what kind of defect that is. Not a contradiction inside one requirement — a contradiction between requirements, which you can only find by reading the set as a whole and holding it in one model. Almost nobody else in the delivery chain does that. An architect writes them sequentially. A developer reads the one they are building. A business analyst owns a slice.

The tester is often the first person to read the collection as a system, and they are usually scheduled to do it last.

Why the Right Finding Arrives as Damage

The value of the finding does not change with time. A contradiction between two requirements is worth the same whether you notice it on the day they were written or three weeks later.

The cost of acting on it multiplies with every downstream artefact that already exists. When the finding lands after sign-off and after coding started, the questions send the complete requirement set back to the architect. That is a re-planning event, and re-planning events have delays attached, and delays get attributed to whoever raised the trigger.

So the tester who did the most valuable thing available to them looks like the source of the slip. The same work, done two weeks earlier, would have been a series of quiet edits nobody would remember.

That is a scheduling defect, not a behaviour defect. The tester was placed where their finding could only be expensive.

The Rule

The cheapest bugs are the ones still in the requirements. A tester in the analysis phase is not an added cost — it is a discount applied to everything that comes after.

The question is never whether the contradictions get found. It is only whether they get found before or after somebody built on top of them.

The Reason You Cannot Simply Ask to Join Earlier

Because sooner or later a project manager asks how long testing this requirement will take, and if the answer is "I don't know", testing does not get a slot.

I have watched exactly that exchange. No estimate, no slot, and testing goes back to being whatever time is left.

The fix is a model, decided once and reused. Test effort expressed as a percentage of the development estimate, by type of work: data model 45%, CRUD 20%, Apex 30%, integrations 50%, complex logic 50%.

Calibrate the numbers against your own history and they will move. Their precision is not the point. The point is that a question which used to produce a week of hedging now takes ten seconds, in the meeting, while the plan is still being written.

And the model does a second job that is easy to miss. Look at what those percentages say: CRUD is cheap to verify, integrations and complex logic cost half of development again. Applied at estimation time, the model tells a project manager which requirements are expensive to verify before anyone writes the code — a risk conversation held at the only moment when the answer can still change the design.

How to Actually Get In Earlier

Two moves, and neither of them needs anybody's permission.

• Review the requirement set, not the requirement. Ask for the whole batch for a feature area and read it in one sitting, looking for two requirements that cannot both be true. That is the finding nobody else's role produces, and it is the argument for your seat.
• Attach your questions to the requirement, in writing, before development starts. At analysis time a question costs a clarification. At execution time the same question costs a rework — with your name on the delay.

Why It Stays This Way

Because "we have always done it this way" is not laziness — it is a process that works acceptably for the people who designed it.

Requirements written without acceptance criteria are perfectly usable by their author, whose model of the system fills every gap silently. The gaps only become visible to somebody who has to verify the thing without that model — and that person, in most organisations, arrives after the decisions are made.

Change the arrival time and the same person becomes cheap. Leave it, and they will keep finding the same defects at the most expensive possible moment, and keep being thanked for it in a tone that suggests otherwise.

On your current project, at what point does a tester first read the requirement — and how many artefacts already exist by then?