Hace unos años me tocó un proyecto difícil: alcance complejo, cliente exigente, y un equipo de desarrollo talentoso puesto a prueba de verdad por primera vez. Todo bien hasta que llegó la época de entrega y las pruebas del cliente. Entre idas y vueltas, hicimos el go-live unos meses después del plazo. Culpa nuestra, pero también de los cambios que el cliente fue pidiendo en el camino. Y ahí el proyecto dejó de ser proyecto y se volvió mantenimiento continuo.
Teníamos un pipeline de CI/CD y una cobertura de pruebas razonable. Lo peculiar era el contrato: en el mantenimiento, las horas de desarrollo de una feature nueva se pagaban; el tiempo gastado corrigiendo bugs, no. Y no había QA dedicado. El mismo equipo que escribía el código probaba lo que escribía, a mano y en automático.
Y cómo había bugs. De solo acordarme se me eriza la piel. Nada grave, pero el bug que se va acumulando raspa la credibilidad con el cliente. La gota que colmó el vaso fue un deploy de viernes. Subimos, nos fuimos a casa. El daño solo apareció cuando abrimos el correo el lunes, con el cliente furioso, y con toda la razón. Una ruta de API se había roto, las pruebas no agarraron el caso, y la integración quedó caída todo el fin de semana. Corrección de una línea. Pero dejamos al cliente colgado, y eso era inadmisible.
El QA era tratado como un lujo
Hasta ahí, el QA era un lujo. Cuando yo tocaba el tema con el tech lead, la lectura era que no hacía falta un equipo dedicado. El liderazgo tampoco veía la necesidad. Ese fin de semana cambió esa mentalidad de una vez por todas. Esa misma semana hubo reunión, y escuché toda la frustración: que nuestro equipo no servía, que deberíamos tener vergüenza de nuestro código, que el contrato estaba en riesgo. Escuché, tragué saliva. Cuando llegó mi turno de hablar, le di la razón, asumí la responsabilidad y pedí una sola cosa: "Dame una oportunidad. En un mes encarrilamos este proyecto."
El equipo era bueno, el código no era malo. Pero lo que pesa es la percepción del cliente. Teníamos un producto innovador en las manos, daba un trabajo enorme poner en producción las features que él pedía, y faltaba gente de adentro para validar todo. Todo proyecto tiene un QA. Nuestro problema era que, hasta entonces, el QA era el propio cliente. Eso tenía que cambiar.
Nace un área de QA
Salí de la reunión con carta blanca para contratar y ordenar la casa. Traer dos personas de QA se volvió prioridad. Hecha la contratación, manos a la obra. Sumé un dev más: mientras uno sacaba features nuevas, el otro corregía los bugs que las QA encontraban. Solo ese ajuste ya equilibró el proyecto financieramente. Y aquí cayó una ficha importante: ¿te acuerdas del contrato, donde una feature nueva se pagaba y la corrección de bug no? Con las QA filtrando los problemas antes de que llegaran al cliente, el equipo paraba menos para apagar incendios y pasaba más tiempo en lo que de verdad generaba ingresos. El QA no era costo. Era ingreso.
El deploy también dejó de pasar a cualquier hora. Pasamos a tener un día fijo en la semana, bien acordado con el cliente. Esa previsibilidad hizo una diferencia enorme en la comunicación, más todavía cuando algún deploy necesitaba rollback. Cada tanto seguía rompiéndose algo en producción, escenarios imposibles de cubrir en homologación, y estaba bien. El primer mes fue pesado. En el segundo, la app ya estaba más estable. Del tercero en adelante, andando redondo. El área de QA probó su valor, duplicó su tamaño y abarcó otros frentes, nuevos productos y herramientas.
Mirando hacia atrás, veo el tamaño del desafío y me alegra que haya salido bien: la confianza del cliente se mantuvo y, donde se había raspado, se reconstruyó. Crear una cultura de QA lleva tiempo. Pero cada pequeña victoria, cada cliente satisfecho, cada elogio pone un ladrillo de esa cultura. El equipo que no tenía QA pasó a ser un equipo que no vive sin él.
Gracias a todas las QA con las que tuve la suerte de trabajar, y al Cantinho das QAs por mantener viva una comunidad de gente talentosa y motivada. ¡Ustedes son lo máximo!