Do We Test Just to Find Bugs?

In a world where testing is mainly test execution, it is reasonable to expect that when people test, they simply expect to find bugs. "We test to find bugs" is the answer given in job interviews. An answer repeated in onboarding materials, embedded in KPI frameworks, and implicitly assumed in every conversation about when software is ready to ship. It is so thoroughly taken for granted that questioning it sounds absurd, like questioning whether hammers are for hitting things.

Testing does find bugs since it involves test execution. But testing involves much more than execution. Framing testing as just a bug-finding activity results in a number of consequences that this article will discuss.

The History

To understand why the bug-finding framing is so persistent, it helps to understand where it came from. It did not emerge from careful thinking about what testing is for. It emerged from the early days of software development.

In the sequential, phase-gated models of software development that dominated from the 1960s through the 1990s, testing was a phase. It came after coding. Its purpose was to check whether what had been built worked as specified. The people who did it were called testers, and the outputs of their work were bug reports. The entire apparatus — the phase, the role, the output — was organized around the assumption that defects were artifacts to be found and removed, like impurities in a manufactured component.

This was a coherent model for its time and context. It mapped reasonably well onto hardware-adjacent software development. Change was expensive, requirements were relatively stable, and the cost of late discovery — while significant — was at least bounded by the pace of development cycles measured in months or years.

Then software development changed. It was all about speed of development. Cycles accelerated. Requirements destabilized. Systems grew interconnected. The gap between what could be specified in advance and what users actually needed widened dramatically. The contexts in which the bug-finding model made sense dissolved — but the model remained. It was too embedded in tooling, organizational structures, hiring practices, and professional identity to dissolve with them.

What remained was a model designed for a slow, sequential world, applied to a fast, iterative one. The phase became a sprint ceremony. The tester became a QA engineer. The bug report became a Jira ticket. The vocabulary updated. The underlying assumption, that testing is what you do to find defects in something already built, did not change, however.

Bug Finders in the SDLC

A bug may exist anywhere in the SDLC. A missing or ambiguous requirement. A design that fails to handle important scenarios. Incorrect or incomplete code. A flawed or missing test that allows defects to escape. A deployment or configuration error that causes the software to behave differently in production. So, in theory, bug finders could be employed all around the SDLC. But in practice, when testing is framed as bug finding it often becomes a late-stage filter. This determines what teams hire for, how they structure work, what they measure, how they explain incidents, and where they invest. It's not a minor detail!

When organizations test to find bugs, features are typically designed, developed, and code-reviewed. A hand-off model is employed whereby, when development is complete, the feature moves to the QA team. The QA team writes test cases based on the requirements document. They execute the tests. They find several bugs. The bugs are returned to the developers. The developers fix the bugs. The feature returns to QA for regression testing. It passes. It ships.

Under such settings, bugs are often exposed late, during the testing process after development. When information about a defect arrives late, decisions have already been made on the assumption that the defect does not exist. Those decisions must be revisited, revised, or lived with. The longer the latency, the more decisions have accumulated on a false foundation.

Hiring Bug Finders

One of the most direct and least-discussed consequences of the bug-finding framing is what it does to hiring. When an organization believes testing is about finding bugs, a good tester is a good bug-finder. But bug-finding, as a job description, selects for a specific and narrow set of skills. The typical bug-finding hire is technically literate but not technically deep. Comfortable at designing/executing test cases, skilled at documenting defects clearly, experienced with the tooling of defect tracking. These are real and useful skills, but they are a small snapshot of the value that testing can produce.

Testing requires the capacity to ask questions that have not been asked before. It requires understanding of system architecture, since you cannot generate useful information about a system that you do not understand. It requires risk reasoning — the ability to identify which regions of the system's behavior space carry the most consequence if they are wrong. It requires communication skills oriented not toward defect documentation but toward translating. Translating technical evidence into decisions that technical and non-technical stakeholders can act on. It requires curiosity: a genuine interest in what the system is actually doing, rather than in whether it matches an expected outcome.

Team Structures

Information about software behavior is generated — or should be generated — all around the SDLC. By developers writing unit and integration tests. By product owners reviewing acceptance criteria. By architects thinking through failure modes. By security engineers probing for vulnerabilities. By data analysts examining production telemetry. The bug-finding framing implicitly assigns all of this to testers. The team structures produced are almost universally recognizable, because they follow directly from the assumption that testing is a downstream, verification activity. This has major implications.

The Bottleneck Problem

When QA is the terminal stage before release, it becomes a bottleneck by construction. Development velocity is limited not by the rate at which developers can produce code but by the rate at which QA can process it. Organizations respond to this by automating testing and/or hiring more QA engineers, which increases throughput without addressing the underlying problem. In some cases, organizations have also reduced the time allocated to testing. This reduces thoroughness without anyone explicitly deciding to accept that risk.

The Ownership Problem

