Una startup está creciendo. 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. Los devs revolean features por encima de la cerca y se olvidan. Los testers encuentran bugs, los developers los arreglan, los testers encuentran más bugs. El ping-pong de tickets se convierte en un deporte de tiempo completo.
Y nadie está más contento. Ni los developers. Ni los testers. Ni los clientes.
La realidad suele ser la siguiente: probablemente no había un problema de calidad. Habia un problema de proceso. Y acaba de empeorar.
Lo que realmente hacen las Big Tech
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.
Los datos dicen otra cosa.
Microsoft fue pionero con el rol de SDET (Software Development Engineer in Test) en los 90s. Tenían una proporción de 2:1 de developers a SDETs. Era su marca registrada.
En 2014, lo eliminaron.
¿Por qué? Porque cuando los equipos empezaron a deployar diariamente, un rol de testing separado creaba demoras incompatibles con la entrega continua. Gergely Orosz describe la transición:
"El equipo de Skype for Web se volvió mucho más productivo al eliminar el rol de SDET."
Tiraron a la basura decenas de miles de tests escritos por el equipo de testing. Reconstruyeron su pirámide de tests. Y mejoraron la calidad, la velocidad y la satisfacción de los ingenieros, todo al mismo tiempo.
¿Uber y Netflix? Nunca tuvieron roles dedicados de QA para equipos de software.
¿Meta? Sin función dedicada de QA para equipos de software puro.
¿Google? Los ingenieros son dueños de su propia calidad. Tienen una org de EngProd que construye infraestructura de testing, pero el testing en sí 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.
Por lo cual 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 ya abandonaron.
Nosotros vs. Ellos
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.
Pero, en la práctica, crea incentivos horribles.
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?
Escuché devs proponiendo "tercerizar" los unit tests al equipo de QA, porque en las organizaciones en donde se separa construir de testear, testear se convierte en una actividad de menor status.
Y todos hemos visto el ping-pong de tickets: 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 se repite ad-nauseam hasta que alguien decide que está "suficientemente bien" y lo pasa de columna.
Esto no es un proceso de calidad. Es teatro de calidad.
El Feedback Loop
Will Larson tiene un muy buen framework para pensar sobre calidad. El insight es la diferencia entre medir calidad y crear calidad.
Errores detectados después del handoff de desarrollo miden calidad. Te dicen que algo salió mal. No previenen que vuelva a pasar.
Peor: 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 corrige. Un bug prevenido durante el diseño se "diseña fuera de existencia".
John Ousterhout define a los "errores fuera de existencia" a hacer que estados ilegales sean irrepresentables. Diseñar interfaces que no se puedan usar mal, atrapar 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, se crea un loop local mucho más ajustado. 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, tenés un paso distinto. Feedback demorado. El problema vive en un cerebro, la solución en otro. Para cuando vuelve el fix, el developer ya hizo context-switch a otras tres features.
El feedback loop no es solo más lento. Es fundamentalmente inefectivo.
QA es un mindset, no un rol
Luca Rossi en Refactoring tiene un framework simple: QA es un mindset, no un rol. Se trata de asegurar que cumplís una expectativa de calidad: saber qué realmente importa y qué no.
Y crucialmente, el ROI del testing cambia según la etapa de tu producto.
Pre-product-market-fit, tu producto cambia constantemente. Los tests se convierten en un pasivo en lugar de un activo. No estás optimizando un sistema existente — estás descubriendo lo que el sistema debería ser. Cada test que escribís puede necesitar reescribirse la semana que viene cuando pivotees.
"Muy poco QA debería existir en este momento. Los E2Es te van a frenar porque tu producto cambia demasiado rápido."
El research de DORA lo respalda. Los performers de élite hacen múltiples deploys on-demand por día. Lead time para cambios: menos de un día. No llegás ahí con una columna de "Ready for QA".
Y llegó la IA
Y ahora 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 con calidad productiva. 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 trabajo pesado (el boilerplate, los casos obvios, las assertions repetitivas) se automatiza.
Hay un catch, though: la IA te lleva el 80% del camino. El último 20% (los edge cases, el manejo de errores, el hardening para producción) todavía requiere juicio humano. Y los ingenieros senior se benefician más de las herramientas de IA 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
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. Testear es inseparable de construir. 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. Tener pocos o ningún defecto hace que el testing sea más confiable y la moral mejor. También hace que los bugs nuevos sean más fáciles de detectar.
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. Citando a Guillermo Rauch (compatriota argentino, fundador de Vercel, y la mente detrás de Next.js y v0): "Escribí tests. No demasiados. Mayormente integración."
Buena observabilidad + testing en prod. Charity Majors, una de las voces más fuertes en observabilidad:
"Testear en producción es un superpoder. Es nuestra incapacidad de reconocer que lo estamos haciendo, y luego invertir en el tooling y el entrenamiento para hacerlo de forma segura, lo que nos está matando."
Su punto: una vez que deployás, ya no estás testeando código; estás testeando sistemas. Sistemas complejos hechos de usuarios, código, ambiente, infraestructura y un punto en el tiempo. Estos sistemas tienen 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.
Esto requiere un cambio cultural. Los ingenieros deberían estar de guardia por su código, mirando su instrumentación mientras despliegan. Los managers necesitan hablar el lenguaje de error budgets y SLOs, ser orientados a resultados en lugar de a tolerancia cero. La resiliencia de un sistema no se define por su falta de errores — se define por su capacidad de sobrevivirlos.
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 preocupaban más por la calidad cuando no era "el trabajo de otro."
Cuándo tiene sentido
Ojo, no me malinterpreten. No estoy diciendo que los equipos de QA siempre estén mal. Tienen sentido en contextos específicos:
- Industrias altamente 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. Si tu proveedor de pagos maneja las partes sensibles, tus bugs causan mala UX, no pérdidas financieras.
- Productos de hardware. Donde no podés pushear un update después de que el dispositivo se envía.
- Ciclos de release lentos. Si los ciclos de release son trimestrales o anuales, una fase de QA es menos costosa.
- Codebases legacy con poco testing automatizado. Si heredaste un desastre sin tests, QA dedicado puede ser necesario mientras salís del pozo.
Notá lo que no está en la lista: startups tratando de encontrar product-market fit.
Ok, pero ya tengo un equipo de QA
Quizás estás leyendo esto pensando: "Genial, pero ya contraté QA. ¿Y ahora qué?"
Redistribuilos.
Cuando Microsoft mató el rol de SDET en 2014, no despidió a todos sus testers. Los transicionó a roles de ingeniería de software. Y pasó algo interesante: esos ex-SDETs se convirtieron en ingenieros inusualmente efectivos.
Gergely describe a los ex-SDETs como muy buenos señalando edge cases. Esto es un superpoder. 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.
Acá es donde la gente de QA puede agregar valor sin ser una función separada:
- Infraestructura de testing y trabajo de plataforma. Construir pipelines de CI/CD, tooling de automatización, lo que Google llama EngProd y Meta llama DevInfra.
- Desarrollo de features con lente de calidad. Embedidos en equipos de producto, escribiendo código de producción y tests.
- Observabilidad y monitoreo de producción. Instrumentando sistemas y 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. Cuando tus mejores "quality thinkers" están embedidos en los equipos que generan el código — no haciendo de gatekeepers después del hecho — todos mejoran.
Las preguntas correctas
En lugar de "¿Necesitamos un equipo de QA?", preguntá: "¿Por qué tenemos tantos bugs?"
¿Es porque los developers no tienen tiempo para testear? Arreglá el sprint planning.
¿Es porque los developers no saben cómo testear? Invertí en capacitación y tooling.
¿Es porque el codebase es tan frágil que los cambios rompen cosas de manera impredecible? Arreglá la arquitectura.
¿Es porque 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.
Las empresas que hacen delivery más rápido con la más alta calidad no separan construir de testear. Los integran tan fuertemente que no podés distinguir dónde termina uno y empieza el otro.
No es un proceso. Es un mindset.
Hay una historia famosa de Art & Fear sobre un profesor de cerámica que dividió su clase en dos: un grupo sería evaluado por la cantidad de vasijas producidas, el otro por la calidad. Al final del semestre, ¿Qué grupo crees que 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. La calidad viene sola.
