Give The Blocking Tests A Release Of Their Own

Mostafa Dhouib·10 min read

Give The Blocking Tests A Release Of Their Own

The short answer. Some specifications come with a large acceptance-test suite that blocks release and a safety gate that applies to everything the product does. If you scope the first release by feature value, as you normally would, two things go wrong. The gate gets partially rebuilt and renegotiated in every subsequent release, because each new feature passes through it. And the blocking tests belong to no release, so nobody owns them until they are the reason you cannot ship. The fix is to treat the gate as a deliverable component and give it its own release, before any feature release. Everything after it then has a fixed thing to be scoped against, and the blocking suite has an owner from the start.

This comes up on regulated builds more than anywhere else, because that is where specifications arrive with a conformance suite attached. It also comes up with payment flows, safety interlocks and anything where one check sits in front of every user action.

The shape of the problem

Two features of a specification create it.

A global gate. A single check that every operation must pass before it takes effect. A safety evaluation before actuation. A contraindication check before a recommendation is shown. An eligibility and limits check before money moves. An authorisation and consent evaluation before data is disclosed. It is not a feature. It is a precondition of all the features.

A large blocking acceptance-test suite. The specification ships with tests, or the regulator or customer defines them, and passing them is a condition of release rather than a quality goal. Hundreds of cases, many of them about the gate, most of them uninteresting to a stakeholder.

Now do the normal thing. Pick the highest-value user-visible slice for release one. Build it. To build it, you need the gate, because the feature cannot take effect without passing the gate. So you build the part of the gate that this feature needs, inside this feature's scope, under this feature's deadline.

Release two is a different feature with different inputs, so it needs more of the gate. Some of what release one built turns out to be specific to release one and has to be generalised. The acceptance tests for release two include gate cases that release one's partial gate does not satisfy, so those tests are now release two's problem, and they are discovered during release two's test cycle.

That is the renegotiation. Each release reopens the gate's design, its interfaces, its data requirements and its test coverage. The gate never gets a specification of its own, because it was always a means to something else. And the blocking suite accumulates against no owner, which means it gets attention at the point where attention is most expensive.

Why the blocking tests end up belonging to nobody

Work gets done when it is inside a release that someone is accountable for. That is the whole mechanism by which planning causes delivery.

A blocking acceptance suite defined by a specification does not map onto feature releases. A given test case may exercise the gate, two features and an edge case in the data model. Which release owns it? In practice, the one that happens to be running when someone tries to execute it and it fails.

So the suite sits outside the plan. Everyone agrees it must pass. Nobody has it in their sprint. It becomes visible as a schedule risk exactly once, late, when the suite is run end to end for the first time and the failures are architectural rather than local. Then you are fixing the gate's design under release pressure, which is where the expensive decisions get made badly.

Giving the gate its own release fixes the ownership problem directly. The gate's release owns the gate's test cases. Those cases are its acceptance criteria, which means they are run from the first week rather than the last. It is the same argument as treating the rules engine as the product rather than as plumbing behind the screens.

What a gate release actually delivers

It is worth being concrete, because "an infrastructure release" sounds like a licence to disappear for a quarter.

The gate as a component with a defined interface. Inputs, outputs, error cases, versioning. Callable by anything, depending on nothing above it. If it can only be invoked through a screen, it is not a component.

The decision table or rule set in data, not code. The specification's logic expressed as reviewable data, so a domain expert can read it and a change does not require a deployment. That matters more than it sounds, because the gate's logic is the part most likely to change and most likely to be audited. The general case is in put the catalogue in data.

The relevant portion of the blocking suite, passing. Not a sample. The subset of the specification's tests that address the gate, executed, with results recorded in whatever form your process requires.

A harness that runs the suite on demand and in continuous integration. The thing that makes every later release cheap. Without it, each release re-establishes how to run the tests.

Evidence that the gate can fail. Negative cases proving the gate blocks what it should block, not only that it permits what it should permit. A gate verified only on the permit path is the implementation-without-effectiveness problem described in every risk control is verified twice.

Traceability from specification clause to rule to test. Built as you go. Retrofitting this is the single most reliable way to lose a month.

One thin vertical slice that exercises it end to end. This is the part teams leave out and should not. A single narrow path through a real interface, hitting the gate, producing a real outcome. It proves the component is integrable rather than merely finished, and it gives you something to show.

How to sell it to a stakeholder who wants to see something

