Qué hace bajar el ratio en las pruebas automatizadas de UI
Selectores
Un rediseño que no cambia nada funcional pone la suite en rojo.
Ahí se va la mayor parte del tiempo de mantenimiento.
Esperas
Las esperas fijas son lentas y aun así inestables. Una espera correcta necesita saber qué está esperando.
La mayor parte de la inestabilidad viene de aquí.
Cobertura escrita a mano
Cubres lo que alguien escribió, es decir, los flujos interesantes y no los que se rompen.
Los selectores y las esperas generan fallos que no son bugs. Cada uno de ellos consume un poco de la disposición del equipo a revisar el siguiente build en rojo.
El momento en que una suite muere
Normalmente se identifica en retrospectiva: la semana en que alguien dijo «vuelve a ejecutarla» y tenía razón. A partir de ahí, relanzar es la primera respuesta ante cualquier fallo, y una regresión real se vuelve a ejecutar hasta que pasa por suerte o acaba en cuarentena.
Nadie decide dejar de confiar en la suite. La confianza se erosiona.
Cómo proteger el ratio
Arregla las pruebas inestables antes de añadir otras nuevas. Impopular, pero correcto. Una prueba nueva añadida a una suite que nadie mira no tiene ningún valor.
Pon en cuarentena a la vista de todos, no en silencio. Una prueba omitida debe ser visible y tener responsable; si no, la lista de omitidas se convierte en el lugar donde las pruebas van a morir.
Trata cada reejecución como un hallazgo. Si una prueba necesitó volver a ejecutarse, algo falla en la prueba o en el entorno. Regístralo en lugar de seguir adelante.
La parte estructural
La disciplina resuelve los selectores y las esperas. No resuelve el tercer costo: la cobertura está limitada por lo que alguien puede escribir, y el producto crece más rápido que eso, sobre todo cuando buena parte del código llega de un agente de programación.
Los pasos expresados como intenciones, y no como rutas por el DOM, eliminan de raíz buena parte de los fallos de selectores, que son el mayor factor individual de ese ratio.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
La misma configuración está disponible en el dashboard de TestSprite si prefieres no instalar nada en local. El resto de la superficie del CLI está en el repositorio del CLI.
Cómo recuperar un ratio deteriorado
Si la suite ya está en el punto en el que la gente relanza en vez de investigar, aplicar disciplina de aquí en adelante no lo arregla, porque el ruido que ya existe sigue reforzando el hábito. Recuperarla exige un reinicio deliberado.
Toma los últimos cincuenta fallos y clasifica cada uno como real, de selector, de tiempos o de entorno. Esa hora te dice cuál de los tres costos tienes en realidad, y suele estar concentrado en uno solo en lugar de repartido. Corrige esa categoría en toda la suite en vez de ir arreglando pruebas a medida que fallan.
Después pon en cuarentena todo lo que siga fallando, con responsable y fecha, y deja que el resto de la suite quede en verde. Una suite pequeña y en verde en la que el equipo confía vale más que una grande y en rojo que ha aprendido a ignorar, y es el único estado desde el que el ratio puede mejorar.
Ejecútala donde los fallos cuestan menos
En cada pull request, para que un fallo apunte a un solo cambio y no a una semana de cambios.
La GitHub App es un webhook que configuras en el dashboard de TestSprite. Escucha el evento de despliegue que tu pipeline ya genera, así que nada cambia en tu repositorio.
GitHub Actions coloca el paso dentro de tu propio workflow, configurado desde la terminal.
Cómo protege TestSprite el ratio
De forma directa: eliminando la mayor fuente de fallos falsos. Los pasos son intenciones y no localizadores, así que los cambios cosméticos que provocan la mayoría de las roturas de selectores no generan builds en rojo. La espera está resuelta en lugar de ser un ejercicio de ajuste prueba por prueba, lo que elimina casi todo el resto.
La cobertura se genera a partir de tu producto y se refina en lenguaje natural, así que ampliar la suite no implica aumentar el mantenimiento en la misma proporción, que es lo que normalmente obliga a elegir entre cobertura y confianza.
El resultado es una suite en la que un fallo sorprende. Ese es el estado en el que la gente investiga en lugar de relanzar, y el único desde el que la cobertura puede seguir creciendo sin que todo acabe convirtiéndose en decoración sin que nadie lo note.
¿Qué tasa de éxito deberíamos esperar?
Lo bastante alta como para que un build en rojo sorprenda. Si los fallos son rutina, la suite está informando sobre sí misma y no sobre el producto.
¿Cómo arreglamos las pruebas inestables?
Averigua si es un selector o una espera. Los selectores necesitan anclas estables; las esperas necesitan esperar por un estado. Hay una tercera categoría: un entorno realmente inestable, que no se arregla cambiando pruebas.
¿Vale la pena eliminar pruebas antiguas?
Sí. Una prueba en la que nadie confía y que nadie mantiene es un costo sin beneficio. Borrarla es mejor que omitirla.
¿La suite debería bloquear los merges?
Cuando el ratio sea sano, sí. Antes de eso, bloquear merges con una suite poco fiable solo enseña a la gente a saltársela.
¿Cómo medimos esto?
Lleva la cuenta de cuántos fallos resultan ser reales. Si nadie conoce ese número, ese es justamente el hallazgo.
La cobertura no es el número que importa.
Las pruebas automatizadas de UI viven o mueren según la proporción de builds en rojo que son bugs reales. Arregla las pruebas inestables antes de añadir otras nuevas, trata cada reejecución como un hallazgo y usa pasos basados en intenciones para eliminar los fallos de selectores que erosionan la confianza.