Crear un framework de automatización para QA suena simple cuando lo decís rápido.
“Armemos una base común para que los devs puedan escribir tests y nos ayuden con la calidad”.
Hermoso. Ordenado. Madurísimo.
Hasta que te sentás a hacerlo y te das cuenta de que no estás escribiendo un par de helpers. Estás construyendo una herramienta que otra gente tiene que entender, confiar, usar y mantener sin odiarte en el proceso.
Ahí cambia todo.
Un framework no es una carpeta con utilidades
El primer error es pensar que un framework de QA es una estructura de carpetas con pages, steps, fixtures y algunos comandos lindos en el package.json.
Eso puede ser el inicio. No es el framework.
Un framework real tiene decisiones tomadas:
- Cómo se escriben los tests.
- Cómo se nombran los escenarios.
- Cómo se crean y limpian datos.
- Cómo se espera por estados reales sin llenar todo de sleeps.
- Cómo se reportan los errores.
- Cómo se debuggea cuando algo falla en CI.
- Qué cosas se abstraen y qué cosas conviene dejar explícitas.
Y cada una de esas decisiones tiene costo.
Si abstraés poco, los devs repiten lógica y cada test termina escrito de una forma distinta. Si abstraés demasiado, nadie entiende qué está pasando y el framework se transforma en una caja negra que solo QA se anima a tocar.
Ese equilibrio es difícil. Y no se resuelve con entusiasmo.
El usuario del framework no sos vos
Esta es la parte que más cuesta aceptar.
Cuando armás un framework para ayudar a aplicar calidad, tu usuario no sos vos. Tu usuario es el dev que está en medio de una feature, con presión de entrega, contexto parcial y cero ganas de pelearse con una herramienta que no entiende.
Si para escribir un test tiene que preguntarte tres veces qué helper usar, el framework falló.
Si el error dice Timeout 30000ms exceeded y no explica qué condición de negocio no se cumplió, el framework falló.
Si la documentación está desactualizada o depende de “preguntale a QA”, el framework falló.
Y ojo: no falló porque esté mal programado. Falló porque no fue diseñado como producto.
Un framework interno también necesita experiencia de usuario. No tiene botones lindos, pero tiene API, nombres, mensajes de error, ejemplos, convenciones y caminos felices. Todo eso comunica.
La adopción no se impone
Podés tener el mejor framework del mundo, pero si los devs sienten que es una obligación burocrática, no lo van a adoptar de verdad.
Van a copiar un test existente, cambiar dos textos, hacer que pase y seguir con su vida.
Eso no es calidad compartida. Es cumplimiento mínimo.
Para que un dev use un framework de QA con ganas, tiene que sentir que le resuelve un problema real:
- Le da feedback rápido.
- Le evita romper flujos críticos.
- Le muestra errores entendibles.
- Le permite escribir tests sin conocer toda la cocina interna.
- Le baja la fricción para validar lo que está construyendo.
La adopción aparece cuando la herramienta ayuda más de lo que molesta.
Y esto parece obvio, pero muchos frameworks internos nacen al revés: pensados desde lo que QA necesita controlar, no desde lo que el dev necesita para colaborar.
Calidad compartida no significa tirarles trabajo a los devs
Hay una confusión bastante peligrosa con esto.
Decir “los devs también tienen que escribir tests” no puede significar “QA ahora arma una plataforma y los devs se arreglan”.
Eso no es shift-left. Eso es mover el problema de escritorio.
Calidad compartida significa que QA diseña caminos para que el equipo pueda validar mejor. Significa acompañar, explicar criterios, revisar escenarios, discutir riesgos y construir herramientas que acerquen la calidad al momento donde se toma la decisión técnica.
El framework es una parte de eso. No reemplaza la conversación.
De hecho, si el framework necesita reemplazar la conversación, ya arrancó mal. Porque ningún helper va a decidir por sí solo qué riesgo de negocio importa, qué escenario merece cobertura o qué comportamiento es crítico para el usuario.
Eso requiere criterio. Y el criterio se entrena trabajando juntos.
La documentación no es un extra
La documentación de un framework de QA no es el README que escribís al final cuando ya estás cansado.
Es parte del producto.
Si querés que otros lo usen, necesitás explicar:
- Cómo crear el primer test.
- Qué patrón seguir.
- Qué no hacer.
- Cómo correrlo localmente.
- Cómo interpretar un fallo.
- Cómo agregar datos de prueba.
- Cuándo pedir ayuda.
Y tiene que estar escrito para alguien que no vive adentro del framework todos los días.
Esto es clave. Cuando vos lo construiste, todo te parece obvio. Sabés por qué existe cada abstracción, por qué un fixture se llama así, por qué un step no debería tocar un selector directo, por qué un test tiene que limpiar lo que ensucia.
El dev no tiene ese contexto.
Entonces, si no lo documentás, no estás evitando documentación. Estás transfiriendo deuda a conversaciones repetidas, malos usos y tests frágiles.
La confianza se gana en los fallos
Un framework de automatización no se mide solo cuando todo está verde.
Se mide cuando algo falla.
Cuando un test falla, el dev debería poder entender rápido tres cosas:
- Qué comportamiento se esperaba.
- Qué comportamiento ocurrió.
- Dónde mirar para resolverlo.
Si cada fallo requiere que QA investigue, mire videos, revise logs, reproduzca localmente y traduzca el error, el framework no está ayudando al equipo. Está centralizando dependencia.
Y esa dependencia es peligrosa, porque termina reforzando lo mismo que querías romper: QA como cuello de botella.
La confianza se construye cuando el framework falla claro. Cuando el reporte dice algo útil. Cuando los screenshots sirven. Cuando los traces cuentan una historia. Cuando el test rojo no es un misterio, sino una señal.
Un buen framework no solo ejecuta tests. Enseña a leer el sistema.
Mantenerlo es más difícil que crearlo
Crear la primera versión suele ser la parte divertida.
Elegís herramienta, armás estructura, escribís ejemplos, automatizás un flujo crítico y sentís que estás ordenando el mundo.
Después llega la realidad.
Cambian pantallas. Cambian APIs. Cambian datos. Cambia el producto. Cambia el equipo. Aparecen casos raros. Un test empieza a fallar solo en CI. Otro tarda demasiado. Otro quedó obsoleto pero nadie sabe si borrarlo. Un helper creció hasta parecer un framework adentro del framework.
Ahí se ve si la arquitectura era buena o si solo estaba prolija.
Un framework de QA necesita mantenimiento como cualquier producto serio:
- Refactors.
- Deprecaciones.
- Versionado de convenciones.
- Limpieza de tests inútiles.
- Revisión de patrones.
- Feedback de quienes lo usan.
Si nadie se hace cargo de esa evolución, el framework se pudre. Y cuando se pudre, los devs dejan de confiar. Y cuando dejan de confiar, vuelven a validar a mano, o peor: dejan de validar.
Lo difícil no es que funcione, es que sobreviva
Hacer que un framework corra tests es relativamente fácil.
Hacer que un equipo lo use bien durante meses, sin convertirlo en una trampa de abstracciones, documentación vieja y errores ilegibles, es otra historia.
Ahí está la dificultad real.
Porque no estás construyendo solo código. Estás construyendo una forma de trabajar.
Y una forma de trabajar tiene que ser clara, repetible, enseñable y suficientemente flexible para no romperse con el primer cambio de producto.
Por eso crear un framework de QA para devs es tan difícil: porque te obliga a pensar como QA, como arquitecto, como usuario interno, como docente y como mantenedor.
Todo al mismo tiempo.
Lo que intento recordar cuando construyo uno
No tengo una receta perfecta. Pero sí tengo algunas reglas que me ayudan a no perder el norte.
Menos magia, más claridad. Si una abstracción ahorra tres líneas pero oculta el comportamiento importante, probablemente no vale la pena.
Errores pensados para humanos. Un fallo tiene que explicar el problema, no solamente escupir un stack trace.
Ejemplos antes que discursos. La mejor documentación de un framework suele ser un test real, corto, bien nombrado y fácil de copiar sin romper todo.
Convenciones pocas, pero firmes. Si todo es opinable, cada test se escribe distinto. Si todo está prohibido, nadie puede avanzar. El equilibrio importa.
Feedback temprano de devs. No esperes a tener “la versión final” para mostrarlo. Si los devs no entienden la API en los primeros usos, esa información vale oro.
Calidad como acompañamiento, no como policía. El framework debería invitar a validar mejor, no hacer sentir que QA está auditando cada movimiento.
Al final, el framework es una excusa
Sí, necesitamos buenas herramientas. Necesitamos tests confiables, patrones claros, datos controlados, reportes útiles y pipelines que den feedback rápido.
Pero el objetivo no es tener “el framework”.
El objetivo es que la calidad deje de aparecer tarde.
Que el dev pueda validar mejor mientras construye. Que QA pueda enfocarse en riesgos reales y no en repetir chequeos mecánicos. Que el equipo tenga un lenguaje común para hablar de comportamiento, cobertura y confianza.
Si el framework ayuda a eso, vale la pena.
Si se convierte en una torre técnica que solo entiende quien la creó, no importa qué tan elegante sea por dentro. No está cumpliendo su función.
Porque aplicar calidad no se trata de poner más capas entre el equipo y el producto.
Se trata de sacar fricción para que todos puedan cuidar mejor lo que están construyendo.