This is the actual obstacle. The engineering case is easy. The conversation with the person funding it is not, and "we are building infrastructure this quarter" is a bad answer.

Lead with the gate as the product's central promise, not as plumbing. In a regulated or safety-relevant product, the gate is usually the thing the product exists to guarantee. The screens are how people reach it. Said that way, the first release delivers the promise and the second delivers access to it, which is a more honest description of the value than the reverse ordering suggests.

Show the blocking suite as a number and track it weekly. Cases passing out of cases required. A stakeholder who wants visible progress can have progress on a chart that maps directly onto the condition for shipping. This is the single most effective move I know, because it replaces an invisible deliverable with a visible one.

Name the renegotiation cost in their units. If every feature release reopens the gate, each one carries rework and a test cycle that discovers architectural problems late. You are not asking for extra time. You are asking to spend it once instead of five times. Stakeholders accept this readily when it is framed as sequencing rather than as scope.

Always include the thin vertical slice. One narrow path, end to end, in the real interface. It is a demo, it is honest, and it costs little once the component exists. Insisting on a pure infrastructure release with nothing to look at is a fight you do not need to have.

Make the gate's release criteria contractual. Written down, agreed, measurable: these specification clauses implemented, these test cases passing, this traceability produced. A release with hard criteria is easier to defend than one described by activity.

Be explicit that it does not reduce total scope. It reorders it. If you imply the features get cheaper you will be held to that, and the credibility loss is worse than the original argument.

The honest limit

This is the right shape when the gate is genuinely global and the blocking suite is genuinely large. It is the wrong shape when the gate is small, or when the specification is still moving. Building a component against a specification that will change substantially means building the wrong component carefully, and in that situation a thin feature slice that forces the specification to be pinned down is more useful.

There is a real risk that a gate release becomes a platform project with no end. The protection is hard release criteria tied to specification clauses and test cases, agreed before the release starts, plus the vertical slice that forces integration. Without those, "build the gate first" turns into a quarter of architecture.

I should also be clear about the status of the claim. This is a sequencing judgement from practice, not a measured result. I have not run the counterfactual where the same team scoped by feature value and compared the total effort. What I have seen repeatedly is the failure mode on the other side: the blocking suite discovered late, owned by nobody, failing for architectural reasons at the point where architectural change is most expensive. The ordering argued here is a response to that pattern, and you should weigh it as such.

Finally, whether your specification's acceptance suite truly blocks release, and in what form the results must be recorded, is a function of your regulatory scope and the current version of the governing documents. Confirm it against the applicable current text rather than against a planning habit.

FAQ

What is wrong with scoping the first release by feature value? When a global safety gate sits in front of every operation, the first feature release builds only the part of the gate it needs, under its own deadline. Every later release then needs more of the gate, generalises what the first one built, and inherits acceptance-test cases the partial gate does not satisfy. The gate gets renegotiated once per release instead of designed once.

Why do blocking acceptance tests end up with no owner? Because work gets done when it sits inside a release someone is accountable for, and a specification-defined suite does not map onto feature releases. A single case may cross the gate, two features and the data model. So the suite sits outside the plan, and it becomes visible exactly once, late, when it is run end to end and the failures turn out to be architectural.

What should a gate release deliver? The gate as a callable component with a defined interface, its rule set expressed as reviewable data rather than code, the portion of the blocking suite that addresses the gate passing with recorded results, a harness that runs the suite in continuous integration, negative cases proving the gate can block, traceability from clause to rule to test, and one thin vertical slice exercising it end to end.

How do I justify an infrastructure release to a stakeholder? Describe the gate as the product's central promise rather than as plumbing, since in a regulated product it is usually the thing the product exists to guarantee. Then track cases passing out of cases required as a weekly number, so invisible work becomes visible progress against the actual condition for shipping. Include the vertical slice so there is something to look at.

Does this reduce the overall amount of work? It reorders it rather than reducing it, and you should say so plainly. The saving is in not paying the gate's design and integration cost once per feature release, and in not discovering architectural test failures under release pressure. Promising cheaper features is a credibility risk you do not need to take.

When is this the wrong approach? When the gate is small enough that no renegotiation cost exists, or when the specification is still changing substantially, in which case you would be building the wrong component carefully. It is also wrong without hard release criteria tied to clauses and test cases, because without those the gate release drifts into an open-ended platform project.