De QA manual a automatización — Parte 1: por dónde empezar cuando todo te abruma

Eres QA manual. Y ya te diste cuenta de que necesitas empezar a automatizar.

Has visto 5 cursos. Has empezado con 3 herramientas. Has leído decenas de artículos que te dicen “aprende Selenium”, “no, mejor Playwright”, “Cypress es más fácil”, “Java”, “Python”, “TypeScript”.

Y sigues sin saber por dónde empezar.

Mientras tanto, todos los días te repiten lo mismo: “tenemos que automatizar”, “el equipo necesita automation”, “¿ya empezaste a automatizar?”

Si esto te suena familiar, quédate. Porque esta guía no te va a enseñar una herramienta. Te va a enseñar la estrategia — el orden, las decisiones, y el camino paso a paso para hacer la transición sin ahogarte en el intento.

Lo primero: por qué estás paralizado (y por qué es normal)

No estás paralizado porque seas incapaz. Estás paralizado porque el problema está mal planteado.

“Aprende a automatizar” es como decir “aprende a cocinar”. ¿Cocinar qué? ¿Para quién? ¿Con qué ingredientes tienes? ¿Cuál es el presupuesto? ¿Tienes cocina o solo un microondas?

La automatización de pruebas es exactamente igual. No existe una respuesta universal. Existe tu contexto:

• ¿Qué tipo de aplicación testeas? (web, mobile, API, desktop)
• ¿Qué stack tecnológico usa tu equipo de desarrollo?
• ¿Tienes acceso al código fuente o solo al producto?
• ¿Cuánto tiempo tienes para aprender mientras sigues haciendo tu trabajo manual?

Hasta que no respondas estas preguntas, cualquier curso es ruido.

Paso 1: Deja de aprender herramientas. Elige UNA.

El error más común que veo en QAs manuales que quieren transicionar es este: empiezan 3 herramientas a la vez, no terminan ninguna, y sienten que no avanzan.

Elige una sola herramienta. Una. Y quédate con ella mínimo 3 meses.

¿Cuál? Depende de tu contexto. Pero voy a simplificarte la decisión:

Si testeas aplicaciones web (la mayoría de ustedes)

Si testeas APIs

Empieza con Postman. Sí, Postman. No necesitas un framework para empezar a automatizar APIs. Crea colecciones, agrega assertions, córrelas con Newman. Cuando te quede chico, migras a un framework de código.

Si testeas mobile

Appium sigue siendo el estándar. Pero si tu app es React Native o Flutter, investiga primero si los frameworks nativos de testing (Detox, Flutter test) te sirven.

La regla

Paso 2: Olvida el tutorial. Automatiza algo real.

Este es el salto que ningún curso te enseña. Y es el paso donde la mayoría se queda.

Ya hiciste el tutorial de la to-do app. Ya automatizaste un login en una página de ejemplo. Felicidades. Pero eso no te convierte en QA automation. Lo que te convierte es automatizar un test real de tu aplicación real.

Cómo elegir tu primer test

No elijas el flujo más complejo. No elijas el más importante. Elije el más predecible:

Buenos candidatos para tu primer test:

• Login con credenciales válidas — flujo simple, verificación clara (llegas al dashboard o no)
• Buscar un producto/registro — escribes en un campo, verificas que aparezca el resultado
• Crear un registro básico — llenar un formulario, enviar, verificar que se creó

Malos candidatos para tu primer test:

• Flujos que requieren datos de otros tests
• Flujos con integración de pagos o APIs de terceros
• Flujos que cambian cada sprint

El ejercicio

Abre tu aplicación. Haz el flujo manualmente. Escribe los pasos en un papel (sí, en un papel). Ahora traduce cada paso a código — y si te trabas, pásale tus pasos escritos a la IA y pídele que te genere el esqueleto del test. Después lo ajustas tú.

import { test, expect } from "@playwright/test";

