Why Most Software Projects Skip E2E Test Automation

Robert Dey February 6, 2026

Most software teams know they should automate their end-to-end tests. The data is clear: production defects cost enterprises $1.7 trillion globally each year, and bugs caught in production cost 10-100x more to fix than those found during testing. Yet only about 5% of companies have achieved full test automation. This article examines the research on why E2E test automation adoption remains low, particularly among smaller companies, and what teams can do to overcome these barriers.

Which Companies Neglect E2E Test Automation?

Before diving into the reasons, it helps to understand which types of organizations most commonly operate without comprehensive E2E test automation.

Startups and Small Teams

Research shows that smaller organizations face disproportionate challenges with test automation. Over 25% of startups have less than 1 QA engineer per 10 developers, compared to medium and large organizations that typically maintain 1-3 QA engineers per 10 developers. Many 3-person SaaS startups operate without any dedicated QA role at all, with co-founders handling testing alongside product management.

This resource imbalance creates predictable outcomes. Smaller teams struggle to keep up with release timelines, and many face delays in releasing products due to testing constraints. A clear indicator of strain for small startup QA teams is shipping untested software, a sign that these teams are overburdened.

Growing SaaS Companies

SaaS companies in growth mode often accumulate testing debt. The pressure to ship features quickly means testing infrastructure gets deprioritized. Cloud-based automation tools are gaining traction among SMEs and startups because they’re more affordable and scalable, but adoption still lags behind larger enterprises.

The automation testing market data tells a story: while SMEs represent the fastest-growing segment at 18.2% CAGR, large enterprises still command 58.41% of the market share. This gap suggests smaller companies are catching up, but many haven’t yet made the investment.

Web Agencies and Service Businesses

Agencies face a unique challenge: each client project has different technology stacks, testing requirements, and timelines. Building reusable test automation frameworks across diverse projects is difficult, and client budgets often don’t include testing infrastructure costs.

For these organizations, manual testing feels faster for one-off projects, even though it doesn’t scale. The initial setup cost of automation makes less sense when projects are short-term.

Companies with Legacy Codebases

Organizations running legacy systems face architectural limitations when trying to implement modern testing practices. According to the World Quality Report 2024-25, 64% of respondents cite reliance on legacy systems as a key barrier to advancing automation efforts.

Legacy applications often weren’t built with testability in mind. They may use outdated UI frameworks that don’t work well with modern automation tools, lack stable element selectors, or rely on technologies like iframes that complicate browser automation.

The Real Barriers to E2E Test Automation

Survey data and industry research point to several consistent barriers that prevent teams from implementing E2E test automation. These aren’t excuses. They’re real constraints that require deliberate strategies to overcome.

Time Pressure and Deadline Constraints

The most frequently cited barrier is simply not having enough time. According to industry surveys, 39% of companies cite lack of time as their primary obstacle to test automation. Development teams face constant pressure to deliver features, and testing infrastructure often gets pushed to “later.”

This creates a vicious cycle. Manual testing consumes up to 50% of total development effort. Without automation, teams spend more time on repetitive testing, leaving even less time to build the automation that would save time. One veteran manual tester observed that their company had attempted E2E test automation four times: “Every time, people started with excitement; then very quickly, no one was interested in it anymore, until the next time.”

The time problem compounds because test automation only pays back in the mid-term after initial investment. Teams stuck in firefighting mode can’t make that investment.

Skill Gaps and Expertise Shortages

Implementing E2E test automation requires specific skills that many teams don’t have. The World Quality Report found that 53% of companies cite insufficient engineering skills among quality engineers as a barrier to effective test automation.

For smaller companies, this challenge is more acute. Small companies and startups may not be able to afford dedicated automation engineers, and the skills gap shows in implementations that don’t meet expectations.

The rise of AI-powered testing tools reflects this challenge. Webinar polls reveal that 74% of participants identify as beginners in AI testing, emphasizing the demand for tools that lower the barrier to entry. Low-code and no-code testing platforms are growing specifically to address this skills gap.

Initial Cost and Resource Investment

Setting up E2E test automation requires upfront investment in time, tools, and infrastructure. For cash-constrained startups, this cost can be hard to justify against immediate feature development.

