Starting SIT Is Not the Same as Being Ready for SIT — 3 September 2026

A delivery team under schedule pressure skips an early readiness or shakeout step and moves straight into formal system/integration testing. The build exists, so testing starts. SIT then discovers missing functionality, failed business rules, interface mismatches, and negative scenarios that should have failed much earlier.

The immediate reaction is often: testing started too early.

The deeper problem is different:

The programme optimised for starting SIT, rather than producing a release candidate that was demonstrably ready for SIT.

This digest reviews current guidance on why this happens and how to prevent it without adding another heavyweight testing phase.

Executive summary

1. Readiness must be demonstrated, not assumed. A deployed build is not automatically a test-ready build.
2. SIT should verify integration risk, not implementation completeness. Basic business rules, interface contracts and negative scenarios should usually fail earlier.
3. A lightweight SIT readiness gate is better than another manual test phase. Define a small set of evidence-backed entry criteria.
4. Supplier and cross-team agreements should become testable contracts. Important requirements need executable verification where practical.
5. Schedule pressure should trigger explicit risk acceptance, not silent removal of controls.
6. The long-term target is continuous assurance. Automate readiness checks in CI/CD so every promoted candidate already satisfies the required conditions.

---

The root cause: readiness was assumed, not demonstrated

The most useful distinction is:

Build available ≠ implementation complete ≠ SIT ready

Teams often collapse these states into one.

A build can deploy successfully while still containing incomplete functionality, incorrect configuration, missing attributes, or unverified business rules.

Microsoft's current Azure Well-Architected guidance explicitly recommends defining entry and exit criteria for testing. Its example entry criteria include conditions such as code complete and environment configured, and it warns against beginning testing without a clear strategy and plan.

Microsoft — Architecture strategies for testing

Microsoft — Build confidence in Azure workloads with effective testing practices

The implication is simple: a planned SIT start date is a schedule commitment, not evidence of readiness.

Root-cause pattern

Schedule pressure
      ↓
Readiness control removed or weakened
      ↓
Incomplete candidate enters SIT
      ↓
SIT discovers upstream defects
      ↓
Triage + rebuild + redeploy + retest
      ↓
More delay and more governance friction

Skipping the readiness check does not eliminate verification work. It moves the work downstream, where the feedback loop is slower and more expensive.

---

SIT has become the wrong quality gate

A weak delivery model often behaves like this:

Development
    ↓
Deploy
    ↓
QA discovers whether it actually works

That makes SIT the first serious verification of implementation completeness.

This is an anti-pattern.

SIT should primarily answer questions such as:

• Do independently verified components work correctly together?
• Do end-to-end business flows survive real integration boundaries?
• Are failures caused by interactions between systems, environments or dependencies?

It should not primarily answer:

• Was the feature implemented?
• Does the service enforce basic business rules?
• Does the API return required attributes?
• Does an obviously invalid request fail correctly?

The UK Home Office's current Quality Assurance and Testing guidance recommends building quality controls throughout delivery, identifying risks early, avoiding rework, and weighting component integration and API integration tests more heavily than UI-driven E2E tests where the architecture allows it.

UK Home Office — Quality assurance and testing

That is directly applicable here: many defects appearing in SIT are often not “SIT defects”. They are upstream verification failures that SIT happened to expose.

---

Supplier and cross-team delivery needs evidence, not declarations

The problem becomes more severe when work crosses suppliers, platforms or internal teams.

A requirement may exist in a contract, specification, ticket or API document, but both sides may still interpret it differently.

That creates a dangerous handoff:

Supplier says "complete"
        ↓
Internal team assumes compliant
        ↓
SIT becomes the first real verification
        ↓
Defect becomes a contractual dispute

By the time the mismatch is visible, the technical issue is mixed with governance questions:

• Was the requirement clear?
• Was it implemented incorrectly?
• Was it never implemented?
• Was it interpreted differently?
• Who owns the remediation?

The better approach is to convert important agreements into testable acceptance conditions.

For interfaces and APIs this should include, where practical:

• required fields and attributes;
• valid and invalid values;
• error responses;
• authentication and authorisation behaviour;
• business-rule enforcement;
• compatibility expectations;
• negative scenarios.

