La distinción ordena esta pregunta, pero no la contesta sola. Acá está la teoría; la recomendación concreta la hace cada página de nivel de madurez.
Los escriben los desarrolladores. DORA lo tiene como capacidad medida:
"when developers are primarily responsible for creating and maintaining suites of automated tests... this drives improved performance"
Y nombra los dos modos de falla cuando un equipo separado es dueño de la automatización:
"If developers are not responsible for test automation, the build pipeline stays broken until the responsible team fixes the tests."
"Developers tend to solve the problem they are given without thinking about how it will be tested. This can lead to poorly designed code and expensive, hard-to-maintain test suites."
El segundo argumento es el que se pasa por alto: no es solo flujo, es diseño. La testabilidad es una propiedad del diseño del código, y solo la cuida quien paga el costo de no tenerla.
Kent Beck lo ubica en el mismo lugar cuando habla de programmer testing. Birgitta Böckeler también: "the minimum I want to still care about and be on top of is the test code". Y XP lo tiene desde los noventa con propiedad colectiva del código y tests primero.
Esto es importante y suele enunciarse mal.
Bolton y Bach no dicen que el testing sea del QA. No asignan por rol en ninguna parte. Y hay una señal más fuerte: un artículo de Bolton de 2025 se titula "Checking is Inside Testing". Para ellos el checking es una táctica dentro del testing, no una actividad hermana que se pueda repartir entre dos personas.
DORA sí menciona el rol que continúa: "Testers and QA teams continue to have an important role in this way of working", vía testing exploratorio, de usabilidad y curaduría de la suite. Pero en la misma recomendación pide emparejar testers con desarrolladores para "learn from each other and solve problems in real time", que es lo contrario de una división limpia.
Modern Testing, de Alan Page y Brent Jensen, va en otra dirección todavía. Su principio 7 dice expandir la capacidad de testing a todo el equipo "understanding that this may reduce (or eliminate) the need for a dedicated testing specialist". No es "el QA hace testing": es "quizás no hace falta un QA dedicado".
Y su principio 3 es la mejor formulación del cambio de función: el QA es "a force for continuous improvement, helping the team adapt and optimize in order to succeed, rather than providing a safety net to catch failures".
El principio 4 de Modern Testing describe el destino del rol:
"We care deeply about the quality culture of our team, and we coach, lead, and nurture the team towards a more mature quality culture."
Es decir: el QA deja de hacer QA y pasa a lograr que el equipo lo haga, acompañando que entiendan los paradigmas en juego y reforzándolos de forma incremental.