Por qué tu suite de pruebas se rompe en cada sprint

La escena es conocida. Sale una versión, la siguiente ejecución vuelve en rojo y alguien se pasa la mañana separando los fallos reales del ruido. Casi siempre, el producto funciona: alguien renombró una clase, una página tardó un segundo más, dos pruebas compartían una cuenta o la preproducción estaba a mitad de un despliegue. La suite no encontró bugs. Encontró cambios.

Las pruebas end-to-end comprueban el producto como lo usa un cliente. Eso es lo que las hace valiosas, y también frágiles: dependen de todo a la vez. Las causas rara vez son un misterio. Parte de las soluciones son herramientas; la mayoría, hábitos.

Selectores atados a la estructura de la página

Un script de prueba encuentra los elementos según cómo está construido el código: una ruta CSS, un nombre de clase generado, el tercer botón de un formulario. Nada de eso es lo que ve el usuario. Una refactorización que no cambia nada para los clientes, como una nueva librería de componentes o un botón que pasa a un diálogo, rompe la prueba de todos modos.

Los buenos equipos tratan los localizadores como un contrato. Apuntan a lo que percibe el usuario, un rol y un nombre accesibles o una etiqueta visible, añaden atributos de prueba donde no hay nada estable y mantienen cada localizador en un único sitio. Funciona, pero exige disciplina a todos los equipos de front, y sigue rompiéndose en cuanto se rediseña un flujo.

Esperar un tiempo en lugar de esperar a la página

Las pausas fijas son el otro clásico. Una pausa de tres segundos es demasiado larga en un día tranquilo y demasiado corta en un runner de CI saturado. Los fronts modernos añaden sus propias condiciones de carrera: un botón que aparece antes de que su manejador esté conectado, una lista que se rellena tarde, un mensaje que desaparece antes de la aserción.

La solución es esperar una condición, nunca una duración: el elemento visible y habilitado, la respuesta recibida, el texto en pantalla. Y antes de ampliar un tiempo de espera, mira la página. Un paso que necesita ocho segundos es un problema de rendimiento, y tus usuarios también esperan.

Un agente tampoco hace rápida una página lenta: en Qalion, una ejecución que supera su límite de tiempo termina como Error, con el motivo «Tiempo agotado».

Datos que las pruebas comparten

Muchas pruebas inestables son problemas de datos disfrazados. La prueba B espera el carrito que llenó la prueba A. Un código promocional solo sirve una vez. Lanza la suite en paralelo y dos pruebas modifican el mismo usuario a la vez. El resultado es el fallo más desconcertante que hay: la prueba pasa sola y falla dentro de la suite.

Los buenos equipos hacen que cada prueba sea dueña de sus datos. Cada una crea lo que necesita, con valores únicos en cada ejecución, o usa una cuenta que nadie más toca, y nunca depende de que otra prueba se haya ejecutado antes. Preparar el estado con una API o un script de carga inicial es más rápido y más fiable que hacer clic por la interfaz.

Qalion cubre una parte de esto. Los conjuntos de datos aportan los valores de un caso, por entorno si hace falta, y las columnas secretas le dan al modelo un marcador en lugar de la credencial. Cada ejecución arranca en un navegador limpio, así que las cookies y el almacenamiento no pasan de una prueba a otra. Eso sí, Qalion no restablece tu base de datos: dos ejecuciones que usan la misma cuenta al mismo tiempo seguirán chocando.

Entornos y servicios que no controlas

La preproducción rara vez es una copia de producción. Los feature flags difieren, la configuración se desvía, otro equipo despliega a mitad de la ejecución, un banner de consentimiento solo aparece en un entorno, una zona horaria hace fallar una prueba cerca de la medianoche. Y luego están los servicios que no gestionas tú, desde los sandboxes de pago hasta los mapas, los captchas o el envío de correos: cualquiera puede ir lento o estar caído el día que pruebas.

Los buenos equipos hacen del entorno parte del resultado. Cada ejecución registra el entorno y la build contra los que se lanzó, los flags se fijan por entorno, los despliegues se coordinan con las ejecuciones y un servicio que no se está probando se simula. Sobre todo, separan «el sitio no respondió» de «el producto no funciona».

Qalion marca esa frontera en sus veredictos. Fallida significa que el agente juzgó que la aplicación no hacía lo esperado. Error significa que nunca llegó a un veredicto: sitio inaccesible, tiempo agotado, agente bloqueado. Los errores quedan fuera de las tasas de éxito. Las cookies, elementos de almacenamiento, cabeceras y credenciales de autenticación básica que necesita un sitio se aplican por código antes de que cargue la primera página, y cada ejecución conserva su registro de red y la consola del navegador.

