Cada tanto un founder me pregunta si debería contratar un equipo de QA. La última vez fue una startup cuyos equipos venían de una consultora: un equipo de backend, uno de frontend y uno de QA. Tenían regresiones todo el tiempo y en las llamadas el aire se cortaba con cuchillo. No porque los ingenieros fueran malos, sino porque los founders presionaban constantemente con deadlines y cambiaban de dirección una y otra vez, sin ningún tipo de espacio para limpiar, meter mejores abstracciones o pagar deuda técnica.
La propuesta de la consultora fue vender más QAs (además de los que ya escribían tests de integración y hacían QA manual) para escribir los unit tests que el equipo de desarrollo no tenía tiempo de hacer.
Vi dinámicas parecidas mil veces, pero cuando alguien intenta tercerizar los unit tests me resulta muy difícil no imaginarme el meme de los Simpsons de "pues cavando".
Esa startup es un caso extremo, pero el razonamiento que los llevó hasta ahí es súper común. Una startup crece, aumentan los bugs, y alguien (generalmente un founder, o un VP recién llegado de una empresa más grande) mira lo que hacen las "empresas de verdad" y concluye que necesitan un equipo de QA. Contratan algunos testers, quizás un QA lead, agregan una columna de "Ready for QA" al tablero. Tres meses después, los releases que antes salían en días tardan semanas, y la frustración sigue creciendo.
La mayoría de las veces el problema no es primariamente de calidad, y el equipo de QA nuevo lo acaba de empeorar.
El círculo vicioso
Hace años trabajé en una startup que tenía un equipo de QA dedicado muy bueno: se enorgullecían de descubrir edge cases que al equipo de desarrollo ni se le habían ocurrido, y de ser súper minuciosos con su proceso de testing.
Aprobar un release les llevaba semanas, lo que hacía el feedback loop cada vez más lento. Inevitablemente los equipos de ingeniería y producto contraatacaban metiendo más items en cada release, lo que hacía el testing todavía más lento, y encontrar el código que rompía algo todavía más difícil por los batches de trabajo más grandes. Lo que, obviamente, "demostraba" que necesitábamos aún más QA, y releases aún más lentos.
Y lo peor es que nadie estaba haciendo mal su laburo: los testers eran minuciosos, los developers trataban de shippear, y el loop de decadencia se seguía auto alimentando.
El QA separado hace algo más: los developers dejan de sentirse responsables por la calidad. ¿Para qué testear edge cases si literalmente para eso les pagan a los testers? ¿Para qué escribir tests exhaustivos si QA va a encontrar los bugs igual? Testear se convierte en trabajo de menor status, eso que tirás por encima de la pared para que alguien más se ocupe. Si se sigue esa lógica lo suficiente, se llega a mi cliente, donde los developers ya ni siquiera eran dueños de sus unit tests.
Mientras tanto, los tickets van y vienen: dev termina una feature, QA encuentra un bug, dev lo arregla, QA encuentra otro, el fix rompe algo de hace dos semanas, y sigue así hasta que alguien decide que está "suficientemente bien" y lo shippean igual.
También hay un costo que no aparece en ningún ticket. Cuando escribís el código y los tests, el problema y la solución viven en el mismo cerebro, y el loop entero (escribir, testear, fallar, arreglar) te lleva minutos. Cuando el reporte del bug te llega de otro equipo días después, ya estás metido en otra cosa, así que lo parcheás con el mínimo esfuerzo y seguís. Diametralmente opuesto a atrapar el problema mientras todavía estás diseñando, cuando todavía podés "definir el error fuera de existencia", como dice John Ousterhout.
Lo que las Big Tech hacen en realidad
Existe esta idea 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 pionera del rol de SDET (Software Development Engineer in Test) en los 90s y mantenía una proporción de 2:1 entre developers y SDETs. Era su marca registrada. En 2014 lo eliminaron, porque los equipos que shippeaban todos los días no podían esperar a un rol de testing separado. Gergely Orosz dice:
"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 viejos del equipo de testing, reconstruyeron la pirámide de tests, y terminaron mejorando calidad, velocidad y satisfacción de los ingenieros, todo junto. Tampoco echaron a sus testers: los ex-SDETs pasaron a roles de ingeniería y resultaron ser inusualmente buenos, con un olfato especial para los edge cases. (Si ya tenés gente de QA: redeployalos.)
Uber y Netflix nunca tuvieron roles dedicados de QA para sus equipos de software, y Meta tampoco. Google tiene una org de EngProd que construye infraestructura de testing, pero el testing lo hacen los ingenieros que escriben el código. Los que siguen aferrados al QA dedicado son Apple y Amazon, principalmente por hardware y ciclos de release lentos. Así que cuando una startup contrata un equipo de QA porque "eso es lo que hacen las empresas serias", está copiando un modelo que las empresas que admira ya abandonaron.
QA es un mindset
Luca Rossi dice que QA es un mindset, no un rol. Estoy 100% de acuerdo con ese framing. Se trata de decidir qué merece atención, y el foco de atención cambia según la etapa de tu producto.
Pre-product-market-fit, el producto cambia constantemente. Los tests se convierten en un pasivo en lugar de un activo. Cada test que escribís puede necesitar reescribirse la semana que viene cuando iterás o pivoteás. Antes de escribir un test me pregunto dos cosas: qué tan crítica es esta funcionalidad y cada cuánto va a cambiar. Los tests que sí pagan son los que cubren un comportamiento que ya se estabilizó sobre una implementación que sigue evolucionando: esos atrapan una regresión cada vez que refactorizás. Y cuando el comportamiento y la implementación cambian los dos todas las semanas, el test es un lastre: vas a pasar más tiempo actualizándolo del que te ahorra.
Los mejores equipos con los que trabajé se ven más o menos así:
Los ingenieros son dueños de la calidad. El que escribe el código escribe los tests, shippea la feature, la mira en producción y la arregla cuando se rompe. No hay pared por encima de la cual tirar nada.
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, e invita al siguiente. Tiene un bonus práctico: cuando tus known issues están cerca de cero, cada bug nuevo salta a la vista.
Tests de integración por sobre tests end-to-end. E2E es lento, genera falsos positivos que necesitan un humano que los revise, e investigar una corrida fallida suele costar más que testear la cosa a mano. Los tests de integración atrapan la mayoría de lo que importa con una fracción del mantenimiento. Como dice Guillermo Rauch (compatriota, founder de Vercel y cerebro detrás de Next.js y v0): "Escribí tests. No demasiados. Mayormente de integración."
Testing en producción, a propósito. 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 para hacerlo de forma segura, lo que nos está matando."
Lo que quiere decir es que staging nunca se parece a producción: los usuarios reales, la infraestructura real y el timing real no se pueden reproducir. Mejor entonces hacer que producción sea un lugar seguro para testear, con feature flags, rollouts progresivos, ingenieros de guardia por su propio código, y managers que piensan en error budgets en lugar de exigir cero errores.
Y toda la empresa se involucra. Cuando trabajé en Cascade, el producto era un producto de estrategia para grandes corporaciones, y también lo usábamos internamente: para alinear el trabajo entre nuestros equipos, para planificar el ciclo de OKRs, y para medir cómo el trabajo de cada ingeniero y product manager contribuía a los objetivos de la organización. Ser el primer consumidor de tu propio producto significa que vivís los bugs antes que tus clientes.
Cuándo sí tiene sentido un QA formal
Ojo, no argumento que los equipos de QA son siempre un error. Hay contextos donde tienen sentido:
- 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 realmente mueven dinero entre cuentas. Si integraste Stripe o Mercado Pago, tu proveedor de pagos se encarga de la parte verdaderamente riesgosa, y tus bugs causan mala UX, no pérdidas financieras.
- Hardware. Donde no podés pushear un update después de que el dispositivo sale al mercado.
- Ciclos de release lentos. Si los releases son trimestrales o anuales, una fase de QA cuesta menos.
- Codebases legacy sin tests. Si heredaste un desastre sin tests, QA dedicado puede ser necesario mientras salís del pozo.
Fijate qué no está en la lista: startups buscando product-market fit.
La pregunta que deberías hacerte
Cuando un founder me pregunta si debería contratar un equipo de QA, le pregunto cuál es el problema, porque "tenemos muchos bugs" es un síntoma, no un problema, y contratar testers es la manera más cara de tratar un síntoma: pagás más sueldos y encima pagás de nuevo con feedback loops más lentos. Las causas suelen estar en otro lado, en el planning, en la capacitación, en la arquitectura, en quién es dueño de la calidad, y un equipo de QA no arregla ninguna de esas. La última hasta la empeora, porque ahora la calidad es oficialmente de otro.
Hay una historia en Art & Fear sobre un profesor de cerámica que dividió su clase en dos: a una mitad la iba a evaluar por la cantidad de vasijas que produjera, a la otra por la calidad. Las mejores vasijas terminaron saliendo del grupo de cantidad: mientras ellos producían y aprendían de sus errores, los de calidad se quedaron teorizando sobre la perfección y terminaron con poco más que teorías grandiosas y una pila de arcilla muerta.
Así que no, mi cliente no necesitaba testers que les escribieran los unit tests a los developers. Lo que necesitaba el equipo era espacio para hacer más vasijas.