The cost of developing automated tests can be expensive and time-consuming. Automating complex tests requires more effort than writing simple unit tests, and automated E2E tests often take longer to write than running a manual test once. The return on investment is real: documented cases show Year 1 ROI of 300-700% on automation investments. But that return requires surviving the initial investment period.

Tool costs add up too. Most QA groups juggle four or five platforms: Selenium for browsers, Postman for APIs, Cypress for front ends, plus separate tools for security and mobile. Every new tool adds setup time, configuration debates, skill gaps, and maintenance that can consume up to half of QA resources before running a single test.

Test Maintenance and Flaky Tests

E2E testing has a somewhat-earned reputation for unstable, flaky tests. Test suites pass one day with no issues, only to fail the next for no apparent reason. Because E2E tests validate multiple components throughout a test run, isolating problems becomes difficult.

Manual test code development and maintenance are the main challenges in test automation. As applications evolve, E2E tests require ongoing maintenance. A single UI change (like renaming a button ID) can break multiple tests.

This maintenance burden is why many test automation initiatives fail after initial enthusiasm. Teams build a test suite, but when the application changes faster than they can update tests, the suite becomes unreliable and eventually abandoned.

Changing Requirements and Rapid Development

For 46% of companies, frequent requirement changes create barriers to maintaining automated tests. In fast-moving environments, features get redesigned before tests are finished. User journeys shift based on feedback. What was a critical path yesterday may be deprecated tomorrow.

This challenge affects startups and smaller companies disproportionately. Smaller organizations with agile teams have a higher frequency of releasing features daily and weekly, which means more changes and more test updates.

When requirements change faster than tests can adapt, manual testing feels more flexible, even though it doesn’t scale.

Management and Organizational Priorities

Test automation fails without management commitment. Poor management is likely near or at the top of the list of reasons for test automation failure. Test automation can generate significant ROI, but it takes time, and management must be committed with carefully calibrated expectations.

The problem often starts with unrealistic expectations. Developers and managers get sold on test automation assuming it will eliminate all manual testing or drastically reduce test cycle times. When reality doesn’t match the pitch, disappointment leads to abandonment.

When team focus shifts to other tools or new project priorities, automation fails to meet expectations, forcing teams back to manual testing.

No Comprehensive Testing Strategy

The World Quality Report found that 57% of respondents cite lack of comprehensive test automation strategies as a key barrier. Many teams start automating without clear goals for what to automate, how to maintain tests, or how to integrate automation into development workflows.

Without strategy, automation efforts become fragmented. Different team members automate different things using different approaches. There’s no shared infrastructure, no consistent patterns, no clear ownership. Eventually, the fragmented tests become more burden than benefit.

Tired of debugging production issues that tests would have caught?

kiteto uses AI to generate E2E tests from natural language descriptions, reducing the skill gap and setup time that block most teams from automation.

The Cost of Skipping E2E Test Automation

Understanding the barriers is important, but so is understanding what skipping automation actually costs. The numbers are significant.

Production Defects Are Expensive

Production defects cost enterprises $1.7 trillion globally each year, with individual critical bugs averaging $5.6 million in business impact. For enterprise-level companies, the average cost of a single hour of critical application downtime exceeds $300,000, with some outages surpassing $1 million per hour.

The cost escalation is dramatic: a bug fixed during design is 100 times cheaper to resolve than the same bug found in production. Fixing a bug after release can cost up to 30 times more than fixing it during development.

These numbers may seem abstract for smaller companies, but the principle scales. A critical bug in production means emergency fixes instead of planned work, customer support escalations, potential churn, and reputation damage.

Developer Time Gets Consumed by Bug Fixing

Development teams spend, on average, 30-50% of their time fixing bugs and dealing with unplanned rework. This time directly competes with feature development. Every hour spent on production bugs is an hour not spent building the product.

E2E tests catch bugs before they reach production, reducing this maintenance burden and freeing developers for planned work.

Release Velocity Suffers

Without automated E2E tests, teams face a choice: release slowly with manual testing, or release quickly with higher risk. Neither option is good.

Manual testing creates bottlenecks. Teams wait for testers to verify changes. Testers scramble to cover everything. Developers make last-minute changes that restart the cycle. The result is delayed releases or untested code reaching production.

The Case for E2E Test Automation

Despite the barriers, E2E test automation delivers measurable benefits that justify the investment.

ROI Is Documented and Substantial

