Quality assurance in distributed development projects

Quality problems in distributed delivery are usually attributed to the distance. The distance is rarely the cause. What distance does is expose gaps that a co-located team was papering over with informal conversation.

If “done” was never written down, a co-located team negotiates it at someone’s desk. A distributed team cannot, so the ambiguity becomes a defect. The fix is to close the gap, not to shorten the distance.

Define “done” before work starts, not at review

This is the highest-return practice and the one most often skipped, because it feels like bureaucracy until the first argument about whether something is finished.

A usable definition of done is specific and testable:

• Acceptance criteria written as scenarios, not as adjectives — “the system handles invalid input gracefully” is not testable
• Which environments it must work in, including the edge cases that matter to your business
• Non-functional expectations stated: response time, concurrent users, data volumes
• Documentation and test evidence included, not implied

The test: could someone who was not in the conversation verify it? If not, you have a shared assumption rather than a specification — and shared assumptions do not survive a time-zone boundary.

Quality ownership sits with the team that builds

The pattern that reliably fails is a separate QA function that receives finished work and finds problems in it. It creates a queue, delays feedback, and encourages the building team to treat quality as somebody else’s responsibility.

What works is quality owned where the work happens, with a specialist role that raises the team’s capability rather than inspecting its output — designing test strategy, building automation, handling exploratory testing that automation cannot.

For a distributed team this has a structural precondition: the team must be able to see the consequences of its work. Access to production telemetry, to the ticket queue, to real user behaviour. A team that cannot see what breaks cannot own quality, whatever the contract says — the same dynamic described in building a global capability centre to Swiss standards.

Where automation pays, and where it does not

Automation matters more in distributed delivery because the feedback loop is longer. A defect caught by a pipeline in ten minutes costs almost nothing; the same defect caught in a review the next morning costs a day.

Automate: regression tests for anything that has broken before, the deployment path, environment provisioning, security and dependency scanning, and the checks that run before a merge.

Do not automate: exploratory testing, usability judgement, or anything whose expected result changes frequently. A brittle test suite that fails randomly is worse than no suite, because teams learn to ignore it — and then ignore the real failure.

A useful order: automate the deployment path first, then regression, then breadth. Teams usually do this backwards and end up with wide test coverage they cannot run reliably.

The review loop that actually catches things

Three layers, each catching what the previous one misses:

• Automated checks on every change — fast, objective, no human time
• Code review by someone who will maintain it — catches design problems tests cannot see
• Acceptance against the written criteria — by whoever wrote them

The second layer is where distributed teams most often weaken. Review by whoever is available produces approvals rather than scrutiny. Review by someone who will live with the code produces questions.

One practice worth insisting on: the reviewer runs it. An approval based on reading the diff catches less than half of what running it catches.

Communication that keeps the loop short

The distributed-specific part, and mostly not about tools.

Overlap hours matter more than location. Same-day coordination, review and demo is the difference between a team and a queue. A 24-hour round trip on every question turns a two-day task into a week. This is why CET overlap is the criterion that matters rather than distance.

Write decisions down. In a co-located team the decision lives in the room; in a distributed one it has to live somewhere findable, or it gets re-litigated.

Make disagreement cheap. The most expensive failure mode in distributed delivery is a team that builds something it believed was wrong because raising it felt costly. That is a culture property, and it is visible in whether anyone has recently pushed back.

What to measure

Four numbers that tell you whether quality is holding:

• Defects found after release, as a share of those found before — the single most informative quality signal
• Change failure rate — releases requiring a fix
• Time to restore — because failures happen and recovery is the controllable part
• Rework rate — work returned as not-done, which is usually a specification problem rather than a skill problem

That last one is the distributed-specific diagnostic. High rework almost always means “done” was not defined clearly enough, and the fix is at the start of the process, not the end.

The Swiss dimension

Two things to plan for deliberately.

Documentation and test evidence are part of the deliverable in any regulated context — under revDSG/nDSG, GDPR, IEC 62304 for medical software, or FINMA expectations. Treating them as overhead creates an audit problem later. Generated from the pipeline, they cost almost nothing.

Data access for the distributed team. Engineers in another jurisdiction touching personal data is a real question, and the answers are pseudonymised test data, documented access controls and sub-processor records. Solvable — but not retrospectively, so settle it before the team starts.

Related reading

• Choosing a software development partner in Switzerland
• Building a global capability centre to Swiss standards
• Dedicated engineering teams

If quality is slipping and you want to know where the loop is breaking, book a call. No obligation.