# No, QA is not your designated tester > No, QA is not your designated tester. “QA” is a process, not a role: its real job is to help the team grow. - Author: Mathieu Eveillard - Published: 2026-06-24 - Tags: Organization, Software craft - Canonical: https://www.mathieueveillard.com/articles/qa/ - Translation (fr): https://www.mathieueveillard.com/fr/articles/qa.md ![No, QA is not your designated tester](https://www.mathieueveillard.com/articles/2026-06-24-qa/qa.webp) QA running _some_ tests? Sure. QA running _all_ the tests? No! A QA is not there to perform the tests that developers don’t want to or don’t know how to do. Not at all, because every developer is responsible from start to finish for what they produce (“You break it, you fix it!” as a former prime minister would have aptly put it). This is, of course, a common misstep, but it is merely a reflection of a deeper organizational or competency issue. This organizational problem, which we will examine in more detail, ultimately results in a shift in terminology: **“QA” (Quality Assurance) is a process, not a role**. Going forward, however, I too will use “QA” to refer to the commonly observed usage. ## The Adverse Effects of the Division of Labor First of all, it is not always possible to separate testing from development. Test-Driven Development (TDD), by its very nature, uses tests to guide development. TDD, and this cannot be emphasized enough, is a development practice before it is a testing practice, with testing being a welcome byproduct. But TDD is just one practice among many, used primarily for developing the core domain, and there are, of course, [other types of tests](https://www.mathieueveillard.com/articles/50-shades-of-tests). In contrast, end-to-end tests are generally written once the application is functional—the “test-after” approach. Does this mean the developer can simply ignore them? No, because separating job roles (development and testing) in favor of greater specialization—Taylor’s beloved division of labor—significantly lengthens the feedback loop. Instead of detecting the error within a few hours at most, the division of labor extends this delay to several days, the time it takes for the tester to take over and familiarize themselves with the work done by their colleague. But it’s also, on an even deeper level, because **the system creates a natural incentive to introduce bugs**, with the unconscious reasoning being “I can let my guard down because someone else will check it after me.” In other words, [you can’t separate _doing_ from _doing it right_](https://www.mathieueveillard.com/articles/departement-qualite). ## Growing the Team Once again, the fact that a single person performs all the testing instead of the rest of the team (PM/analyst/designer, developer, etc.) is a symptom. The lack of automated regression tests is often the primary underlying cause of this situation. In the absence of regression tests in CI, every new feature requires manual verification to ensure there are no unintended side effects, across a scope made all the broader if the application is not properly [modularized](https://www.mathieueveillard.com/articles/priorite-modularite). Since the workload is immense and not limited to the work of a single developer, it is shared and assigned to QA. **The root cause here, therefore, is a problem with the developers’ expertise**. And this, in my view, is one of QA’s main jobs: rather than taking on this workload, it is QA’s responsibility to help the teams understand the problem and provide training. This is, essentially, the work of a coach, who must help the team grow. ## Pushing the application to its limits One of QA’s essential tasks is to push the application to its absolute limits. This can apply to performance, load tolerance, as well as security and accessibility. Again, these issues must be anticipated during the functional or technical design phase. Discovering them at the very end of the process is not normal. If, on the other hand, there is one thing that, by its very nature, is performed after development, since it already requires a usable product, it is exploratory testing. You might say that users do this very well, without necessarily being able to explain how they arrived at a particular dead end (monkey testing, anyone?), but the challenge for QA is to identify these inconsistent states early on, before the application goes into production. This exploration requires a thorough functional understanding of the application. **One must already be familiar with all of an application’s edge cases to be able to combine them and imagine new ones**. Some bugs are discovered by chance, of course, but even more numerous are those bugs whose existence we imagined and which experience has allowed us to verify. ## Working upstream with teams on functional design **It is best to anticipate these complex scenarios during the functional design phase, which is why QA should be an integral part of this work**. In this regard, [Example Mapping](https://www.mathieueveillard.com/articles/example-mapping) is the ideal practice, since the examples on which the functional design is based become acceptance tests once development is complete. Here again, I think it’s worth clarifying that the QA’s role is not to perform the acceptance tests that their colleagues are reluctant to do. These tests are, by definition, a contract between the developer and the PM, because they define the expected behavior of the application. How could I, as a developer, consider my work complete and submit it to the PM for review if I do not run these tests myself? As for the PM, how can he know if he has designed the right application increment if he does not run these tests himself (even a high-performing team will find about 5% of the behavior that needs to be modified)? As always, the misuse of words limits us. Thinking of “QA” as a role or, worse, as a job opening, doesn’t work, because “QA” is a process: acceptance tests are the team’s contracts, developers write other types of tests themselves, and exploratory testing should, in my view, be conducted jointly by the entire team, PM and Dev. So if a role with that name is still needed, it would be that of a coach.