En algún momento de tu carrera alguien te va a decir esta frase: “necesitamos automatizar — arma un framework desde cero”. Quizás ya te la dijeron. Y si te pasó lo que le pasa a la mayoría, la reacción fue una mezcla rara: sabes escribir un test, sabes usar la herramienta, has leído sobre Page Objects… y aun así te quedaste mirando el editor vacío sin saber por dónde entrarle.

Esa parálisis tiene mala fama. Se lee como “me falta nivel”. Y el diagnóstico es otro, mucho más reparable: no te falta habilidad, te falta el nombre de la cosa que te pidieron construir.

Te pidieron construir un harness. Solo que nadie usó esa palabra.

El encargo viene sin mapa

Fíjate en la asimetría. Cuando te piden “escribe los casos de prueba del login”, sabes exactamente qué forma tiene el resultado: una tabla, con pasos y resultados esperados. Cuando te piden “arma el framework”, ¿qué forma tiene eso? ¿Una carpeta? ¿Cuántos archivos? ¿Qué va primero?

El encargo llega sin mapa porque quien lo hace tampoco suele tenerlo. “Framework de automatización” funciona como una palabra-nube: todos la usan, cada uno imagina algo distinto, y nadie la baja a piezas. Así que el QA que la recibe hace lo único que puede hacer con una nube: darle vueltas.

En la primera parada de esta serie recuperamos la palabra exacta para esa cosa: harness. El arnés que rodea a lo que se ejecuta: prepara las condiciones, dispara la acción, observa y registra el resultado. Tu “framework de tests” es eso. No es una nube — es un arnés con partes.

La parálisis frente al “framework desde cero” no es falta de habilidad. Es intentar construir algo que todavía no tiene bordes en tu cabeza.

Lo que cambia cuando la cosa tiene nombre

Puede sonar a detalle semántico. No lo es, y te lo muestro con la cadena completa:

Cuando la cosa tiene nombre, tiene bordes → Cuando tiene bordes, tiene piezas → Cuando tiene piezas, hay un orden para construirlas → Cuando hay orden, desaparece la parálisis

“Framework” no te da nada de eso, porque significa demasiadas cosas. “Harness” sí, porque describe una función: rodear al sistema bajo prueba para ejecutarlo en condiciones controladas y observarlo. De esa función salen las piezas solas — algo tiene que preparar el estado, algo tiene que disparar los casos, algo tiene que definir qué es “correcto”, algo tiene que contarte qué pasó.

¿Te suena? Es la misma jugada que hace un buen QA con un requerimiento vago: no se pone a escribir casos sobre la nube — primero le pone bordes, después la desarma en escenarios. Lo que haces con las historias de usuario, hazlo con tu framework.

Trabajando como consultora me tocó armar arquitecturas de automatización desde cero para varios clientes, y el patrón se repetía: el pedido nunca era el problema. El problema era que el equipo llevaba meses “por empezar el framework” porque nadie podía decir qué era terminarlo. La conversación que destrababa todo no era técnica — era ponerle bordes: “esto que quieren se llama harness, tiene estas partes, empecemos por esta”. Ahí la montaña se volvía lista de tareas.

Las piezas, a vuelo de pájaro

No te voy a dar la anatomía completa acá — le toca su propia pieza a fondo, la siguiente de la serie. Pero para que veas que la nube tiene forma, el arnés se sostiene sobre cosas como estas:

  • Algo que prepara el estado — datos, sesión, ambiente conocidos (tus fixtures).
  • Algo que dispara los casos — el runner y su configuración.
  • Algo que define “correcto” — el oráculo, tus assertions (el goal verificable, ¿te acuerdas?).
  • Algo que te cuenta qué pasó — reporting, evidencia, observabilidad.

Cuatro funciones, no cuatro archivos. Playwright, Selenium, Cypress, k6 o Appium las implementan distinto, pero todas las herramientas resuelven las mismas funciones — por eso el modelo te sirve aunque mañana cambies de stack.

Y guarda este dato, porque vuelve más adelante: estas funciones no solo envuelven a tu código bajo prueba. En la primera parada te conté que también armé un arnés alrededor de mi agente de IA — mismas piezas, otro ejecutante. Hay una parada entera de esta serie dedicada a construirlo paso a paso.

Por qué esto no es la guía de la trilogía

Si lo que necesitas hoy es el paso a paso — qué instalar, cómo estructurar, cómo escalar — eso ya está escrito en la serie De QA manual a automatización, y su Parte 2 entra de lleno en arquitectura y pipeline. Esta pieza te da lo que esa serie da por sentado: el modelo mental que hace que esos pasos tengan sentido.

Por dónde se empieza de verdad