The goal is not to turn every requirement into a contract test. It is to ensure that high-risk agreements are verified before formal system testing depends on them.

---

The recommendation: introduce an evidence-based SIT readiness gate

The solution is not necessarily to restore a heavyweight “shakeout testing phase.”

That risks replacing one problem with another ceremony.

Instead, define a small set of explicit conditions that a release candidate must satisfy before entering SIT.

A practical minimum could be:

Readiness condition	Expected evidence
Release scope is known	Version / release scope identified
Committed functionality is implemented	Delivery or supplier completion evidence
Critical acceptance criteria pass	Automated or documented verification
Core business rules pass	Unit / component / API results
Interface contracts pass	Contract or integration checks
Environment is usable	Deployment and smoke checks
Known gaps are visible	Documented limitations and owners

The important distinction is between an assertion and evidence:

"Development is complete"      → assertion
Passing business-rule tests    → evidence
Passing API/contract tests      → evidence
Passing deployment smoke test  → evidence

The UK Government's updated Gate 4: Readiness for Service guidance takes the same evidence-oriented approach. It expects test results against predefined acceptance criteria, confirmed end-to-end testing, identified incomplete items with corrective actions, stakeholder acceptance, and explicit decisions about whether to proceed.

UK Government — Gate 4 Review: Readiness for Service

The principle scales down well even if the project does not need formal programme governance:

Ready should mean the evidence satisfies agreed conditions.

---

Move negative scenarios earlier

A large number of failed negative scenarios during SIT is usually a useful signal that verification is happening at the wrong layer.

Examples include:

• missing mandatory attributes;
• malformed requests;
• invalid identifiers;
• duplicate operations;
• invalid state transitions;
• unauthorised requests;
• basic business-rule violations.

Most of these can be exercised more cheaply and deterministically through:

• unit tests;
• domain/business-rule tests;
• API tests;
• component integration tests;
• contract tests.

SIT should still include negative testing where the behaviour genuinely depends on system interaction. But basic service behaviour should not wait for a full integrated environment.

This follows the Home Office recommendation to favour lower-order contract/component integration coverage over excessive E2E coverage where possible.

UK Home Office — Quality assurance and testing

---

Do not silently remove the control under schedule pressure

Schedule pressure is unavoidable. Hidden risk acceptance is optional.

If a candidate does not satisfy every readiness condition but the programme still wants to proceed, make that decision explicit.

A simple model is:

Ready

All mandatory criteria pass.

Conditional entry

A non-critical criterion is unmet, impact is documented, and a named delivery/product owner accepts the risk.

Not ready

Critical functionality, business rules, interface contracts, or environment conditions fail.

This changes accountability.

Instead of:

QA allowed an incomplete build into SIT.

The record becomes:

Readiness criterion X was not met. Delivery accepted the stated risk and chose to proceed.

The UK Government Gate 4 guidance similarly expects risk/impact evaluation and explicit decisions on whether to delay or proceed.

UK Government — Gate 4 Review: Readiness for Service

---

The target state is automation, not another meeting

A readiness gate can become bureaucracy if every candidate requires a checklist meeting, spreadsheet, multiple approvals and manual evidence collection.

The maturity path should move in the opposite direction:

Manual checklist
      ↓
Checklist backed by test evidence
      ↓
Automated pipeline quality gates
      ↓
Continuous assurance

Thoughtworks describes a similar governance direction: replace process-intensive point-in-time gates with standards-as-code and continuous automated assessment where possible.

Thoughtworks — Putting architecture digitalization into practice

For SIT readiness, that could mean a pipeline automatically verifies:

Build
 ├─ unit/business-rule tests
 ├─ API tests
 ├─ contract checks
 ├─ security checks
 ├─ deployment verification
 └─ smoke tests
        ↓
   SIT-ready candidate

Human judgement remains important for exceptions and material risks, but routine readiness should progressively become machine-verifiable.

---

Reduce the batch size as well as strengthening the gate

A readiness gate prevents bad candidates from consuming SIT capacity, but it does not solve every structural problem.

DORA's current guidance emphasises small, testable batches, frequent integration and rapid feedback. It specifically warns against breaking work into small pieces and then regrouping those pieces into large batches before downstream testing or release.

