Your Sprints Are Two Weeks. Your Integration Is Waterfall.

The sprints are two weeks long. The next integration window is about two months away.

Both of those sentences describe the same project. Nobody set out to build it that way.

SIT receives a single deployment per release. With the next release still in build, full end-to-end, integration and regression testing all happen once, late, for the entire release at once. Everything before that runs against a QA environment where the release exists in pieces.

An Agile Front Over a Waterfall Backbone

The ceremonies are real. Sprint planning happens, stand-ups happen, stories move across a board every fortnight and the burndown is honest.

What does not happen every fortnight is integration.

That distinction is easy to miss because the visible artefacts all say agile. The board says agile, the cadence says agile, the retrospective says agile. The deployment calendar says something else entirely, and the deployment calendar is the one that determines when defects are found.

So the question worth asking on any project, before you accept its description of itself: where does integration actually happen, and how often? Not where does the code get written. Where do the systems first meet.

What That Structure Does to QA

If integration is a one-shot gate at the end of a release, then QA is not one validation layer among several. It is the only live validation window during the entire build.

There is no per-sprint integration environment to dry-run against. There is no earlier point at which a cross-system scenario can be executed and fail cheaply. Whatever QA does not catch is not caught by anything until the release-end window opens, by which time the fix is competing with a deployment date.

That changes what a test strategy is supposed to maximise. It is not "cover the story and rely on the layers downstream." There are no layers downstream in any meaningful sense — there is one, it is expensive, and it is late.

The Leakage Number Is Structural

In one cycle, roughly 40% of the defects found in SIT should never have left QA.

The instinct on seeing that number is to look at people. Which testers, which areas, who is not being careful enough. That instinct produces a conversation that feels like accountability and changes nothing, because the number is mostly a property of the structure.

When there is no integration environment during the build, cross-system defects have nowhere to surface except the one-shot window. When the one-shot window is the first time anything meets anything, it will find things — and every one of them will be classifiable, after the fact, as something QA might have caught.

That does not make the number unimportant. It makes it a question about the shape of the process rather than about individual diligence.

The Half You Can Fix This Sprint

There is a second cause, and this one is not structural at all.

Testers are pushed to write detailed test cases blind: from the requirements only, before the change exists in the QA environment in any observable form. Then the same person who wrote the analysis executes the tests.

Two things follow from that, and both are predictable.

Writing detailed cases against a complex Salesforce Industries build you cannot yet see guarantees weak first drafts. Not careless drafts — weak ones. The parts of the system that will surprise you are precisely the parts you cannot anticipate from prose, so the case covers what the requirement describes and misses what the implementation does.

And when the analyst and the tester are the same person, the second pass inherits the assumptions of the first. If you decided during authoring that a field behaves a certain way, you will execute the case in a way that confirms it. There is no separate moment where that assumption gets challenged, because there is no second person.

Shift Left Has a Precondition

Moving test-case authoring earlier is meant to be an improvement. It backfires when it is shifted past the point where the system is observable.

The fix is not to move authoring back. It is to split it by what can honestly be known.

• Before the change is visible, write conditions, risks, data needs and open questions. These are exactly the artefacts that gain from being early — they drive conversations with the developer and the analyst while the build is still cheap to influence.
• After the change is observable, write the detailed steps and expected values. That is when you can see the actual field, the actual sequence, the actual error, and the case stops being a guess dressed as a specification.
• Put the peer review between the two. A second tester reading your conditions before execution costs half an hour and catches the gap that would otherwise be found by SIT six weeks later at a hundred times the price.

Peer review is the part that stings, because on this project it is already mandated. The organisation's own QA standard requires it. It is not being skipped as a considered trade-off — it is being skipped because nothing in the schedule allocates time to it, and an unallocated activity does not happen no matter what the standard says.

Why This Escapes Every Retrospective

Retrospectives look at the sprint. This problem is not inside a sprint.

The cost of the missing integration window does not appear until the release window opens, which is several sprints after the decisions that caused it. By then the conversation is about the defects themselves — which ones block the go-live, who fixes what by when — and not about why they all arrived at once, in the most expensive possible place.

A leakage rate is a diagnostic about your process shape. Before treating it as a quality problem, find out where your integration actually happens. If the answer is "once, at the end", then your QA window is not the first of several safety nets.

It is the net.

On your project, how many times does a cross-system scenario get executed before the release-end window — and if the answer is zero, what is your test strategy assuming?