Y acá va lo contraintuitivo, porque el instinto de casi todo el mundo es empezar eligiendo herramienta. Semanas comparando Playwright contra Cypress, leyendo benchmarks, mirando videos. Es la procrastinación con mejor disfraz que existe: se siente trabajo, y no construye nada.

Esto es lo que hago yo, paso a paso, cuando arranco un harness desde cero:

Paso 1 — Escribe una frase. Antes de instalar nada, abre un archivo y escribe qué significa “el primer pedazo está terminado”. Concreto, verificable, de un solo flujo:

El flujo de login corre en verde, y cualquiera del equipo lo ejecuta con npm test.

Esa frase es tu goal. Fíjate que no dice “framework completo” ni “cobertura del regression” — dice UN flujo, UN comando, UN resultado observable. Sabes exactamente cuándo lo lograste, y cabe en una semana tranquila.

Paso 2 — Elige la herramienta en una hora, no en tres semanas. La que tu equipo ya conoce; si nadie conoce ninguna, la líder del dominio (en web hoy: Playwright; Selenium y Cypress también resuelven). La elección pesa menos de lo que crees — acabas de ver que todas implementan las mismas cuatro funciones. Cambiar de herramienta después es trabajo; no arrancar nunca no se arregla con benchmarks.

Paso 3 — Construye SOLO lo que esa frase exige. Y acá está la magia del goal bien elegido: para cumplirlo, no te queda otra que crear una versión mínima de cada pieza del arnés. En archivos reales, tu primer harness es más o menos esto:

mi-harness/
├── playwright.config.ts    ← el runner: qué corre y contra qué URL
├── .env                    ← el estado: el usuario de prueba (nunca hardcodeado)
├── tests/
│   └── login.spec.ts       ← el caso, con su oráculo: expect(page).toHaveURL("/dashboard")
└── package.json            ← el comando: "test": "playwright test"

Cuatro archivos. Nada de carpetas pages/, utils/, helpers/ todavía — eso llega cuando el segundo y tercer flujo lo pidan. El reporte ya te lo regala la herramienta (playwright show-report): esa es la cuarta función, cubierta gratis.

Paso 4 — Haz que otra persona lo corra. Cuando alguien de tu equipo clona el repo, corre npm test y ve el verde sin preguntarte nada, tu goal está cumplido. Eso — no “elegí la herramienta” — es tener un harness. Embrionario, pero completo y vivo.

Después creces desde ahí: segundo flujo, fixtures compartidas, Page Objects, CI. Pero ya no estás frente a la montaña — le estás agregando piezas a algo que existe y corre.

1 Frase que define 'terminado'
4 Archivos en tu primer harness
0 Semanas comparando herramientas

Si el framework ya existe, esto también te sirve

Sin humo: la mayoría de los QA no van a construir un framework desde cero — van a heredar uno. Entrar a un equipo con una suite ya armada, escrita por gente que quizás ya no está, y tener que moverse ahí adentro.

El modelo te sirve igual, con otra pregunta: en vez de “¿por dónde empiezo?”, es “¿dónde está cada pieza?”. Recorre la suite heredada buscando las funciones: ¿dónde se prepara el estado? ¿qué dispara los casos? ¿dónde viven los oráculos? ¿qué me cuenta los resultados? En una tarde tienes el mapa de un codebase que antes era territorio ajeno — y de paso encuentras las piezas que faltan, que en las suites heredadas suele ser reporting o datos de prueba.

Leer un framework como harness es la diferencia entre “acá hay mil archivos” y “acá están las cuatro funciones, implementadas así”.

Lo que quiero que te lleves

La próxima vez que escuches “arma un framework desde cero” — o que te toque heredar uno — ya no es una nube. Es un harness: un arnés con funciones concretas que puedes nombrar, ubicar y construir en orden, empezando por un goal verificable de un solo flujo.

El nombre no es decoración. Es el mapa.

Nadie se paraliza por falta de habilidad frente a algo que puede nombrar, desarmar y ordenar. La parálisis era la nube. El harness es el mapa.

En la próxima parada desarmamos el arnés entero: la anatomía completa de un harness — las piezas que toda herramienta comparte, mapeadas en Playwright, k6 y Appium para que veas que son las mismas en UI, performance y mobile. Con eso vas a poder evaluar cualquier framework — el tuyo o el heredado — con una checklist concreta.

Y con la anatomía en la mano, viene la parada que te adelanté más arriba: construir el harness de tu agente de IA. Las mismas piezas que le pusiste a tu framework de tests, envolviendo esta vez a tu agente — herramientas, método, reglas — para que deje de ser un chat que responde suelto y pase a ser un compañero de QA que diriges. Paso a paso, con lo que ya sabes de esta serie.