DORA — Working in small batches

DORA's trunk-based development guidance similarly describes continuous integration as combining frequent integration with fast automated testing so teams can avoid long integration and stabilisation phases.

DORA — Trunk-based development

This matters because a readiness gate should not become a mechanism for validating another huge late-stage integration batch.

The stronger operating model is:

Small change
   ↓
Fast automated verification
   ↓
Frequent integration
   ↓
Continuously releasable candidate
   ↓
Focused SIT for genuine system risk

---

Ownership model

One governance improvement is especially important: QA should not own implementation readiness.

A clearer split is:

Responsibility	Primary owner
Requirement clarity	Product / BA
Implementation completeness	Development / supplier
Component verification	Development / supplier
Interface compatibility	Producing + consuming teams
Readiness evidence	Delivery team / supplier
Assessment of test readiness	QE / Test Lead
Exception / risk acceptance	Delivery / Product owner
SIT execution	QE + integration participants

QE should be able to state:

The evidence satisfies the agreed SIT entry criteria.

or:

Criteria X and Y are not satisfied; proceeding is a delivery-risk decision.

That is very different from making QA responsible for declaring development complete.

---

Measure the waste, not only the defect count

A high SIT defect count is useful information, but it does not expose the full delivery cost.

A better set of measures includes:

SIT entry failure rate

How often are release candidates rejected because they fail readiness conditions?

An initial increase may be healthy: problems are being caught before consuming SIT capacity.

Defect detection layer

Track where defects are first detected:

Unit → Component → API/Contract → SIT → UAT → Production

The desirable trend for basic implementation defects is leftward.

SIT rework rate

Track how much SIT execution must be repeated because the candidate is replaced, rebuilt or materially changed.

Invalid SIT effort

Measure tester time spent on defects that clearly belonged upstream.

For example:

30% of SIT effort was spent investigating implementation-completeness, contract, or basic business-rule failures.

That tells a stronger story than simply reporting “40 SIT defects”.

It shows that expensive downstream capacity is being used to perform upstream verification.

---

Recommended operating model

For teams seeing this pattern repeatedly, the initial intervention can stay small:

1. Define 5–7 mandatory SIT entry criteria.
2. Require suppliers and delivery teams to provide evidence with each candidate.
3. Automate high-risk interface and acceptance rules as API/contract checks.
4. Move basic negative and business-rule scenarios into lower test layers.
5. Require named risk acceptance when schedule pressure overrides a readiness criterion.
6. Track SIT rework and upstream-defect leakage.
7. Gradually move readiness evidence into CI/CD.

Do not introduce a large new testing phase unless the system genuinely needs one.

The strategic goal is that readiness becomes increasingly continuous and automated.

---

Final assessment

The recurring delivery failure is not simply “we skipped shakeout testing”.

The deeper issue is:

The delivery system had no reliable mechanism to prove that an integrated candidate was ready before formal SIT consumed it.

Under schedule pressure, the organisation optimised an intermediate milestone—starting SIT—rather than delivery flow.

The consequence is predictable:

Earlier SIT start
     ↓
Late discovery of cheap upstream defects
     ↓
Triage and ownership disputes
     ↓
Rebuild / redeploy / retest
     ↓
More delay

The better model is not “more testing”. It is earlier evidence, clearer ownership, smaller batches, testable contracts, automated readiness checks, and explicit risk decisions.

The practical target is straightforward:

SIT should verify the integrated system, not discover whether the system was built.

Sources

• Microsoft Azure Well-Architected Framework — Architecture strategies for testing
• Microsoft Azure Well-Architected Framework — Build confidence in Azure workloads with effective testing practices
• UK Government — Gate 4 Review: Readiness for Service
• UK Home Office — Quality assurance and testing
• DORA — Working in small batches
• DORA — Trunk-based development
• Thoughtworks — Putting architecture digitalization into practice and realizing the benefits

Source note

This digest prioritises current engineering guidance from standards-oriented public-sector organisations and established software-delivery research/practitioner organisations. The recommendations above combine those sources with independent quality-engineering interpretation; they should not be read as a direct prescription from any single source.