¿Cuándo vale la pena automatizar pruebas? Selenium, Playwright y Appium

«¿Deberíamos montar automatización de pruebas?» es una de las preguntas que más hacen los equipos pequeños y los responsables de producto. La respuesta no es ni «por supuesto» ni «no hace falta». Bien ubicada, la automatización ahorra horas en cada versión; mal ubicada, se convierte en un montón de pruebas sin mantenimiento que siempre están en rojo y que al final nadie mira. En este artículo explico de forma práctica qué cubren las pruebas manuales y las automatizadas, cuándo la automatización se amortiza, cómo elegir entre Selenium, Playwright y Appium y por dónde empezar.

¿Qué cubren las pruebas manuales y las automatizadas?

Las pruebas manuales consisten en que una persona usa realmente la aplicación y la revisa. El ojo humano detecta detalles de diseño extraños, textos confusos y flujos que «funcionan pero no tienen sentido». Para las pruebas exploratorias, la evaluación de usabilidad y la primera revisión de una funcionalidad nueva, las pruebas manuales son insustituibles.

Las pruebas automatizadas consisten en que un código ejecuta pasos predefinidos una y otra vez, siempre de la misma manera. No se cansa, no se salta pasos y puede ejecutar decenas de escenarios en minutos. Pero solo comprueba lo que se le ha indicado: no «nota» errores nuevos, sino que verifica si un comportamiento conocido sigue funcionando.

En resumen, no son rivales sino complementarias: la automatización se encarga de las comprobaciones repetitivas para que las personas dediquen su tiempo a lo que de verdad requiere pensar.

¿Cuándo se amortiza la automatización?

Cada prueba es una inversión: escribirla lleva tiempo, y actualizarla cuando cambia la aplicación también. Esa inversión suele compensar cuando:

• Prueba el mismo flujo a menudo. Si en cada versión recorre a mano el inicio de sesión, el registro, el carrito y el pago, esos pasos son los primeros candidatos a automatizar.
• Hay flujos cuyo fallo sale caro. Un carrito que no cobra o un restablecimiento de contraseña roto significan dinero y clientes perdidos.
• Publica versiones con frecuencia. Un equipo que despliega varias veces por semana no puede permitirse una larga lista de comprobación manual cada vez.
• Da soporte a varios navegadores o dispositivos. Probar a mano el mismo escenario en Chrome, Firefox y Safari se vuelve tedioso enseguida.
• El producto ha alcanzado cierta madurez. En un prototipo temprano cuya interfaz cambia cada semana, las pruebas se rompen constantemente; cuando los flujos principales se estabilizan, la automatización es mucho más eficiente.

Por el contrario, para una página de campaña puntual, un MVP muy temprano o una revisión de diseño visual, las pruebas manuales suelen ser la opción más sensata.

Elegir herramienta: Selenium, Playwright, Appium

Selenium

Selenium es la herramienta de automatización de navegadores más consolidada y la base del estándar W3C WebDriver. Admite muchos lenguajes, como Java, Python, C#, JavaScript y Ruby, y con Selenium Grid puede ejecutar pruebas en paralelo en varias máquinas. Si su equipo ya trabaja con Java o C#, o tiene una infraestructura de pruebas corporativa, Selenium sigue siendo una opción sólida. La desventaja es que a menudo hay que construir uno mismo la lógica de esperas y los informes.

Playwright

Playwright es una herramienta más reciente desarrollada por Microsoft. Controla los motores Chromium, Firefox y WebKit con una única API y admite TypeScript/JavaScript, Python, Java y .NET. Su mayor ventaja es la espera automática: espera por sí sola a que un elemento esté realmente listo para interactuar, lo que reduce notablemente las pruebas inestables (flaky). Trae de serie un ejecutor de pruebas, ejecución en paralelo, capturas de pantalla, vídeos y un trace viewer para inspeccionar paso a paso. Para un proyecto web que empieza desde cero, Playwright suele ser mi recomendación.

Appium

