Back to blog
AutomationAutomationQAManual Testing

De Manual a Automation Tester: Tu Hoja de Ruta Técnica y Herramientas Esenciales

En mi artículo anterior, exploramos cómo la Inteligencia Artificial está redefiniendo el futuro del Testing. Pero para llegar a ese futuro y pilotar esas herramientas avanzadas, pr...

26 mar 20268 min readCarlos Cervantes
De Manual a Automation Tester: Tu Hoja de Ruta Técnica y Herramientas Esenciales

En mi artículo anterior, exploramos cómo la Inteligencia Artificial está redefiniendo el futuro del Testing. Pero para llegar a ese futuro y pilotar esas herramientas avanzadas, primero necesitas construir una base sólida. Necesitas hacer el viaje: de Manual Tester a Automation Tester.

Si hoy pasas la mayor parte de tu tiempo ejecutando casos de prueba repetitivos en Excel o Jira, este artículo es para ti. No te voy a mentir: es un desafío técnico, pero es un camino totalmente transitable si tienes el mapa correcto.

Aquí tienes la hoja de ruta detallada, paso a paso, técnicamente hablando, para realizar esta transición exitosamente.

Fase 1: Los Cimientos No-Código (The Prereqs)

Antes de escribir tu primera línea de código, necesitas entender a fondo el entorno en el que viven las aplicaciones. Un Automation Tester no adivina; inspecciona y comprende.

1. Dominar el DOM (Document Object Model) y los Selectores

El DOM es el "esqueleto" de una página web. Cuando un script de prueba falla, el 80% de las veces es porque el elemento web (un botón, un campo de texto) cambió su ubicación o sus atributos en el DOM.

El arte de los localizadores estables: No puedes depender de copiar y pegar el XPath absoluto del navegador (ej. /html/body/div[2]/div/form/input[1]), porque si el desarrollador agrega un simple <div> extra, tu prueba se rompe.

Qué aprender a fondo:

Atributos únicos: Busca siempre interactuar con id, name, o data-testid (este último es una excelente práctica que puedes pedirle a tus desarrolladores que implementen).

CSS Selectors Avanzados: Aprende a buscar elementos hijos (div &gt; p), hermanos (h1 + p) o por partes de un atributo (input[class*='btn-submit']).

XPath Dinámico: Aprende a usar funciones de XPath como contains(), text() y ejes como following-sibling. Ejemplo de un buen XPath: //button[contains(text(), 'Login')].

2. Fundamentos de Redes y la Pestaña "Network"

Un buen tester no solo mira lo que pasa en la pantalla, sino lo que viaja por la red.

Qué aprender: Abre las DevTools (F12) y ve a la pestaña Network (Red). Haz clic en un botón de tu aplicación web y observa la petición que se dispara. Debes entender cómo leer el Request Payload (lo que envías) y el Response Preview (lo que el servidor te devuelve, usualmente en formato JSON). Entender esto te salvará la vida cuando necesites saber si un bug es de Frontend (la UI no se actualizó) o de Backend (el servidor devolvió un error 500).

Fase 2: Aprender a Programar (The Real Jump)

Aquí es donde pasas de usar herramientas de "grabar y reproducir" (Record & Playback) a crear verdaderas soluciones de software. Como Automation Tester, tú también eres un desarrollador, solo que tu producto final es el código que prueba el código.

¿Cómo aplicar la programación al Testing?

No vas a programar un carrito de compras, vas a programar su validación. Así es como usarás los conceptos básicos:

Variables: Para guardar datos dinámicos, como un ID de orden que el sistema acaba de generar (order_id = "12345").

Bucles (For / While): Imagina que tienes una tabla con 50 usuarios y necesitas verificar que todos tengan el estado "Activo". Un bucle recorrerá cada fila en milisegundos para hacer la aserción por ti.

Estructuras de Datos (Arrays/Listas y Diccionarios/JSON): Esenciales para pruebas basadas en datos (Data-Driven Testing). Puedes crear una lista con 10 correos electrónicos inválidos y hacer que tu script los pruebe uno por uno en el campo de registro.

Programación Orientada a Objetos (POO): Te permite crear "moldes" (Clases) para no repetir código. Si 10 de tus pruebas necesitan iniciar sesión, no escribes los pasos 10 veces; llamas al método login() de tu clase principal.

Fase 3: Automatización de APIs (La "Pirámide del Testing")

Antes de tocar la interfaz gráfica (UI), debes conocer la Pirámide de Automatización. Las pruebas de UI son la punta (lentas, frágiles y costosas de mantener). Las pruebas de API están en el medio: son increíblemente rápidas, súper estables y te dan un feedback casi inmediato.

¿Qué automatizamos en una API?

No se trata solo de hacer "ping" para ver si responde. Debes automatizar validaciones profundas (Aserciones):

Status Code: ¿El servidor respondió con un 200 (OK), 201 (Creado) o 401 (No autorizado)?

Validación de Contenido (Body): Si pides la información del usuario "Juan", ¿el JSON de respuesta realmente dice "nombre": "Juan"?

