Cómo elegir tu stack de automatización sin casarte con ninguna herramienta

No elegí Selenium.

Selenium era lo único que conocíamos en el equipo, y no había presupuesto para nada más. Ese fue el proceso de decisión completo: lo que ya sabíamos usar y lo que costaba cero. Sin comparativa, sin prueba de concepto, sin tabla de features.

Y funcionó. Con eso llevamos tres proyectos en paralelo —uno de gobierno, uno financiero, uno educativo— de testing manual puro a un híbrido que aguantó años.

Si el criterio fue “lo único que sabemos y lo que no cuesta”, y aun así el framework sirvió durante años, la herramienta era la parte de la decisión que menos pesaba.

Hasta la parada anterior armaste un harness con Playwright. Hoy la pregunta es la que llega antes —o la que te llega cuando te ponen a liderar el armado—: ¿con qué lo hago? Y la respuesta honesta no es una herramienta. Es un método para no volver a discutirla cada seis meses.

Playwright vs Cypress es la pregunta equivocada

Vuelve a las seis piezas de la anatomía: setup, runner, herramientas, goal, reporting y orquestación.

Cuando comparas Playwright con Cypress —o con Selenium, o con lo que salga el año que viene— estás comparando la pieza 2 y la pieza 3. El runner que descubre y ejecuta tus casos, y la capa que toca el navegador. Eso es lo que cambia entre una y otra.

Las otras cuatro se quedan de tu lado, elijas lo que elijas:

• El setup lo diseñas tú: qué estado necesita cada test y cómo se lo das sin repetir el login quince veces.
• El goal sale del negocio, no del framework. Ninguna herramienta sabe cuál es el valor esperado de tu pantalla de pagos.
• El reporting te lo dan a medias. Te regalan un HTML y un trace; qué se reporta, a quién le sirve y qué se hace con un fallo, lo decides tú.
• La orquestación —cuándo corre, con qué datos, contra qué ambiente, qué bloquea el merge— es tuya entera.

Por eso las comparativas de features no te ayudan a decidir: te muestran en detalle la parte que menos te va a doler. El equipo que fracasa automatizando casi nunca fracasa por haber elegido mal entre dos herramientas buenas. Fracasa en las cuatro piezas que ninguna comparativa menciona.

Las 5 preguntas que sí deciden

1. ¿Qué dominio estás automatizando?

Es la pregunta cero, y la que hace que el resto tenga sentido. No existe “tu stack de automatización” en singular. UI web, API, performance y mobile son cuatro problemas distintos, con cuatro capas de herramientas distintas.

El QA que busca una sola herramienta para todo termina forzando la que ya conoce a un dominio donde no encaja: tests de API escritos como si fueran de UI, pruebas de carga simuladas abriendo navegadores. Decide por dominio, y acepta que tu stack va a tener varias piezas.

2. ¿Qué lenguaje habla el equipo que la va a mantener?

Ojo con la trampa: no es el lenguaje que tú sabes. Es el que va a quedar cuando tú no estés en ese proyecto.

Si los devs escriben TypeScript y tu suite está en Java, cada arreglo pasa por ti y se vuelve un cuello de botella. Si el equipo es Java de punta a punta, una suite en JavaScript va a envejecer sola. La herramienta que el equipo puede leer es la que sobrevive.

3. ¿Dónde tiene que correr?

Acá es donde varias opciones lindas se caen solas. Tiene que correr en CI, sin interfaz gráfica, dentro de un contenedor, contra un ambiente que a veces está caído. A veces contra navegadores viejos que el cliente todavía usa. A veces en una red cerrada donde no puedes bajar lo que quieras —y esa restricción, te lo digo por experiencia, decide más que cualquier benchmark.

Una herramienta que solo brilla en tu máquina no es una opción: es una demo.

4. ¿Qué te cuesta salir?

La pregunta que casi nadie hace, y la única que te protege del error caro. No preguntes cuál es mejor hoy. Pregunta cuánto tendrías que reescribir si dentro de dos años tienes que cambiarla.

Si la respuesta es “toda la suite”, no elegiste una herramienta: te casaste. Más abajo está cómo bajar ese costo.

5. ¿Quién la mantiene y con qué ritmo?

Mira quién está detrás, cada cuánto libera versiones y qué pasa cuando reportas algo. Una herramienta abandonada es una deuda técnica con fecha de vencimiento: el día que el navegador cambie algo, tu suite se apaga y no hay a quién reclamarle.