Real-world examples demonstrate significant returns:

• One e-commerce platform achieved Year 1 ROI of 644% on a $180,000 investment, with 3-Year Cumulative ROI of $3.8M
• A B2B SaaS platform achieved Year 1 ROI of 721% on a $95,000 investment, protecting $3.2M in average customer lifetime value

The World Quality Report found that organizations with mature automation reduce manual testing by up to 62%. Teams leveraging automation execute test cycles 75% faster.

Quality and Speed Aren’t Tradeoffs

Research from the DevOps Research and Assessment (DORA) team demonstrates that top-performing teams excel at both deployment frequency and change failure rate simultaneously. Speed and stability reinforce each other when supported by effective automation.

Elite performers deploy on-demand, often multiple times daily, while maintaining change failure rates of 0-15%. Low performers deploy monthly or less with change failure rates of 46-60%. The difference isn’t choosing between speed and quality. It’s having the automation infrastructure that enables both.

Early Bug Detection Compounds Savings

The cost escalation of bugs is well-documented. Catching bugs earlier is exponentially cheaper:

E2E tests run during development or in CI/CD pipelines catch issues before they compound. Even imperfect test coverage that catches 50% of bugs before production delivers significant cost reduction.

Test Automation Enables Continuous Delivery

Organizations that want to ship frequently need automated verification. Manual testing can’t keep pace with daily or multiple-daily deployments.

Industry data shows DevOps integration grew from 16.9% in 2022 to over 51.8% by 2024, indicating a shift toward unified quality approaches where automated testing becomes central to deployment workflows.

Where to Start: A Practical Guide for Small Teams

For teams that have avoided E2E test automation, starting doesn’t require massive investment or dedicated automation engineers. Here’s a practical approach.

Start with Your Critical Path

Don’t try to automate everything. Identify the one or two user journeys that absolutely must work:

• For an e-commerce site: checkout flow
• For a SaaS app: sign-up and core feature activation
• For a web agency project: the client’s most important conversion path

Automate these first. A single reliable E2E test that validates your critical path provides more value than 100 flaky tests covering edge cases.

Choose Tools That Match Your Team’s Skills

Tool selection should prioritize your team’s existing capabilities:

• If your team knows JavaScript, consider Playwright
• If you need cross-browser testing with minimal setup, look at cloud-based solutions
• If coding is a barrier, evaluate low-code or AI-powered tools that generate tests from natural language

The goal is reducing friction to adoption, not picking the “best” tool by some abstract criteria.

Integrate Tests into Your Deployment Pipeline

Automated tests only help if they actually run. Integrate your E2E tests into your CI/CD pipeline so they execute on every deployment or pull request.

This integration provides immediate feedback and creates accountability. When tests block deployments, teams can’t ignore them.

Accept Imperfect Coverage Initially

Perfectionism kills test automation initiatives. Start with 10% coverage of critical paths. Then 20%. Then gradually expand.

Research shows that 26% of teams are replacing up to 50% of their manual testing efforts with automation, and 20% are replacing 75% or more. These teams didn’t achieve that coverage overnight. They built it incrementally.

Invest in Test Maintainability

From the beginning, structure tests for maintainability:

• Use page object patterns or similar abstractions to isolate UI changes
• Keep tests focused on user behavior, not implementation details
• Delete flaky tests rather than letting them undermine confidence in the suite

A smaller, reliable test suite is more valuable than a comprehensive but unreliable one.

Budget Time for Maintenance

Accept that E2E tests require ongoing maintenance. When planning sprints, include time for test updates alongside feature work. This isn’t overhead. It’s the cost of maintaining a working safety net.

Conclusion

The barriers to E2E test automation are real: time pressure, skill gaps, initial costs, maintenance burden, and organizational priorities. These barriers disproportionately affect smaller companies, which often operate without dedicated QA resources.

But the cost of skipping automation is also real. Production defects drain developer time, delay releases, and cost organizations significantly more than early detection would. The research consistently shows that teams with effective test automation deploy faster with fewer failures.

Starting doesn’t require solving all barriers at once. Begin with critical paths, choose tools that match your team’s skills, integrate tests into your deployment process, and build coverage incrementally.

The data shows most companies still haven’t achieved comprehensive test automation. That means the competitive advantage is available to teams willing to make the investment. Even imperfect progress beats no progress at all.