Acabas de terminar las tres partes de la trilogía. Ya sabes elegir tu primera herramienta, montar una arquitectura con POM y CI/CD, y cómo posicionarte como QA Automation Engineer.
Y aún así, hay una pregunta que ninguna de las tres guías te respondió: ¿tienes que hacerlo?
Si esa pregunta te incomoda, este artículo es para ti.
La mentira que nos vendieron
Abre LinkedIn cinco minutos y vas a leer alguna versión de esto:
«El QA manual está muerto.» «Si no automatizas, te quedaste atrás.» «Automatiza o muere.»
Es ruido. Y peor: es ruido que hace daño.
Hace daño porque convierte una herramienta — la automatización — en una identidad. Te dice que si no automatizas, no eres «de verdad» un QA. Que estás en el escalón bajo. Que lo manual es lo que se hace cuando no sabes programar.
Nada de eso es cierto.
Los mejores QA que conozco — los que encuentran los bugs caros, los que la gente escucha en refinamiento, los que el equipo no quiere perder — automatizan menos del 50% de lo que prueban. Y lo hacen a propósito.
La automatización no es una meta. Es una herramienta.
Esta es la frase que me hubiera gustado escuchar cuando empecé:
Automatizar lo equivocado es peor que no automatizar nada.
Un test automatizado que no aporta valor no es neutro. Tiene un costo: hay que escribirlo, mantenerlo, debuggearlo cuando falla por razones tontas, actualizarlo cuando el equipo cambia un selector, explicárselo al QA nuevo que entra dentro de seis meses.
Si ese test no te ahorra tiempo, no detecta bugs reales, o protege un flujo que ya casi nunca se usa — estás pagando una hipoteca por una casa donde no vives.
Cuándo NO tiene sentido automatizar
Esto es lo que ningún tutorial te dice. Hay escenarios completos donde automatizar es la respuesta equivocada, por mucho que LinkedIn te haga sentir culpable:
Si tu contexto entra en alguno de estos cuadros y aún así estás forzando automatización porque «hay que automatizar», estás haciendo trabajo que se va a tirar.
Cuándo SÍ es obligatorio
Y ahora la otra cara. Hay escenarios donde no automatizar es directamente irresponsable. No es opinión — es cálculo:
Este es el tipo de cálculo que veo repetirse en proyectos fintech donde la regresión crítica estaba consumiendo horas semanales de un QA, repitiendo los mismos clicks, cada semana, sin variación. Cuando la conversación pasa de «hay que automatizar» a mostrar ese ROI con números concretos, la discusión termina. Ahí la automatización deja de ser una opción — es la única decisión responsable.
Lo que el QA manual hace mejor que cualquier script
Ahora la parte que casi nadie escribe, porque no vende cursos.
Hay cosas que un humano probando hace infinitamente mejor que cualquier suite automatizada. No «mejor por ahora hasta que la IA nos alcance». Mejor punto. Para siempre.
Testing exploratorio real
Sentarte frente al producto sin script, sin caso de prueba, sin checklist. Solo curiosidad y experiencia. Hacer lo que un usuario no debería hacer y ver qué pasa. Ningún test automatizado va a encontrar lo que tú encuentras en una sesión de exploratorio bien hecha — porque por definición, lo que automatizas es lo que ya sabes que puede pasar.
Detectar inconsistencias de UX
Un botón que dice «Guardar» en una pantalla y «Confirmar» en otra. Un formulario que pide el teléfono con código de país y otro sin. Mensajes de error que mezclan español e inglés. Eso ningún assert lo ve. Un humano lo nota a los diez segundos.
Cuestionar el requerimiento
El bug más caro que encontré en mi carrera lo encontré leyendo un documento. Sin ejecutar una sola línea de código. La especificación tenía una contradicción entre dos secciones, y esa contradicción habría costado a la empresa miles de dólares en transacciones mal calculadas. Eso no se automatiza. Eso es criterio.
Entender el negocio
Saber que cuando el flujo de inscripción tarda dos segundos más de lo normal, el área comercial pierde leads. Saber que ese campo «opcional» es obligatorio en la práctica porque el equipo de soporte usa esa información para responder tickets. Ese contexto vive en las personas, no en el código.
El criterio: una matriz simple
Si te llevas una sola cosa de este artículo, que sea esta. Antes de automatizar cualquier cosa, pásala por dos preguntas:
1. ¿Con qué frecuencia se va a ejecutar este test? 2. ¿Qué tan estable es el flujo que voy a probar?
Eso te da cuatro cuadrantes:
Solo uno de los cuatro cuadrantes justifica automatizar. Los otros tres no son fracasos — son decisiones inteligentes.
La verdad incómoda del cierre
Después de quince años en QA, después de liderar equipos, después de construir frameworks desde cero, esto es lo que aprendí:
El mejor QA Automation Engineer que conozco automatiza menos del 40% de lo que prueba. El resto lo prueba a mano, porque sabe que automatizar lo equivocado es peor que no automatizar nada.
La automatización no te hace mejor QA. Te hace más eficiente en una parte específica del trabajo. El criterio para saber qué automatizar y qué no — eso sí te hace mejor QA. Y ese criterio se construye probando a mano, leyendo requerimientos, hablando con usuarios, encontrando bugs donde nadie los esperaba.
Si después de leer las tres partes de la trilogía decides que tu contexto no necesita automatizar todo — o nada — no eres menos profesional. Eres más maduro.
Y si decides automatizar, hazlo donde tiene sentido. No donde LinkedIn te hace sentir culpable.
¿Y ahora qué?
Si todavía no leíste la trilogía completa, este es el orden:
- Parte 1: Por dónde empezar
- Parte 2: Arquitectura y pipeline
- Parte 3: El salto a QA Automation Engineer
Y si quieres entender la teoría detrás del criterio que acabamos de ver — partición de equivalencia, valores límite, tablas de decisión, transición de estados — eso es exactamente lo que estoy preparando en una nueva sección del blog. Pronto.