Análisis de estabilidad de las pruebas
Dado que las pruebas se utilizan para determinar la calidad de tu proyecto, es bastante importante que las pruebas mismas sean estables.
El comportamiento inestable de una prueba puede interferir con los resultados de las pruebas, haciendo que todo el informe sea menos confiable y causando "fatiga de alarma" en el equipo de QA. También puede tener un impacto negativo medible en la productividad del equipo, ya que el tiempo que se dedica a perseguir errores inexistentes no se destinará a errores reales.
Idealmente, cada prueba debería ser consistente: debería arrojar un estatus diferente solo cuando el sistema bajo prueba se comporte de manera diferente. Cuando una prueba falla, deberías ser capaz de reflejar esto en las prioridades de tu equipo inmediatamente, en lugar de esperar que la prueba pase la próxima vez.
Allure Report te ayuda a encontrar pruebas potencialmente inestables asignándoles marcas de inestabilidad de prueba. Hay 5 tipos de marcas de inestabilidad: Inestable, Nuevo fallido, Nuevo aprobado, Nuevo roto y Reintento.
Las marcas se muestran junto a las pruebas en los árboles y en el panel de detalles. También puedes filtrar las pruebas por sus marcas.
Pruebas inestables
La marca Inestable se agrega automáticamente a una prueba si se cumplen todas las siguientes condiciones:
- la prueba obtuvo el estatus de Fallida en algún momento dentro de los últimos 5 lanzamientos,
- la prueba obtuvo el estatus de Pasada al menos una vez desde entonces,
- la prueba obtuvo el estatus de Fallida o Rota en el último lanzamiento.
El historial de pruebas debe estar habilitado para que Allure Report agregue esta marca. Algunos adaptadores de Allure también proporcionan una forma de marcar manualmente una prueba problemática como Inestable, consulta la documentación de tu adaptador de Allure.
Para tratar con pruebas inestables en tu proyecto, recomendamos un proceso de 4 pasos: investigar todo, arreglar lo que se pueda arreglar, reintentar el resto y seguir monitoreando.
Investigar por qué las pruebas son inestables.
Una prueba inestable puede indicar una amplia gama de problemas con el código de la prueba, el entorno de prueba o el producto mismo. Diversas herramientas en Allure Report pueden ayudarte en el análisis de los resultados de las pruebas.
En la pestaña Comportamientos o Suites, haz clic en Mostrar resultados de pruebas inestables para ver qué características o suites contienen más pruebas inestables que otras. Por ejemplo, si la mayoría de las pruebas inestables están relacionadas con una característica recientemente introducida en tu aplicación, puede que necesites investigar esta característica más a fondo.
En la pestaña Categorías, haz clic en Mostrar resultados de pruebas inestables para ver si las pruebas inestables tienen mensajes de error y trazas de pila similares o no. Por ejemplo, si ves el mismo error de tiempo de espera en diferentes pruebas inestables, puede ser causado por un servidor externo no disponible y no por problemas específicos de la prueba.
Para pruebas individuales que no forman parte de tendencias más grandes, considera usar pasos y archivos adjuntos para reducir los momentos en que algo sale mal durante la ejecución.
Si es posible, arreglar la fuente de la inestabilidad.
Una vez que se detecte la fuente de la inestabilidad, recomendamos invertir tus recursos en solucionarla. Esto es importante incluso para errores menos críticos, ya que la incapacidad de ejecutar la prueba de manera confiable puede evitar que encuentres un problema más crítico en el futuro.
Si la inestabilidad es causada por el código de la prueba o el entorno, arreglarlo puede implicar reorganizar la prueba, reescribir algunas aserciones, introducir servidores simulados o dobles en lugar de servicios externos de los que depende la prueba, etc. Cuando diferentes pruebas tienen una gran base de código común, es posible que el problema subyacente mejore múltiples pruebas a la vez. Implementar todos los cambios puede tomar algo de tiempo, pero también puede ahorrar mucho tiempo en el futuro, ya que el equipo no tendrá que analizar nuevamente este resultado de prueba inestable.
A veces, la fuente de inestabilidad es el producto mismo. Por ejemplo, las pruebas inestables pueden aparecer debido a fugas de memoria o carreras de datos. Si no puedes solucionar el problema ahora, intenta reproducirlo de manera confiable. Puede que necesites escribir una nueva prueba para eso. De esta manera, incluso cuando todas las pruebas inestables parezcan “verdes” en un informe futuro, al menos verás un resultado de prueba “rojo” para informarte que el problema sigue presente.
Si la prueba sigue siendo inestable, habilitar reintentos.
Si no puedes solucionar la fuente de la inestabilidad ahora mismo, considera habilitar un mecanismo de reintentos automáticos. Por ejemplo, configúralo para ejecutar la prueba hasta 5 veces cuando falle, aumentando así las probabilidades de que la prueba inestable pase, lo que ahorrará tiempo en futuros análisis de pruebas. Por ejemplo, si tu prueba intenta conectarse a un servidor externo y recibe un error de tiempo de espera, probablemente sea causado por un problema temporal que podría resolverse cuando reintentes la prueba en unos segundos.
Muchos marcos de pruebas proporcionan anotaciones fáciles de usar o construcciones similares para configurar las pruebas fallidas para que se reintenten automáticamente cuando fallen.
Cuando reintentas la prueba completa, su estatus de prueba se determinará por el último intento, con otros intentos disponibles a través de la pestaña de reintentos. Alternativamente, implementa una lógica de reintento solo para la parte inestable de tu prueba, registrando cada intento con un estatus de paso. De esta manera, la prueba solo tratará con fuentes conocidas de inestabilidad y no ocultará una que aún sea desconocida.
Seguir monitoreando tus pruebas inestables.
En cada informe de prueba, asegúrate de analizar todas las pruebas inestables, incluso aquellas que ya analizaste en informes anteriores. Por ejemplo, es posible que previamente una prueba fallara temprano debido a un servicio no disponible, pero ahora falle por una causa completamente diferente, y es importante analizar la nueva causa. Considera definir categorías personalizadas para distinguir entre causas conocidas y desconocidas.
Nuevas pruebas fallidas
La marca Nueva fallida se agrega automáticamente a una prueba Fallida si tuvo cualquier otro estado en el lanzamiento anterior.
Debe habilitarse el historial de pruebas para que Allure Report agregue esta marca.
Cuando te enfrentas a una prueba Nueva fallida, comienza revisando los cambios recientes en el código del producto, el código de la prueba, sus dependencias o los recursos externos de los que dependen. Ve a la pestaña de Categorías para ver si el nuevo problema es único o común entre diferentes pruebas.
Si el problema parece ser causado por un cambio, trátalo como un defecto e intenta corregirlo si es posible.
Si el problema no está relacionado con cambios recientes, esto básicamente significa que la prueba está en camino de ser reconocida como Inestable. Una buena manera de comenzar la investigación es ejecutando la prueba nuevamente (por ejemplo, en tu computadora local). Verifica si falla consistentemente, y si no es así, consulta las recomendaciones para Pruebas inestables.
Nuevas pruebas pasadas
La marca Nueva pasada se agrega automáticamente a una prueba Pasada si tuvo cualquier otro estado en el lanzamiento anterior.
Debe habilitarse el historial de pruebas para que Allure Report agregue esta marca.
Cuando aparece inesperadamente, las pruebas Nuevas pasadas generalmente deben generar las mismas preocupaciones que las pruebas Nuevas fallidas.
Revisa los cambios recientes en el producto, la prueba o el entorno para ver si podrían causar el cambio de estado. Si lo hicieron, es una buena noticia, pero si no, esto podría significar que la prueba es Inestable y que otras pruebas aprobadas podrían ser menos confiables también.
También recomendamos volver a ejecutar las pruebas (por ejemplo, en tu computadora local) para ver si aprueban consistentemente o si regresan al estado anterior. En este último caso, consulta las recomendaciones para Pruebas inestables.
Nuevas pruebas rotas
La marca Nueva rota se agrega automáticamente a una prueba Rota si no estaba rota en el lanzamiento anterior.
Debe habilitarse el historial de pruebas para que Allure Report agregue esta marca.
Al igual que una prueba Nueva fallida, una prueba Nueva rota puede indicar un nuevo error o una inestabilidad. Verifica si los cambios recientes causan el problema. Si no es así, consulta las recomendaciones para Pruebas inestables.
Pruebas reintentadas
La marca Reintentada se agrega automáticamente a una prueba si se ejecutó varias veces durante el lanzamiento de la prueba y obtuvo al menos dos estados diferentes entre ellos.
A diferencia de las otras marcas, Allure Report no necesita acceso al historial de lanzamientos anteriores para agregar la marca Reintentada. Solo tiene en cuenta todos los resultados de la prueba del lanzamiento actual. Consulta Reintentos para más detalles.
Dependiendo de la configuración del marco de pruebas y la naturaleza de las pruebas en sí, el estado Reintentado puede o no indicar un problema. Por ejemplo, si una prueba depende de un servicio web externo, el estado Aprobada con la marca Reintentada puede ser completamente aceptable. Por otro lado, una prueba que solo trabaja con la funcionalidad del producto probablemente se espera que pase cada vez, por lo que la marca Reintentada probablemente necesite una investigación más profunda.
Asegúrate de vigilar estas pruebas de vez en cuando. Al igual que una prueba Inestable, la inestabilidad de una prueba Reintentada puede tener múltiples fuentes, algunas de las cuales podrían no haberse analizado aún.