Cada vez que alguien dice “Patrick, ¿ya testeaste esto?”, una parte de mí muere un poco. No porque no quiera testear — sino porque QA es mucho más que eso.
El mito del tester
El estereotipo del QA es alguien que recibe un build, hace clic en cosas y reporta bugs. Y sí, hacemos eso. Pero también hacemos esto:
- Revisamos requisitos antes de que se escriba una sola línea de código
- Diseñamos casos de prueba que cubren los edge cases que nadie pensó
- Automatizamos para que los humanos no pierdan tiempo en lo repetitivo
- Monitoreamos producción para detectar problemas antes que los usuarios
Calidad desde el diseño
La mejor forma de prevenir bugs es no crearlos. Suena obvio, pero la mayoría de los bugs que encuentro nacen de requisitos ambiguos o diseños incompletos. Mi trabajo empieza mucho antes del primer npm test.
Automatización inteligente
No todo necesita un test automatizado. Sí, lo dije. A veces un test manual bien pensado vale más que 50 tests e2e que tardan 20 minutos en correr y se rompen cada vez que alguien mueve un botón.
La clave es automatizar lo que tiene sentido: flujos críticos, regresiones conocidas, validaciones de datos. El resto, criterio humano.
El verdadero rol del QA
Somos los abogados del usuario. Nuestra pregunta constante es: ¿esto funciona como el usuario espera? No como el dev espera, no como el diseño dice — como el usuario realmente lo va a usar.
Y eso, amigos, es mucho más que correr tests.