Muchos quieren entrar al mundo de QA Automation pensando que el camino es aprender Playwright, Cypress o Selenium.
Y pará un poco.
Porque saber usar una herramienta no te convierte en tester.
Automatizar no es hacer clics con código. Automatizar es saber qué validar, por qué lo validás, qué riesgo estás cubriendo y qué evidencia necesitás cuando algo falla.
Y eso no te lo enseña una librería.
Eso te lo enseña QA manual.
La herramienta no piensa por vos
Playwright no entiende el negocio. Cypress no decide prioridades. Selenium no sabe si un flujo es crítico para el usuario o si estás validando una pantalla irrelevante.
Las herramientas ejecutan instrucciones. Nada más.
Si las instrucciones son malas, el test va a ser malo. Más rápido, más repetible, más integrado al pipeline, sí. Pero malo igual.
Ahí está el problema: mucha gente quiere automatizar sin haber aprendido primero a testear.
Y si vos no sabés diseñar un buen caso de prueba manualmente, lo único que vas a hacer automatizando es ejecutar basura más rápido.
QA manual te enseña a mirar el producto
QA manual no es “hacer clics”. Esa mirada pobre del rol hizo bastante daño.
Un buen QA manual observa el producto, entiende el flujo del usuario, cuestiona supuestos, busca inconsistencias, piensa en datos, estados, permisos, errores, límites y caminos alternativos.
Eso es criterio.
Y el criterio no aparece porque instalaste una dependencia de npm.
Cuando testeás manualmente, aprendés a preguntarte cosas que después son fundamentales para automatizar bien:
- ¿Qué comportamiento importa de verdad?
- ¿Qué riesgo estoy cubriendo con este caso?
- ¿Qué pasa si el usuario no sigue el camino feliz?
- ¿Qué dato necesito para que esta prueba tenga sentido?
- ¿Qué evidencia debería quedar si algo falla?
- ¿Este caso merece automatizarse o solo lo estoy automatizando porque puedo?
Esas preguntas separan a un automatizador serio de alguien que solo traduce pasos manuales a código.
Automatizar sin criterio escala el problema
Un mal caso manual duele una vez.
Un mal caso automatizado duele todos los días en CI.
Tests que validan cosas irrelevantes. Asserts pobres. Flujos duplicados. Esperas frágiles. Datos compartidos. Reportes que no explican nada. Pipelines rojos donde nadie entiende si se rompió el producto, el ambiente, el test o la cabeza del que lo escribió.
Eso no es automatización. Es deuda técnica con formato de suite.
La automatización no reemplaza el criterio: lo amplifica.
Si tenés buen criterio, automatizás mejor. Si tenés mal criterio, hacés quilombo a escala.
Qué te da QA manual antes de automatizar
QA manual te obliga a entender el producto antes de tocar código.
Te entrena para diseñar escenarios. Te muestra dónde suelen aparecer los defectos. Te enseña a priorizar riesgos. Te obliga a reportar con claridad. Te hace distinguir entre una falla real, un problema de datos, una mala expectativa y un comportamiento ambiguo.
Y eso después impacta directo en la automatización:
- Escribís mejores nombres de tests.
- Elegís mejores assertions.
- Priorizás casos con valor real.
- Evitás automatizar flujos inútiles.
- Diseñás datos más estables.
- Reportás fallas con evidencia entendible.
- Sabés cuándo un test está mintiendo.
Porque automatizar no es copiar un caso manual y meterle código. Eso es mecanizar pasos.
Automatizar bien es convertir conocimiento del producto en una verificación confiable.
El orden importa
No estoy diciendo que tengas que pasar años haciendo QA manual antes de tocar una herramienta. Tampoco seamos dogmáticos al pedo.
Pero sí digo algo concreto: si querés ser buen QA Automation, primero aprendé a testear.
Aprendé a observar. Aprendé a preguntar. Aprendé a diseñar escenarios. Aprendé a priorizar riesgos. Aprendé a reportar bien. Aprendé a entender cuándo algo falla y por qué.
Después sí: meté Playwright, Cypress, Selenium o la herramienta que quieras.
Pero no confundas herramienta con profesión.
La herramienta ejecuta.
El criterio lo ponés vos.
Primero QA.
Después Automation.