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 E2E tests.
What we find is that neither of those things really works out in practice. Below, we explain what happens in organizations when developers have to balance feature development with managing a test suite.
Productivity suffers, and costs increase
It’s easy to think that writing a test case is a one-off thing, but the real work is investigating failures and maintaining the tests as the product changes. In organizations where the developers are responsible for investigation and maintenance, anywhere between 20 and 40% of their time is absorbed in QA functions.
That’s two days a week, and as much as 100 days a year, that 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,” when developers are waiting for their tests to finish in CI (plus re-running and debugging flaky tests).
The skills gap leaves critical workflows untested
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, skilled though they are, simply don’t specialize in these areas. 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, key user flows or critical interactions can remain entirely untested, simply because the developer didn’t anticipate them or dismissed their significance.
Pressure to release means test coverage gets deprioritized
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.
Without the tests or the time to build them, teams revert to manual testing
When teams can't find the time to build or maintain automated tests, they fall back on manual testing. At first glance, this might seem like a quick fix—after all, manual testing doesn't require upfront development or ongoing maintenance. But this shortcut comes at a cost.
Manual testing is slow, tedious, and error-prone. It requires people to meticulously repeat the same steps for each new release, making it difficult to achieve consistent results. Human testers inevitably miss issues due to fatigue, distractions, or simply overlooking certain scenarios. Over time, manual testing becomes a bottleneck, causing releases to slow down significantly.
Meanwhile, any automated tests left running in CI begin to deteriorate without regular maintenance. Flaky tests fail unpredictably, tests start to break and get disabled entirely, and the coverage gaps widen. Soon, the safety net that teams originally built to catch bugs deteriorates, allowing issues to slip into production more frequently.
The end result: slower releases, declining confidence in software quality, and frustrated teams constantly firefighting issues that automation could have prevented.
Let developers focus on code quality, not test management
Developers bring the most value when they can concentrate on writing robust, well-structured code, supported by strong white-box unit and integration tests. These tests are naturally aligned with their workflow, providing immediate feedback during development and catching critical issues early, exactly when they're easiest and least costly to fix.
But E2E black-box testing is fundamentally different. It requires specialized expertise and an objective perspective that developers can't easily maintain due to their closeness to the code. Handing off black-box testing responsibilities to dedicated QA engineers or managed testing services like QA Wolf allows teams to achieve comprehensive, reliable test coverage without compromising developer productivity.
This separation of responsibilities offers clear benefits: developers gain more time and space to innovate and ship features faster, while QA specialists ensure thorough, unbiased testing that consistently catches bugs before they reach production. The result is a faster, safer development process that improves both software quality and business outcomes.
.svg){kind=logo}
