What happens when developers are responsible for testing

Startups, M&A-ed businesses, or high-growth companies typically look to cut costs. That’s okay. But sometimes, they cut them by choosing not to build a dedicated QA function. That’s also okay, but only if decision-makers understand the consequences. 

Their reasoning is usually straightforward: developers already understand the codebase, they’re writing the features, so they can validate them too. They already see lower headcount costs and fewer handoffs.

However, there is no single established standard for team counting and RACI modeling. Industry has been using the 1:3 ratio principle for years, now decreasing to 1:5 and below. Katalon found out that only 36% of teams are sure they have a positive ROI from their testing approach.  

Teams that try to rely entirely on developer testing often rebuild a dedicated QA function a year or two later.

On the other hand, we can’t help but agree: developers do catch a large number of defects through code review, unit testing, and general awareness of what they just changed. The problem isn’t that developers test badly. It’s more like a structural problem: testing your own code carries inherent limitations that don’t disappear with skill or good intentions.

There is a common bias: developers and testers are more likely to choose positive tests (the ones that verify their hypotheses) rather than negative tests designed to break their assumptions. 

That is, the person who built a feature is the least likely person to find its edge cases. So what actually happens when developers become the only quality gate?

We discuss this and its impact on the QA strategy in this article.

Developers catch issues earlier

Market stakes are another reason why so many companies rely on developer-led testing. Founders think that no one knows the code better than the developer who actually wrote it. And high-risk markets only fuel this belief.

But there is also an indisputable thing: bugs found during development are significantly cheaper and faster to fix than bugs found later.

From this angle, developer participation in software testing is beneficial a priori. When a developer is writing a feature, the code is fresh in their memory, and they can cover the design decisions, the data flow, the edge cases, and many other technical aspects. 

Four noticeable developer testing features

1. Catches integration regressions early: Once again, devs can catch service-level failures at the point of introduction, not when the release is on fire on app stores.
2. Validates logic at the source: Unit tests confirm that individual functions behave correctly across the inputs they were designed to handle.
3. Ensures safe refactoring: A developer who changes an implementation detail has immediate confidence that the behavior remains correct if existing tests still pass.
4. Iterates faster: At least, it’s supposed to. Write code, run tests, see results in seconds — ideally, developers are meant to move quickly without accumulating unknown breakage.

Developer testing works best as an early-stage quality layer within a broader testing strategy. 

Developers focus primarily on functionality

One of the most significant caveats in this topic — perspective. 

If we believe that successful testing is matching a test suite with “how a specific feature is supposed to work”, then developer testing is the best approach.

From another perspective, that creates a systematic gap. Research on confirmation bias in software testing found that developers and testers are more likely to design tests that verify their own hypotheses rather than refute them. 

In the industry, we call it a happy-path coverage. Here’s an example — what are the most obvious validation points in a checkout flow? Chances are, they are:

• The app must check if the card details are valid
• If the payment is successful, the user must get an order confirmation page
• The system must create a new database record

But what happens when the user double-clicks the submit button or leaves the session open for 40 minutes and then completes payment — these unusual paths are not that obvious. Even if the developer has covered the mentioned ones, there are endless scenarios to happen, and a third-party perspective can come in handy.

Three gaps your team may encounter with a developer-led QA strategy 

1. Error states and recovery paths: Failed API calls, partial form submissions, timeout errors mid-flow exist in every application and still need to be tested. It goes without saying, but that doesn’t make it any less painful. These states often go untested, whether due to a lack of time or an inexperienced developer (or any other reason).
2. Cross-feature interactions: Again, a lack of time forces programmers to cut corners — they may choose not to test how their change interacts with features built by other engineers, particularly those modified in other sprints.
3. User mental models vs. design intent: A developer understands the intended flow because they built it. Users don’t read the documentation; they navigate by instinct, try things in unexpected order, and use features in ways the design never anticipated. 

So once again, it is important to understand: under an upcoming deadline, developers and testers are even more likely to default to positive testing and skip disconfirmatory threads. 

Complex user workflows often remain under-tested

Unit tests cover functions. Integration tests cover service boundaries. A real user’s actions in your product is what actually moves the needle. Especially, if you’re entering a foreign market — you can simply overlook important interpretations that form users’ behavior.  

Three gaps examples in a QA process

1. Multi-step user journeys: Let’s count: the user signs up, verifies their email, completes a profile, selects a plan, enters payment details, and lands on a dashboard. Six steps. It can be fewer, but typically, this flow has at least three. Each step involves different components, different state transitions, and different failure modes. A developer writing unit tests for the payment module verifies that the module correctly handles card input. Given the limited time and specific priorities, the developer may skip writing tests that validate what happens when a user completes step four, closes the browser, reopens it two hours later, and tries to resume, or what happens when the email verification link expires mid-flow.

2. System integrations: SaaS products depend on external services, and the interactions between these systems produce a category of failures that component-level testing just can’t reach. An order confirmation flow might work perfectly in unit and integration tests and fail in production because the email provider returns a rate-limit error that the app doesn’t handle. To find that failure, you have to test the complete flow under realistic conditions — that is, become your customer for a while.

3. Unexpected user behavior: Humans are irrational. There is no way users will act as you predict. At least, not always. They paste content into fields that expect typed-only input. They navigate backwards through flows that assumed forward progress. They submit forms multiple times when a page loads slowly. They arrive at a checkout screen via a shared link rather than the navigation path you assumed they’d use.