Nada de esto vuelve estable un entorno inestable. Si la preproducción se cae dos veces por semana, lo que hay que arreglar es la preproducción.

Pruebas que graban clics en lugar de intenciones

Un script grabado captura cómo se recorrió un flujo, no por qué. «Haz clic en el tercer botón, escribe en el segundo campo» no le dice a nadie qué protege la prueba, así que cada fallo empieza con un trabajo de arqueología. Las aserciones también lo sufren: unas no comprueban nada y otras comparan una página entera y fallan ante cualquier cambio.

Los buenos equipos escriben un comportamiento por prueba y hacen que cada resultado esperado sea algo que una persona pueda ver: un mensaje, un encabezado, un total. Los pasos dicen lo que hace el usuario, «añadir las zapatillas azules al carrito», y la mecánica se queda fuera de la prueba.

Aquí es donde un agente cambia más las cosas. Un caso de prueba de Qalion se escribe en lenguaje natural, como pasos, un escenario Gherkin o texto libre. En cada paso, el agente mira una captura de la página con los elementos interactivos marcados, elige el que describe el paso y actúa; después compara la página con el resultado esperado y registra un veredicto. Así, las clases e ID renombrados, los elementos movidos y la mayoría de refactorizaciones que conservan la intención del usuario ya no rompen el caso.

Eso es lo que significa la autorreparación en Qalion, y tiene un límite deliberado: se ocupa de cómo se encuentra un elemento, nunca de lo que hace el producto. Un total de pedido incorrecto sigue fallando. Si el flujo cambia, por ejemplo con un nuevo paso obligatorio, hay que actualizar el caso: lo haces tú, o lo propone Qalion AI y espera tu aprobación. Y cada veredicto llega con lo necesario para comprobarlo: una captura por paso, un vídeo y el registro de acciones del agente.

Fallos de los que nadie se ocupa

La última causa no es técnica. Cuando un resultado en rojo no tiene responsable, la gente vuelve a ejecutar hasta que sale verde, los reintentos esconden la inestabilidad y los fallos conocidos se acumulan. Luego un bug de verdad pone la build en rojo y nadie reacciona, porque el rojo ya no significa nada.

Los buenos equipos asignan a cada fallo un responsable en el mismo día, y una causa: bug del producto, prueba, datos o entorno. Las pruebas inestables se ponen en cuarentena a la vista de todos, con un nombre y una fecha límite, en lugar de reintentarlas en silencio. Los problemas conocidos llevan un motivo y una fecha de caducidad.

Qalion está construido en torno a esa rutina:

• Las ejecuciones fallidas no se reintentan automáticamente. Volver a ejecutar crea un nuevo intento dentro de la misma ejecución, y los intentos anteriores se conservan como evidencias.
• Los fallos se agrupan en problemas por caso de prueba, paso fallido y tipo de fallo, y la IA se ocupa del resto. Diez ejecuciones en rojo por un mismo bug son un solo problema, con un responsable, un estado y una categoría, como bug del producto, datos de prueba o entorno.
• Una prueba se marca como inestable cuando alterna entre éxito y fallo dos veces o más en sus diez últimas ejecuciones, en cuanto reúne al menos seis veredictos. Una prueba en cuarentena sigue ejecutándose, pero deja de contar en las tasas de éxito. Estas cifras salen de reglas fijas, no de la IA.
• Cuando una causa no está clara, un análisis con IA lee las evidencias, incluida la última ejecución correcta, y cita en qué se apoya.

Por dónde empezar

Cuenta antes de arreglar. Toma los cinco flujos que más se rompen, normalmente el inicio de sesión, el pago y tu formulario principal, ejecútalos cada día durante dos semanas y etiqueta cada resultado en rojo: bug del producto, prueba, datos o entorno. La proporción de bugs reales es la medida honesta de tu suite. La mayor de las demás categorías te dice dónde concentrar el esfuerzo primero.

Si son los datos, dale a cada prueba los suyos. Si es el entorno, arregla el entorno. Si son los localizadores y los scripts, reescribe esos flujos como intenciones. Y asigna un responsable a cada fallo desde el primer día.

Un agente que lee la página elimina una categoría de ruido, el localizador roto, y hace más visibles las demás. No vuelve estable un entorno inestable, y nunca debería poner en verde una regresión real.