Passing the Outer Layer Is Evidence About the Outer Layer

The test passed on the first click. That was the problem.

The Setup

A rule that says a locked account cannot proceed. It is enforced in four stacked layers.

Three of them are easy to name from the front. The button is hidden. A validation rule blocks the edit. An orchestration gate blocks plan creation.

Each was built by somebody solving the same problem at their own altitude, and each works.

The Symptom

I opened the record as the actor named in the story. The button was not there.

Which is a pass. The rule is enforced, the user cannot proceed, the expected result in the test case is satisfied word for word. Screenshot, evidence attached, move on.

Except the story did not deliver a hidden button. The story delivered the orchestration gate — the innermost layer, the one that decides what happens after submission. And the actor named in that story cannot reach it, because two layers above it stop them first.

So the pass I recorded was evidence about the button. Nothing else.

Getting to the Layer

The state I needed does not occur by walking the journey. It has to be built.

Build the cart while the account is unlocked. Set the flag. Then press Submit.

Three steps, and the middle one is the whole trick: the lock arrives after the work has started, not before. Once the cart already exists, the hidden button is irrelevant — that layer has already been passed, legitimately, at a time when passing it was correct.

That is the only sequence I found that puts a submission in front of the orchestration gate. It is not a workaround and it is not a hack. It is a real ordering of events, which is why the innermost layer exists at all.

Why the Journey Hides It

Test design defaults to walking the user journey. It is the honest default — it mirrors what a real person does, it produces readable steps, and it is what a business reviewer can sign.

A journey stops at the first layer that blocks it.

That is the failure mode, and it is silent. The deepest layer is never exercised, and the test report says the feature works. Not "partially works." Works. Every case green, every screenshot correct, every expected result matched — and the component the story was written to deliver has never once been reached.

Defence in depth does this to test coverage. The more layers you add, the harder the innermost one is to reach, and the more convincing the evidence that you do not need to reach it.

What This Was Not

It was not a broken layer. All of them behaved correctly.

It was not a bad test case either. The steps were right, the expected result was right, and the tester who wrote it followed the journey the story described.

It was a mismatch between the actor in the story and the layer in the story. Those two fields sit in the same document and nobody compares them, because comparing them is not a step in any template.

The Rule I Took From It

When a rule is enforced in layers, identify which layer the story delivers, then construct the state that arrives at that layer. Do not walk to it. You cannot walk to it — that is what the outer layers are for.

And then ask the follow-up, which is where the real risk sits: which paths reach that layer without a UI at all?

An API call. An integration. A batch job. A cart built before the lock landed.

None of those see a hidden button. None of them see a validation rule on a screen the caller never opens. For those callers the innermost gate is not the last line of defence — it is the only one, and it is the layer with the least test evidence behind it.

In the story you are testing right now, which layer does it actually deliver — and can the user in the acceptance criteria reach it?