One of the most effective ways to handle these is a so-called stranger mindset. In our case, it means letting someone who is in the dark about your software building process observe your app without prejudices.

Developers already have heavy workloads

Adding end-to-end testing to a developer’s workload is overkill. You either have to pay such employees way more or rethink your tech team structure.

Stack Overflow found that 37.5% of developers find non-development work the greatest distraction from the work they’ve been hired for. Just imagine, it’s almost like meetings!

Jokes aside, research on interruptions in software development found that frequent context switching leads directly to mental fatigue, and hence, potentially more bugs. Even though the research was conducted in 2010, not that much has changed — developers, as most humans, struggle to regain cognitive context after each interruption. 

As a tech leader, you should understand that this may have consequences — lengthy pauses and unproductive work increase technical debt.

What the impact on software quality is

A developer is mid-way through implementing a complex feature when a production bug comes in that needs immediate attention. They context-switch to debug, fix, and deploy the patch. Then a tech lead is like: “I got a minute. Let’s quickly plan our next 3 sprints before I go on my vacation”.

By the time the dev returns to the feature, the testing that was supposed to happen before the PR gets a cursory pass rather than thorough coverage.

Quality strategy requires specialized expertise

Testing and writing tests are not the same thing: the first action is focused on a specific behavior a dev just implemented, the second is about a different question: given how this product is built and how it’s used, where are the highest-risk failure points?

That difference in orientation is the core of what a dedicated QA function provides.

Four core pillars, a strong QA process inevitably involves

1. Ruthless prioritization: A payment flow mandates exhaustive coverage of error states, currency edge cases, and retry behavior. This is how you earn money. A preference settings page needs far less. And where to invest the team’s limited time is the manager’s wisdom and the cost of failure in each area.  
2. Risk identification: QA engineers know that the third-party shipping integration has a history of edge case failures, that the user permission model has subtle behavior under concurrent sessions, and many other potential pitfalls — just because they are focused on that. Apart from informing the dev team which scenarios to prioritize, they suggest specific scenarios for test automation. And that’s already a direct business impact as they cut costs.
3. Designing tests that actually find bugs: Different people bring different assumptions about how the software should behave. Diversification works here as well.
4. Coverage decisions over time: Dedicated QA specialists help adjust the coverage strategy to the product’s growth. New features add new risk areas, and you have to go through the described flow above once again. Ideally, faster and smoother than before.

This is why combining QA and development expertise is the fastest way to improve software quality: developers validate their own builds through unit and integration tests, and QA engineers own the strategy, the end-to-end coverage, and the test suite as a dynamic system.

Testing can become inconsistent without a separate QA function

No clear ownership — coverage reflects individual judgment rather than a comprehensive and expert-driven approach. And the problem here isn’t even that nobody tracks areas that haven’t been touched (because someone does, or at least, has to). The problem is an unsystematic practice.

How inconsistency plays out 

• Regression coverage depends on which developer is reviewing a PR
• The coverage largely depends on the free time and the cognitive focus of a specific developer
• Q1/Q2/Qx review shows that many features were just “happy pathed”, without in-depth testing
• Integration points get tested less than individual components
• No one maintains a picture of overall coverage, no consistent documentation and single source of truth for legacy

The most dangerous is the gap between what’s tested and what’s in production. Many teams discover that gap through users’ bug reports.

CrowdStrike outage as an example

CrowdStrike’s Post Incident Review confirmed that the July 2024 Falcon update failure stemmed directly from a gap in its validation and testing process. Sensor Content underwent automated unit testing, integration testing, performance testing, stress testing, and staged rollout before release. 

Rapid Response Content, by contrast, didn’t go through the same test coverage. The update was deployed globally without a staged rollout, and a bug in the Content Validator skipped a flawed configuration file to production.

8.5 million Windows systems went down. Insurers estimated the outage cost for US Fortune 500 companies to be USD 5.4 bn. 

Note: Not a security breach, nor an architecture problem. It was a gap in automated testing: different update types received different levels of validation, and one category was deployed without the standard safeguards.

The best teams combine developers and QA engineers

At this moment of the blog, what do you think — is developer testing alone sufficient?

We’re not about to sell hype to you — sometimes, it is. But for most SMEs and even more for enterprises, it has never been sufficient.

The most effective model combines the expertise of both.

How to distribute software testing

How and where automation supports both

At the intersection. 

Developers write unit and integration tests, and the automated testing tool runs them with every changeset. QA-designed end-to-end tests run before deployment. The tool shares the results of the CI pipeline with both teams right after completion. 

While automation doesn’t replace QA judgment, it frees both parties from the repetitive routine and gives time for what really matters: coverage decisions, edge case design, triage, quality strategy, and so on.

Owlity ensures this by recording real user flows and converting them into automated tests. This removes the scripting overhead from the QA team and keeps coverage aligned with how the product is actually used.

Supporting testing when QA resources are limited

Hiring a senior automation engineer takes month(s). Onboarding and first valuable outputs take even more. Or if your product takes the market by storm, and the user base scales rapidly. So the deadline pressure never ends.

Modern test automation platforms cover some of these blockers. 

Record real user flows and convert them into automated tests 

Low entry level — a product manager or a junior tester can record any flow needed in minutes

Expand test suites, build out scenario variations, and identify what’s being missed with advanced features

All these remove the dependency on scripting expertise for initial coverage. But if you need to go through a genuine change in your QA strategy, consider experienced consultants or outsourcing pros. 

Owlity lowers the barrier enough that teams don’t have to choose between shipping and testing.