So, developers write code and testers verify that the code works OK. Does this imply that QA owns quality? Organizations that answer yes to this question open the door to other dangers. If testers own quality, then developers have a reduced incentive to ensure the correctness of their own work. After all, it's someone else's job. The empirical result is predictable and well-documented: defect rates increase when developers operate in an environment where defect detection is handled downstream.

The Adversarial Problem

In organizations where the hand-off model is combined with metrics that reward development velocity and measure QA performance by defect counts, a perverse incentive structure emerges. Development is rewarded for speed; QA is rewarded for finding bugs. The implicit incentives push these functions into an adversarial relationship — developers resenting QA for slowing release, QA resenting developers for producing buggy code. This adversarial dynamic is not a cultural problem. It is an incentive problem produced by a framing error.

The Release Process

The release process is where the framing becomes most visible. This is because the release process is the moment at which the organization is forced to answer the question: do we know enough to ship? The answer to that question is operationalized as: have we found enough bugs? The proxies are test execution rates, pass/fail ratios, open defect counts, and severity distributions. A release is approved when the open defect count is below a threshold, the regression suite passes, and the severity of known issues is judged acceptable. 

The assumption embedded in this process is that the tests have found the bugs, the bugs have been fixed, and what remains is known and manageable. This assumption, however, is almost never fully warranted. Experienced release managers know it. Every release approval is accompanied by a degree of unspoken uncertainty — a sense that the tests have probed what they have probed, and that what they have not probed remains unknown. This uncertainty is rarely made explicit, because the framework does not have a vocabulary for it. The question "what do we not know about this system's behavior?" often has no formal place in a release process organized around defect counts.

The question is not "have we found the bugs?" It is "have we generated sufficient evidence about the risks that matter most, and is the residual risk in the untested regions acceptable given what we know about this system's usage and consequences?" This is a harder question to answer, but it is the right question. It produces better decisions since it forces the organization to name its assumptions rather than hide them under a metric.

Incident Post-Mortems

When something breaks in production, the organization is forced to explain how it happened. Post-mortems tend to converge on a specific narrative: the defect was present but was not found by testing. The conclusions that follow are predictable — more tests, better coverage, improved test cases for this class of defect. Sometimes a retrospective guilt is attached to a specific test or test type that should have caught the issue.

Such a narrative can be dangerous for the cohesion of teams. It is also incomplete. It asks what the filter missed, when the right question is why the filter was the primary defense against this class of failure. It treats the absence of a specific test as the root cause. However, the actual root cause may be that the organization's testing model was structurally incapable of generating the information that would have prevented the incident. To put simply, why does testing only follow development?

 A few legitimate questions for post-mortems are:

• What information did we have about this region of the system's behavior before the incident?
• Why was that information insufficient — was it absent, was it present but not acted on, or was it structurally impossible to generate with the testing approach we were using?
• At what point in the SDLC was information about this failure mode accessible, and why did it not reach the people who could have acted on it?
• What does this incident tell us about the shape of our evidence — where are the gaps in what we know about our system's behavior?

These are different questions from "which test should have caught this." They produce different answers and different remediation paths. And they are more honest, because they acknowledge that the incident may not always be a failure of test execution. It was a failure of information generation at some point in the SDLC, and the post-mortem's job is to find that point.

The Blame Allocation Problem

When testers are bug-finders, there can be an uncomfortable dimension to post-mortems that deserves naming directly. When an incident occurs, the implicit question "who was supposed to find this bug?" resolves to the testers. This is expected given the framing. If testing is the activity by which bugs are found, and this bug was not found, then the people responsible for testing bear some responsibility for the failure. This is counterproductive since post-mortems should be blameless. The blamelessness in post-mortems is more important than how we frame our jobs, but most importantly, the two interact with each other. If you find that blaming is part of your post-mortems, then I suggest first identifying why. Why do you need blame in your post-mortems? As you walk through the path to get rid of it, if framing your jobs stands in the way, then a good idea is to rethink the fundamentals. Fundamentals like: What is quality? How do we develop our code? Why do we test? Who owns quality, and how do we learn in software products/projects? Try to get the wider picture possible.

Wrapping Up

The belief that testing finds bugs is a consequential framing error in software engineering. Not because it is false — testing does find bugs — but because it is so incomplete that organizing a quality program around it produces systematic, predictable, and expensive failures. 

Testing is much more than bug finding. Testing generates information about software behavior. That information is the raw material of every quality decision made in the SDLC. The earlier that information is generated, the cheaper it is to act on. The later it arrives, the more decisions have accumulated on a false foundation, and the higher the cost of correction.

After all, the answer to questions like "what is testing?" propagates through every dimension of how organizations work: who they hire, how they structure teams, what they measure, how they make release decisions, and how they explain incidents. Changing the framing is not a cosmetic exercise. It is a structural change that requires deliberate action at the level of process, metrics, and professional development.

If we frame testing as information generation and try to see the wider picture, for example, as in this article, then things could be different in many ways, as shown below.