test("login exitoso muestra el dashboard", async ({ page }) => {
  // Paso 1: Ir a la aplicación
  await page.goto("https://mi-app.com/login");

  // Paso 2: Llenar credenciales
  await page.getByLabel("Email").fill("qa-tester@empresa.com");
  await page.getByLabel("Contraseña").fill("MiPassword123");

  // Paso 3: Hacer click en "Iniciar sesión"
  await page.getByRole("button", { name: "Iniciar sesión" }).click();

  // Paso 4: Verificar que llegué al dashboard
  await expect(page.getByRole("heading", { name: "Dashboard" })).toBeVisible();
});

No es perfecto. No tiene Page Object Model. No tiene datos dinámicos. No tiene CI/CD.

No importa. Es tu primer test real. Y es infinitamente más valioso que 10 tutoriales completados.

Paso 3: Cómo proponerlo en tu empresa (sin que te ignoren)

Tienes tu primer test. Funciona. Ahora viene el paso que los cursos no enseñan: cómo convencer a tu equipo de que esto vale la pena.

No llegues a la reunión diciendo “deberíamos automatizar”. Eso ya lo dijeron 47 personas. Llega con datos.

El argumento que funciona

No hables de herramientas. No hables de “mejores prácticas”. Habla del dolor que ya conocen:

La estructura de la propuesta

La clave es que no pidas permiso para “aprender automation”. Muestra un resultado y pide tiempo para escalar lo que ya funciona.

Paso 4: El plan de 90 días

Aquí es donde esto se convierte en algo real. No es “cuando tenga tiempo”. Es un plan con semanas, objetivos, y resultados medibles.

Mes 1 — Los cimientos (semanas 1-4)

Objetivo: Tu primer test real funciona y el equipo lo sabe.

Mes 2 — Consolidación (semanas 5-8)

Objetivo: 5-10 tests estables cubriendo el smoke test más importante.

Mes 3 — Velocidad (semanas 9-12)

Objetivo: La automatización es parte del proceso, no un experimento paralelo.

Paso 5: Lo que nadie te dice

Voy a ser honesta contigo porque me hubiera gustado que alguien me dijera esto cuando empecé.

Vas a ser lenta al principio

Tu primer test va a tomar un día entero. El mismo flujo que ejecutas manualmente en 5 minutos te va a tomar 8 horas automatizarlo. Y va a fallar. Y vas a buscar errores que no entiendes.

Pero aquí está la buena noticia: ya no estás sola en eso. La IA cambió las reglas del juego para quienes están aprendiendo. Cuando tu test falle con un error incomprensible, en vez de pasar 2 horas en Stack Overflow, pégale el error a Claude o ChatGPT y pregunta: “¿qué significa este error y cómo lo soluciono?” En el 80% de los casos vas a tener una respuesta útil en 30 segundos.

Si quieres saber exactamente en qué momentos la IA te ayuda más (y en cuáles no confíes ciegamente), lee mi guía IA para QA: la guía práctica que me hubiera gustado tener.

No estás perdiendo el tiempo. Estás invirtiendo. Ese test que tardaste un día en escribir va a correr miles de veces sin que toques nada. Las matemáticas siempre favorecen la automatización a largo plazo.

No tienes que dejar de hacer testing manual

Automatización no reemplaza tu trabajo. Lo potencia. Las pruebas exploratorias, el análisis de requisitos, el ojo crítico que tienes después de años de testing manual — eso no se automatiza. Y es tu mayor ventaja competitiva.

Los mejores QA automation engineers que conozco no son los que mejor programan. Son los que mejor entienden qué testear y por qué. Eso viene del testing manual. No lo subestimes.

De hecho, esa capacidad de análisis que desarrollaste haciendo testing manual es exactamente lo que hace que la IA funcione mejor para ti que para un developer. Tú sabes qué preguntar, qué buscar, qué puede salir mal. La IA pone la velocidad. Tú pones el criterio. Si quieres ver cómo se ve esa combinación en la práctica, lee De prompts a agentes: cómo armé mi propio equipo de IA para QA.

