Un día escuché a un dev senior proponer, sin ironía, tercerizar los unit tests al equipo de QA.
No era un mal ingeniero. Era alguien que había internalizado la lógica de su organización: si existe gente cuyo trabajo es testear, ¿para qué voy a testear yo?
La historia siempre empieza igual. Una startup crece. La cantidad de bugs aumenta. Alguien (generalmente un founder o un VP nuevo) mira lo que hacen las "empresas de verdad" y dice: "Necesitamos un equipo de QA."
Contratan algunos testers. Quizás un QA lead. Configuran workflows en Jira con columnas de "Ready for QA". Crean planes de testing.
Tres meses después, todo es más lento. Releases que antes salían en un día ahora tardan una semana. Y empieza el ping-pong: dev termina feature, QA encuentra bug, dev lo arregla, QA encuentra otro bug, dev lo arregla, QA encuentra una regresión del primer fix. Y así sucesivamente hasta que alguien decide que está "suficientemente bien" y lo pasa de columna.
Nadie está más contento. Ni los developers. Ni los testers. Ni los clientes.
La realidad: probablemente no había un problema de calidad. Había un problema de proceso. Y acaba de empeorar.
El modelo que estás copiando ya no existe
Existe esta suposición de que las empresas tech exitosas tienen ejércitos de testers. Que si querés jugar en las grandes ligas, necesitás QA dedicado.
Microsoft fue pionero con el rol de SDET (Software Development Engineer in Test) en los 90s. Era su marca registrada. Tenían una proporción de 2:1 de developers a SDETs. Miles de ingenieros dedicados exclusivamente a testing.
En 2014, lo eliminaron.
Tiraron a la basura decenas de miles de tests escritos por el equipo de testing. Reconstruyeron su pirámide de tests desde cero. ¿El resultado? Mejoraron la calidad, la velocidad y la satisfacción de los ingenieros, todo al mismo tiempo. Gergely Orosz, que vivió la transición, lo describe así: "El equipo de Skype for Web se volvió mucho más productivo al eliminar el rol de SDET."
¿Por qué funcionó? Porque el rol de testing separado creaba demoras incompatibles con el delivery continuo. El modelo que había funcionado para releases anuales se convirtió en un cuello de botella.
Y no es solo Microsoft. Uber, Netflix y Meta nunca tuvieron roles dedicados de QA para equipos de software. En Google, los ingenieros son dueños de su propia calidad; tienen una org de EngProd que construye infraestructura de testing, pero el testing es responsabilidad de la gente que escribe el código.
Las únicas Big Tech que mantienen QA dedicado son Apple y Amazon, principalmente para productos de hardware o ciclos de release lentos. No software.
Cuando tu startup contrata un equipo de QA porque "eso es lo que hacen las grandes empresas," estás copiando un modelo que las empresas que admirás abandonaron hace una década.
La pared invisible
El QA separado crea una división entre la gente que construye y la gente que verifica. Suena razonable. Checks and balances. Ojos frescos sobre el código.
En la práctica, crea incentivos perversos.
Los developers empiezan a pensar que la calidad es problema de otro. ¿Para qué escribir tests exhaustivos si QA va a encontrar los bugs de todas formas? ¿Para qué testear edge cases cuando literalmente para eso les pagan a los testers? ¿Para qué preocuparse por la experiencia del usuario cuando te miden por tickets cerrados, no por satisfacción del cliente?
Y así es como terminás con un dev senior proponiendo tercerizar los unit tests. Porque en las organizaciones donde se separa construir de testear, testear se convierte en una actividad de menor status. Algo que hace "otra gente."
Pero hay un problema más profundo que los incentivos: el timing del feedback.
Will Larson tiene un framework útil para pensar sobre calidad. El insight clave es la diferencia entre medir calidad y crear calidad. Los errores detectados después del handoff de desarrollo miden calidad. Te dicen que algo salió mal. No previenen que vuelva a pasar.
Peor aún: cuanto más tarde encontrás los problemas, más probable es que obtengas fixes tácticos en lugar de fixes estructurales. Un bug encontrado en QA se parchea. Un bug prevenido durante el diseño se "diseña fuera de existencia" —lo que John Ousterhout describe como hacer que estados ilegales sean irrepresentables, diseñando interfaces que no se puedan usar mal, atrapando problemas en tiempo de compilación en lugar de runtime.
Esto requiere pensamiento en tiempo de diseño. No puede pasar después de que ya construiste la cosa.
Cuando los developers son dueños del testing, el loop es local. Escribís código, escribís test, lo ves fallar, lo arreglás, lo ves pasar. Feedback inmediato. El problema y la solución viven en el mismo cerebro.
Cuando los testers son dueños del testing, el loop se rompe. El problema vive en un cerebro, la solución en otro. Para cuando el ticket vuelve, el developer ya hizo context-switch a otras tres features.
El ping-pong de tickets no es un proceso de calidad. Es teatro.
Y llegó la IA
Hay otro factor que hace que el QA dedicado sea aún más difícil de justificar: los asistentes IA para codear están haciendo que los developers sean dramáticamente mejores en testing.
Herramientas como Cursor y Claude Code no solo escriben código. Generan tests. Pediles que agreguen tests a código existente, e identifican edge cases que no habías considerado.
Esto cambia los economics. El argumento principal para QA dedicado siempre fue que los developers son demasiado caros para gastar tiempo en testing. Pero cuando una IA puede armar tu suite de tests en minutos, ese argumento se cae. El developer revisa y refina, pero el boilerplate se automatiza.
Hay un catch: la IA te lleva el 80% del camino. El último 20% —los edge cases sutiles, el hardening para producción— todavía requiere juicio humano. Y los ingenieros senior se benefician más precisamente porque saben qué buscar. Pueden detectar cuando el test generado por IA está testeando lo incorrecto, o faltando un escenario crítico.
La IA no reemplaza el pensamiento de calidad. Lo amplifica. Y lo amplifica más para la gente más cercana al código.
Lo que realmente funciona
Luca Rossi en Refactoring lo resume bien: QA es un mindset, no un rol. Se trata de saber qué realmente importa y qué no.
Los mejores equipos que conozco no tienen QA dedicado. En cambio, tienen:
Ingenieros que son dueños de la calidad. La misma persona que escribe el código escribe los tests. No tirás tu código para el otro lado de la cerca. Lo shippeás, lo monitoreás, lo arreglás cuando se rompe.
Una política de cero defectos. Los bugs se arreglan rápido, incluso los de baja prioridad. Es la teoría de las ventanas rotas aplicada al código: un bug sin arreglar señala que los bugs son aceptables, lo que invita más bugs. Mantener el contador en cero hace que los bugs nuevos sean obvios.
Buen testing de integración. Los tests de integración entregan mejor ROI que los tests end-to-end. Son más fáciles de escribir, más fáciles de mantener, y atrapan la mayoría de los problemas que importan. Guillermo Rauch lo resume: "Escribí tests. No demasiados. Mayormente integración."
Testing en producción con buena observabilidad. Charity Majors:
"Testear en producción es un superpoder. Es nuestra incapacidad de reconocer que lo estamos haciendo, y luego invertir en el tooling para hacerlo de forma segura, lo que nos está matando."
Su punto: una vez que desplegás, ya no estás testeando código; estás testeando sistemas. Sistemas complejos con interacciones impredecibles que desafían tu capacidad de testear de forma determinista. La única forma de saber si tu código funciona es mirarlo funcionar.
Ownership distribuido. En todas las empresas en las que trabajé promoví el dogfooding: PMs y EMs stress-testeaban los builds tempranos. Soporte al cliente canalizaba feedback. Las métricas de negocio se monitoreaban en tiempo real. Todos se preocupan más por la calidad cuando no es "el trabajo de otro."
Cuándo sí tiene sentido
No estoy diciendo que los equipos de QA siempre estén mal. Tienen sentido en contextos específicos:
- Industrias reguladas. Healthcare, aviación, automotriz —donde los bugs causan violaciones de compliance o daño físico.
- Core banking e infraestructura de pagos. Sistemas que mueven dinero directamente entre cuentas, no apps fintech que se sientan arriba de Stripe o Mercado Pago.
- Hardware. Donde no podés pushear un update después de que el dispositivo se envía.
- Ciclos de release lentos. Si los releases son trimestrales o anuales, una fase de QA es menos costosa.
- Codebases legacy sin tests. Si heredaste un desastre, QA dedicado puede ser necesario mientras salís del pozo.
Notá lo que no está en la lista: startups en busca de product market fit.
Pre-product-market-fit, tu producto cambia constantemente. Los tests se convierten en un pasivo. No estás optimizando un sistema existente —estás descubriendo lo que el sistema debería ser. Luca Rossi:
"Muy poco QA debería existir en este momento. Los E2Es te van a frenar porque tu producto cambia demasiado rápido."
Ya tengo un equipo de QA. ¿Y ahora?
Redistribuilo.
Cuando Microsoft mató el rol de SDET, no despidió a todos sus testers. Los transicionó a roles de ingeniería. Y pasó algo interesante: esos ex-SDETs se convirtieron en ingenieros inusualmente efectivos. La gente que pasó años rompiendo software piensa diferente que la gente que pasó años construyéndolo. Ven los modos de falla. Anticipan los comportamientos raros de usuarios. Saben dónde se esconden los bugs.
Donde pueden agregar valor sin ser una función separada:
- Infraestructura de testing. Pipelines de CI/CD, tooling de automatización, lo que Google llama EngProd.
- Desarrollo de features con lente de calidad. Embedidos en equipos, escribiendo código de producción y tests.
- Observabilidad. Instrumentando sistemas, construyendo dashboards.
- Release engineering. Pipelines de deployment, feature flags, canary releases.
El objetivo no es eliminar a la gente enfocada en calidad. Es eliminar la pared entre construir y verificar.
Las preguntas correctas
En lugar de "¿Necesitamos un equipo de QA?", preguntá "¿Por qué tenemos tantos bugs?"
¿Los developers no tienen tiempo para testear? Arreglá el sprint planning.
¿No saben cómo testear? Invertí en capacitación y tooling.
¿El codebase es tan frágil que los cambios rompen cosas de manera impredecible? Arreglá la arquitectura.
¿Nadie es dueño de la calidad? Cambiá la cultura.
Contratar QA es usualmente la solución más cara para el problema —tanto en costos directos como en los costos ocultos de feedback loops más lentos.
Hay una historia famosa de Art & Fear sobre un profesor de cerámica que dividió su clase en dos grupos. Uno sería evaluado por la cantidad de vasijas producidas. El otro por la calidad de una sola vasija.
Al final del semestre, ¿qué grupo produjo el trabajo de mayor calidad?
El de cantidad.
Mientras estaban ocupados produciendo vasijas y aprendiendo de sus errores, el grupo de calidad se sentó a teorizar sobre la perfección y terminó con poco más que teorías grandiosas y un montón de arcilla muerta.
El software funciona igual. Shippea más. Aprende más rápido.
