- El sueldo promedio es más alto. Cierto. Pero el sueldo promedio de un QA automation junior que no entiende lo que está automatizando es el mismo que el del manual — porque en la práctica no lo contratan.
- LinkedIn los presiona. “El manual está muerto”, “automatiza o muere”, la letanía de siempre. Nada de eso lo escriben personas que hayan contratado QAs en los últimos dos años.
- Los cursos lo venden así. Es más rentable vender un curso de 12 semanas de Selenium que decir “primero haz tres meses de manual, después volvemos”.
El problema es lo que viene después. Cuando llega la primera entrevista técnica, o peor, el primer día de trabajo.
He visto este patrón repetirse en tres formas:
Tests que prueban lo que el botón hace, no lo que el usuario necesita. Un test que hace clic en “Comprar” y verifica que aparezca “Compra realizada”. Técnicamente correcto. Pero no prueba que el cobro fue por el monto correcto, que el stock se descontó, que el email de confirmación llegó, que el carrito quedó vacío. El test pasa. El bug llega a producción.
Incapacidad de explicar por qué probar algo. En la entrevista técnica te preguntan “¿qué probarías en este formulario de registro?” y la respuesta es “haría un test que llene los campos y haga clic en enviar”. Correcto. Insuficiente. La pregunta real era “¿qué puede salir mal aquí?”, y eso se aprende probando a mano, no escribiendo scripts.
Fragilidad para debuggear. Un test falla. ¿Falló porque el código cambió? ¿Porque el selector se movió? ¿Porque el flujo de negocio ya no es el mismo? Sin haber recorrido ese flujo a mano muchas veces, no sabes dónde mirar. Terminas marcando el test como “flaky” cuando en realidad tu framework te está avisando de un bug real.
Los tres problemas tienen la misma raíz: nunca entendiste el flujo antes de intentar automatizarlo.
No es una ley sagrada. Es el orden que veo funcionar una y otra vez cuando alguien llega a QA sin background técnico:
Primeros 3 meses — Manual puro. Aprende a leer un requerimiento, a escribir casos de prueba, a reportar bugs, a hacer testing exploratorio. Nada de código todavía. El objetivo es construir criterio: saber qué probar antes de saber cómo automatizarlo.
Meses 4 al 6 — Manual + scripting básico. Ahora sí: primer test automatizado, pero sobre flujos que ya probaste a mano decenas de veces. La automatización deja de ser “algo que no entiendo” y pasa a ser “una forma más rápida de hacer lo que ya sé”.
Meses 7 al 12 — Automation con criterio. Frameworks, Page Object Model, CI/CD. Pero ahora cada decisión técnica tiene un por qué detrás: sabes qué vale la pena automatizar y qué no, porque lo has vivido del lado manual.
Al año, la persona que siguió esta secuencia y la persona que fue directo a automation están en lugares muy distintos. La primera está lista para pedir un aumento. La segunda sigue copiando tests de Stack Overflow.
Dos preguntas te ubican:
1. ¿Tienes background técnico previo? (programación, informática, carreras STEM) 2. ¿Cuánto tiempo real al día puedes dedicarle? (no el que quisieras — el real)
Con eso:
- Sin background + menos de 2h al día → Manual primero, sí o sí. Saltártelo es tirar 6 meses.
- Sin background + más de 2h al día → Manual primero, pero en paralelo empieza a familiarizarte con HTML/CSS básico. En el mes 3 vas a estar listo para el primer test.
- Con background + cualquier tiempo → Puedes hacer manual y scripting en paralelo desde el mes 1. Pero no te saltes la parte manual, solo la aceleras.
- Con background técnico fuerte + mucho tiempo → Eres el único caso donde ir “rápido” a automation tiene sentido. Aún así, dedica las primeras 3-4 semanas a testing manual de verdad antes de tocar código.
Ninguno de los cuatro casos dice “salta el manual”. Porque ninguno funciona.
El QA que cobra mejor en 2026 no es “el automation” ni “el manual”. Es la persona que tiene los dos y sabe cuándo usar cuál. Porque eso es lo que una empresa real necesita: alguien que pruebe a mano lo que todavía no está estable, automatice lo que sí, y tenga el criterio para saber la diferencia.
Si estás arrancando, no elijas entre los dos cursos. Elige el orden. Primero el Manual de TesteandoYa para construir la base — testing exploratorio, casos de prueba, reportes de bugs, criterio. Después el QA Automation Pro para convertir esa base en framework, Page Object Model, Playwright, CI/CD.
No es “cuál tomo”. Es “cuál tomo primero”. Esa sola palabra — primero — cambia todo.