Si en lugar de una web tiene una app nativa de Android o iOS, entra en juego Appium. Appium también usa el protocolo WebDriver y ejecuta pruebas en dispositivos reales y emuladores mediante drivers como UiAutomator2 para Android y XCUITest para iOS. La configuración es más laboriosa que con las herramientas web y las pruebas móviles son por naturaleza más lentas, así que conviene elegir con especial cuidado el número de escenarios en móvil.

Un pequeño ejemplo con Playwright

La prueba siguiente verifica que un usuario puede iniciar sesión y ver el panel. En proyectos reales, las primeras pruebas que escribo suelen ser igual de sencillas:

// tests/login.spec.ts
import { test, expect } from '@playwright/test';

test('user can log in and see the dashboard', async ({ page }) => {
  await page.goto('https://example.com/login');

  await page.getByLabel('Email').fill('demo@example.com');
  await page.getByLabel('Password').fill('correct-password');
  await page.getByRole('button', { name: 'Sign in' }).click();

  // Playwright waits automatically until these become true (or times out)
  await expect(page).toHaveURL(/dashboard/);
  await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();
});

// Run: npx playwright test

Fíjese en que, en lugar de clases CSS, se usan selectores basados en lo que ve el usuario, como getByRole y getByLabel. Así las pruebas se rompen menos cuando cambia el diseño.

Integración con CI

Las pruebas muestran su verdadero valor cuando se ejecutan automáticamente, sin que nadie tenga que acordarse. En un sistema de CI como GitHub Actions o GitLab CI se añade un paso que ejecuta las pruebas en cada pull request o en cada push a la rama principal; si una prueba falla, se bloquea la fusión y el informe, las capturas o los archivos de trace se guardan como artefactos. Playwright ofrece para ello una guía de CI lista para usar con configuraciones de ejemplo, y la puesta en marcha inicial lleva menos de una hora en la mayoría de los proyectos.

Errores frecuentes

• Intentar probarlo todo. Cientos de pruebas de extremo a extremo dan como resultado un conjunto lento y difícil de mantener. Es más sano cubrir los flujos críticos de extremo a extremo y los detalles con pruebas unitarias y de API.
• Ignorar las pruebas inestables. Una prueba que unas veces pasa y otras falla destruye la confianza del equipo en los resultados. Use esperas basadas en condiciones en lugar de sleep fijos, y corrija la prueba inestable de inmediato o desactívela temporalmente dejándolo registrado.
• Selectores frágiles. Los XPath largos o las clases CSS generadas automáticamente se rompen con el menor cambio de diseño. Prefiera roles accesibles, etiquetas o atributos data-testid dedicados.
• Pruebas que dependen unas de otras. Cada prueba debe preparar sus propios datos y poder ejecutarse sola; si no, todo se derrumba cuando cambia el orden.
• No contar con el coste de mantenimiento. El código de pruebas también es código: debe seguir siendo legible y actualizarse a medida que cambia la aplicación.

¿Por dónde empezar?

1. Haga una lista de los tres a cinco flujos críticos cuyo fallo le saldría más caro: normalmente inicio de sesión, registro, pago y la funcionalidad principal.
2. Describa primero esos flujos paso a paso en texto plano; eso también será su lista de pruebas manuales.
3. Automatice esos escenarios con Playwright para web o con Appium para móvil.
4. Conecte las pruebas a la CI y ejecútelas con cada cambio.
5. Amplíe el conjunto poco a poco a medida que se detecten errores reales o se añadan nuevas funcionalidades críticas.

Un conjunto de pruebas pequeño pero fiable siempre vale más que uno grande en el que nadie confía.

Conclusión

La automatización de pruebas no es un fin en sí misma, sino una herramienta para publicar versiones con tranquilidad. Con los flujos adecuados y la herramienta adecuada, se amortiza rápidamente incluso en equipos pequeños. Si quiere definir conmigo qué escenarios de su proyecto merece la pena automatizar, o hacer más fiables sus pruebas actuales, no dude en ponerse en contacto.