How do you handle disagreement between engineers on E2E test ownership — devs or QAs?

"Whose tests are these?" is one of the most common organisational frictions in test-heavy teams. The unhealthy patterns to avoid:

• Devs throw it over the wall. "I'm done; QA writes the tests." Cycle time tanks; QA becomes a bottleneck; devs disclaim responsibility for breakage.
• QA owns everything. Devs lose context on what's tested; the QA team becomes a drag on velocity; tests duplicate logic the devs already verified at unit level.
• Nobody owns it. The suite drifts into a flaky, untrusted state.

The shared-ownership model that works:

Unit and integration tests — devs own. They're the closest to the code, written first, run on every commit. QA may pair on test design but doesn't write them.

E2E — joint, with clear allocation.

• Top user journeys (login, checkout, the headline feature) — the QA / automation team owns the tests. They cover cross-team flows and need a holistic view.
• Feature-specific E2E (a new admin page, a settings tab) — the dev team owns the test, the QA team reviews it for quality and consistency. Tests ship in the same PR as the feature.

Framework, custom commands, fixtures, CI infrastructure — QA owns. It's a shared library devs consume.

Flake quarantine and triage — QA owns the SLA but flake fixes are joint. Whoever touched the area last takes the fix.

The cultural moves:

• Test-writing is part of definition-of-done. No PR ships without the tests for its scope. The QA team approves; devs author.
• Pair on writing the first few. When a dev's writing their first Cypress test for a new feature, a QA engineer pairs. Knowledge transfers without becoming a bottleneck.
• Publish quality bars (flake rate, escape rate, coverage). When responsibility for a bar is named, "owns the test" stops being a debate.
• Avoid tracking 'tests written by QA vs dev' as a metric. It produces gaming, not collaboration.

When the disagreement is a real conflict:

• Sometimes it's about workload. "Devs don't have time to write E2E" usually means E2E framework is too heavy or test coverage targets are unrealistic. Fix the friction before fixing the ownership.
• Sometimes it's about skill. Devs new to Cypress need pairing, not lectures.
• Sometimes it's about incentives. If devs are evaluated on velocity-only and QA on coverage, the conflict is structural — escalate to engineering management.

The lead's job: surface the structural issue, propose a shared-ownership model with clear bars, and reduce the cost of writing tests so neither side is overburdened.