Y una advertencia en el otro sentido: novedad no es criterio. Una herramienta de seis meses puede estar buenísima y desaparecer.

La matriz por dominio

Esto es lo que puedes llevarte hoy y usar en tu próxima discusión de stack.

Pero la columna “líder” es la menos interesante de esa tabla. Esto es lo que de verdad usas, cuándo gana la alternativa:

• UI / E2E — Cypress, si tu equipo front ya vive ahí y va a mantener los tests. Selenium, si tienes grid propia o te toca soportar navegadores viejos.
• API — REST Assured, en equipos Java de punta a punta. Y Postman con Newman cuando quien prueba no escribe código: peor para versionar, mejor para que el trabajo exista.
• Performance — JMeter, en banca y enterprise: protocolos que k6 no habla y reportes que alguien tiene que auditar.
• Mobile — Maestro, en equipos chicos que necesitan velocidad y no tienen a nadie para mantener la flakiness de Appium.

Fíjate un detalle: en la fila de API la herramienta líder es la misma de UI. No porque sea mágica, sino porque ya tienes ahí el runner y el reporting. Reutilizar dos piezas que ya funcionan suele valer más que la herramienta “ideal” para ese dominio. Eso es decidir por contexto y no por moda.

Cómo no casarte: el costo de salida

Acá está la parte accionable, y es de código.

Mira este test. Es correcto, pasa, y está casado:

test("un pago rechazado no descuenta saldo", async ({ page }) => {
  await page.goto("/pagos");
  await page.fill("#monto", "150000");
  await page.click("#pagar");
  await expect(page.locator("#saldo")).toHaveText("500.000");
});

En esas cuatro líneas hay dos tipos de conocimiento mezclados. Uno es del negocio: un pago rechazado no toca el saldo. El otro es de la herramienta: que existe un #saldo, que se llena con fill, que se afirma con toHaveText. El día que cambies de herramienta, el segundo se muere y se lleva puesto al primero.

Ahora separados:

test("un pago rechazado no descuenta saldo", async ({ page }) => {
  const pagos = new PantallaDePagos(page);
  const saldoInicial = await pagos.saldo();

  await pagos.pagar({ monto: 150000 });

  expect(await pagos.saldo()).toBe(saldoInicial);
});

El test ahora dice qué se prueba y cuál es el criterio. Cómo se toca la pantalla vive en PantallaDePagos, y esa clase es la única que sabe qué herramienta estás usando.

Sí, eso es el Page Object Model de siempre —está paso a paso en la Parte 2 de la trilogía—. Pero el POM se enseña casi siempre como una cuestión de orden. La razón fuerte es otra: es tu costo de salida. Migrar quinientos tests casados es un proyecto; migrar quinientos tests que hablan con veinte clases de pantalla es un trabajo acotado.

Con esa separación, cuando cambias de herramienta:

• Sobrevive lo caro: los criterios, los datos de prueba, el conocimiento del flujo, el reporting, el pipeline.
• Muere lo barato: selectores y sintaxis del runner.

Volviendo a esa decisión

Con esta matriz en la mano, ¿aquella decisión de Selenium estuvo mal?

No. “Es lo único que el equipo sabe usar” es la pregunta 2, y “no hay presupuesto” es una versión durísima de la pregunta 3. Las restricciones son criterios legítimos: te acotan las opciones antes de que empieces a compararlas, y eso ahorra semanas. El QA que ignora sus restricciones para elegir “lo mejor” termina con una herramienta que su equipo no puede mantener.

La pregunta que no me hice entonces fue la 4. No era cuál herramienta es mejor. Era qué me va a costar salir de esta. Nadie me la enseñó, y tampoco estaba en ninguna comparativa de las que se leían en esa época.

Es la que te dejo hecha hoy, para que no tengas que descubrirla como la descubrí yo.

Lo que quiero que te lleves

Cuando te toque elegir —o defender lo que ya eligieron— no abras una tabla de features. Haz las cinco preguntas en orden: qué dominio, qué lenguaje habla el equipo que se queda, dónde tiene que correr, qué cuesta salir y quién la mantiene. Con eso decides en una reunión lo que normalmente se discute durante un trimestre.

Y recuerda la proporción: la herramienta resuelve dos piezas de seis. Elegirla bien te ahorra trabajo; elegirla mal te cuesta una migración. Pero las cuatro piezas que deciden si tu automatización sirve o no siguen siendo tuyas en cualquier escenario.

La próxima parada baja de vuelta al teclado, con el primer dominio de la matriz que no es UI: el harness de API, donde el goal es el contrato.