Validación de Esquema (Schema Validation): Verificar que la estructura de la respuesta no haya cambiado (ej. que el campo "edad" siga siendo un número y no haya cambiado a texto).

El camino recomendado: Domina las colecciones de Postman, usa sus variables de entorno y escribe pequeños scripts en JavaScript en la pestaña "Tests". Una vez que domines eso, migra tus peticiones a un framework de código puro como Rest-Assured (Java) o Requests + Pytest (Python).

Fase 4: Automatización Web (UI) y Patrones de Arquitectura

Automatizar el navegador no se trata solo de abrir Chrome y hacer clics. Se trata de crear un proyecto escalable.

1. Los "Test Runners" (El motor de tus pruebas)

Selenium o Playwright solo saben interactuar con el navegador, pero no saben cómo organizar tus pruebas, generar reportes o decirte cuántas pruebas pasaron o fallaron. Para eso necesitas un Test Runner:

Si usas Python: Pytest.

Si usas Java: TestNG o JUnit.

Si usas JavaScript: Mocha, Jest o el test runner integrado de Playwright/Cypress. ** 2. Entendiendo el Page Object Model (POM) a fondo**

Imagina que la pantalla de "Login" cambia completamente su diseño. Si tienes 50 scripts que hacen login directamente, tendrás que actualizar 50 archivos. Con POM, creas un solo archivo llamado LoginPage. Ese archivo contiene:

Los selectores (ej. input_usuario, input_password, boton_enviar).

Las acciones (ej. una función hacerLogin(usuario, password)).

Tus 50 scripts de prueba simplemente llaman a LoginPage.hacerLogin(). Si el diseño cambia en el futuro, solo actualizas un archivo, y las 50 pruebas volverán a funcionar mágicamente. Eso es mantenibilidad real.

Fase 5: El Ecosistema DevOps (Donde viven tus tests)

El objetivo final de la automatización es el "Shift-Left Testing": encontrar los bugs lo más temprano posible. Para ello, tus pruebas no pueden vivir escondidas en tu computadora local.

1. Ejecución "Headless"

En un entorno profesional, tus pruebas no abrirán un navegador visible donde veas cómo se mueve el mouse. Se ejecutarán en modo Headless (sin interfaz gráfica) dentro de un servidor en la nube. Es un 30% más rápido y consume muchos menos recursos.

2. El Pipeline de Integración Continua (CI)

Debes aprender a conectar tu repositorio (GitHub/GitLab) con una herramienta de CI/CD. El ciclo de vida de un Automation Tester profesional se ve así:

El desarrollador sube nuevo código al repositorio.

El pipeline (ej. GitHub Actions o Jenkins) detecta el cambio automáticamente.

El pipeline descarga el código, instala las dependencias y ejecuta tu suite de pruebas de forma automática.

Si una prueba falla, el pipeline "rompe" la compilación y alerta al equipo inmediatamente, impidiendo que ese bug llegue a producción.

Se genera un reporte HTML (como Allure Reports) con capturas de pantalla de los errores.

El Código es solo una Herramienta, tu Mentalidad es el Superpoder

Sé perfectamente que llegar al final de este artículo y ver listas de lenguajes, frameworks, APIs y pipelines puede resultar abrumador. Es normal sentir el famoso "síndrome del impostor" o pensar: "Soy de QA Manual, la programación no es para mí".

Pero quiero compartirte el secreto mejor guardado de la industria: la parte más difícil de la automatización no es escribir el código. La sintaxis se busca en Google, los selectores se depuran y los pipelines se configuran una vez.

La verdadera dificultad radica en saber qué probar, en tener esa malicia para encontrar los edge cases, en entender el negocio y en poseer ese pensamiento crítico que no deja escapar ni un solo bug a producción. ¡Y esa mentalidad tú ya la tienes!

Llevas meses o años entrenando tu cerebro para desarmar y analizar software. Aprender a programar es simplemente aprender un nuevo idioma para pedirle a tu computadora que ejecute esos casos de prueba por ti, a la velocidad de la luz, mientras tú te dedicas a tareas más estratégicas e interesantes.

Pasar de Manual a Automation Tester no significa borrar lo que sabes; significa darle superpoderes a tus habilidades actuales. Significa decirle adiós a las regresiones aburridas de los viernes por la tarde y darle la bienvenida a un perfil profesional mucho más cotizado, mejor pagado y listo para liderar la era de la Inteligencia Artificial de la que hablamos en mi post anterior.

El viaje no se hace en un fin de semana, requiere disciplina y frustrarse un par de veces con una pantalla en rojo. Pero el momento en que veas tu primer script abrir el navegador, hacer login y marcar un caso de prueba en verde de forma automática... te prometo que no habrá vuelta atrás.

No intentes aprenderlo todo hoy. Elige una herramienta (abre Postman o instala Python), sigue un solo tutorial básico y automatiza una pequeña validación. Ese primer paso es el único que importa ahora mismo.

¿Estás listo para escribir tu primera línea de código? ¡Cuéntame en los comentarios con qué lenguaje o herramienta vas a empezar tu viaje!