We all want high end-to-end (E2E) test coverage that’s stable, reliable, and fast, because it gives our teams the confidence to innovate and ship faster, knowing that bugs will be caught before they sneak into production. The decision that teams face is who should be responsible for building the tests, investigating failures, and maintaining them as they break.
One common approach is to have developers do the work by including it in the definition of done for a feature or release. It’s a logical approach. After all, who knows the product better than the developers who built it?
By putting E2E test suite management onto the developers building the features, we assume that…
- Developers will ship fewer bugs because they’re responsible for writing and maintaining tests themselves—thereby improving overall code quality; and…
- It will speed up the software development life cycle if the same people who code are also responsible for writing end-to-end tests.
As with any strategy, it's important to acknowledge and mitigate the risks if you're going to be successful.
Below, we explain what to look out for when asking developers to balance feature development with test suite management.
Watch for productivity loss
It’s easy to think that writing a test case is a one-off, but the real work lies in investigating failures and maintaining the tests as the product changes. In organizations where developers are responsible for investigation and maintenance, 20-40% of their time is spent on QA functions.
That’s two days a week, and as many as 100 days a year, during which the developer is not focused on feature delivery and the product roadmap. And with developers earning $150,000/year or more, that translates to $30,000–60,000/year per developer that is not being used to build features.
This time can be compounded by developers “babysitting builds” while waiting for their tests to finish in CI (plus re-running and debugging flaky tests).
Consider whether devs have a testing mindset
Testing isn’t just about writing code—it’s both an art and a science. To achieve comprehensive, meaningful coverage, you need deep expertise in knowing what to test, how to test it effectively, and ensuring that your results are accurate, reliable, and actionable. Developers are excellent at testing their own code paths, but large end-to-end suites require a different kind of operational focus. Their training emphasizes building functionality and shipping code, not mastering the nuances of testing and quality assurance.
Moreover, developers are naturally very close to their own code, which creates blind spots and biases. They test scenarios based on assumptions and expectations rather than real-world user behaviors or edge cases that arise in complex, unpredictable environments. As a result, important user flows, or edge cases, can be missed unless teams deliberately step back and design coverage around real user behavior.
Protect time for devs to prioritize testing
There's only so much time in the week, and when deadlines get tight, testing is usually the first thing to go. Teams are constantly under pressure from business stakeholders to ship new features faster, which means test suite creation and maintenance quickly become “nice-to-haves.”
When teams try to cram too much work into each sprint, instead of pushing back on timelines or scaling down the scope, it's easier to quietly skip or delay writing and updating tests. It feels harmless at first—after all, the features are still getting out the door, and users won’t immediately notice if the testing isn't thorough.
But this approach quickly snowballs. Each skipped test or neglected update adds a little more risk and technical debt, causing problems down the road that ultimately slow down future development cycles even more. Eventually, teams find themselves stuck playing catch-up, constantly chasing bugs that slipped through gaps in their test coverage. What started as a quick fix to hit a deadline becomes an ongoing problem that gets harder and harder to solve.
Give end-to-end testing the focus it requires
Developers bring the most value when they can focus on building reliable product functionality supported by strong unit and integration tests. Those tests fit naturally into the development process, providing fast feedback while code is being written.
End-to-end testing introduces a different set of challenges. Designing meaningful coverage, investigating failures, and maintaining tests as the product evolves requires sustained operational attention. Without that focus, even well-written tests can become brittle or fall out of sync with how the application actually behaves.
Teams address this in different ways. Some assign ownership of the E2E suite to dedicated QA engineers. Others keep ownership with developers but invest in platforms that reduce the operational burden of running and maintaining large suites. Platforms like QA Wolf support both approaches, allowing teams to build and run tests themselves or partner with QA Wolf for additional support.
What matters most is ensuring that end-to-end testing receives the attention it needs to stay reliable and maintain deep coverage of the flows that matter most to the business. When that happens, teams gain the confidence to ship quickly while knowing their most important user experiences are protected.