El síndrome del impostor es parte del proceso

Vas a sentir que no sabes suficiente. Que los developers escriben código “de verdad” y tú estás jugando. Que tus tests son torpes comparados con lo que ves en GitHub.

Déjame decirte algo: cuando yo empecé a automatizar en DESOFT, en Cuba, no tenía frameworks, ni Stack Overflow, ni IA que me ayudara. Aprendí rompiendo cosas. Literalmente. Y mi primer test de Selenium era espantoso. Pero funcionaba. Y eso fue suficiente para empezar.

Tú tienes algo que yo no tuve: una IA que te explica los errores, te genera esqueletos de código, y te desbloquea en segundos. La transición que a mí me tomó años, hoy se puede hacer en meses. No tienes excusa.

JavaScript/TypeScript no es tan difícil como crees (y la IA te acelera)

Si nunca programaste, TypeScript te va a parecer un idioma extraterrestre los primeros días. Pero no necesitas ser experta en programación para automatizar tests. Necesitas saber:

• Variables y funciones (para guardar datos y organizar pasos)
• async/await (para esperar que las cosas pasen en el navegador)
• Cómo leer un error en la terminal (el 80% de la resolución es entender qué dice el error)

Eso es todo para empezar. Lo demás lo aprendes sobre la marcha, resolviendo problemas reales.

Y aquí va algo que hubiera cambiado mi vida cuando empecé: usa la IA como tu compañera de aprendizaje. No para que escriba todo por ti — sino para que te explique lo que no entiendes. Pégale un fragmento de código y pregunta “¿qué hace esta línea?”. Pídele que te explique un concepto como si fueras principiante. Úsala para generar los primeros test cases a partir de tus pasos manuales y luego revisa, edita, y entiende cada línea.

Si te interesa cómo uso yo la IA en mi día a día real como QA (no en teoría, en la práctica), escribí sobre eso en 5 cosas que la IA hace mejor que yo en QA — y 3 donde falla horrible.

Paso 6: Tu primer checklist de acción

No te voy a dejar con teoría. Aquí tienes lo que puedes hacer hoy — literalmente hoy:

# 1. Verifica que tienes Node.js instalado (necesitas versión 18+)
node --version

# 2. Crea una carpeta para tus tests
mkdir mis-primeros-tests
cd mis-primeros-tests

# 3. Inicializa Playwright (te va a hacer preguntas — acepta los defaults)
npm init playwright@latest

# 4. Corre los tests de ejemplo que vienen incluidos
npx playwright test

# 5. Abre el reporte visual para ver los resultados
npx playwright show-report

Resumen: la hoja de ruta completa

¿Y después de los 90 días?

Si llegaste hasta aquí, ya no eres QA manual que “está aprendiendo a automatizar”. Eres QA que automatiza. La diferencia es enorme — y el mercado lo sabe.

Pero este es solo el primer paso. Después vienen las preguntas de verdad:

• ¿Cómo organizo mi código cuando tengo 50 tests? (Page Object Model)
• ¿Cómo integro mis tests al pipeline de CI/CD?
• ¿Cómo decido qué automatizar y qué dejar manual?

Eso es exactamente lo que cubro en la Parte 2: arquitectura y pipeline.

Y cuando estés lista para el salto a testing de APIs, visual regression, y posicionamiento profesional, está la Parte 3: el salto a QA Automation Engineer.

Una última cosa

Hace 13 años, en Cuba, yo era exactamente tú. Testing manual. Sin frameworks. Sin nadie que me dijera por dónde empezar. Aprendí por ensayo y error — más error que ensayo, siendo honesta.

Hoy lidero automatización con Playwright, uso IA en mi flujo diario, y enseño a otros QAs a hacer esta misma transición.

No te cuento esto para presumir. Te lo cuento para que sepas que la parálisis no es permanente. Es solo el primer paso de un camino que merece la pena recorrer.

Deja de acumular cursos. Abre tu app. Escribe tu primer test.

Lo demás viene después.