El Uso Del Análisis De Brechas En El Proceso de Prueba Para Alinear Desarrolladores y Probadores

Es una creencia generalizada que los desarrolladores y probadores se llevan bien como tiza y queso. Los desarrolladores a menudo miran con desprecio a los probadores, viéndolos como un obstáculo inflexible e inútil para desarrollar código nuevo que no proporciona detalles claros en sus tickets de error. Del mismo modo, los probadores a menudo ven a los desarrolladores con irritación por no mantenerlos informados de los cambios de código y por impulsar nuevos cambios durante los ciclos de prueba. Esta es la razón por la que el análisis de brechas en el proceso de pruebas de control de calidad puede ser especialmente beneficioso para alinear tanto a desarrolladores como a probadores.

Si bien esta vista puede ser apócrifa, a menudo ocurre que los desarrolladores y probadores no se comunican bien. A menudo, la comunicación solo ocurre a través de la gestión (gerentes de proyecto y gerentes de línea) o a través de tickets en Jira. El resultado es que las pruebas a menudo resultan inadecuadas. En particular, con demasiada frecuencia el código nuevo se prueba mal o no se prueba en absoluto. La investigación ha demostrado que este nuevo código no probado es la mayor fuente de errores y fallos futuros. Aquí es donde entra en juego el concepto de Análisis de Brechas de prueba.

En este blog, exploraremos qué es el Análisis de brechas de prueba, mostraremos cómo puede ayudar a identificar el código que necesita ser probado y exploraremos si este enfoque es la panacea que puede cerrar la brecha entre desarrolladores y probadores.

¿Qué es el Análisis de Brechas de Prueba?

Cuando desarrolla por primera vez un sistema de software, es fácil asegurarse de que está probando todo el sistema. Los probadores pueden tomar las especificaciones del código y usar una combinación de pruebas planificadas y exploratorias para garantizar que prueban cada parte móvil de la base de código. Sin embargo, la mayoría del software no es estático. Las empresas hacen versiones periódicas monolíticas de código de larga duración o emplean algún nivel de integración continua e implementación continua (CI/CD). En cualquier caso, el código base cambia constantemente. Sin embargo, con demasiada frecuencia los casos de prueba no se actualizan al mismo ritmo. A veces, los evaluadores simplemente no saben que se ha realizado un cambio de código. Otras veces, el cambio de código se envía justo después de que se haya ejecutado un conjunto particular de pruebas. Las pruebas parecen haber pasado, pero el cambio de código puede tener roto.

El análisis de brechas de prueba es el proceso de identificar estas brechas donde se ha implementado código nuevo pero aún no se ha probado. Esto requiere una combinación de análisis estático de todos los cambios de código y análisis dinámico de todas las pruebas actuales. Al comparar estos dos análisis, puede ver fácilmente dónde están las brechas. Es decir, áreas de nuevo código que han sido probadas adecuadamente. Típicamente, esto se hace trazando el código usando una forma de diagrama de árbol donde el código se divide en bloques funcionales, debajo de cada bloque están las clases constituyentes, debajo de esas están los métodos y funciones reales. En cada nivel de la jerarquía, el tamaño relativo del bloque indica la cantidad de código. Al superponer el árbol que muestra los cambios de código con el árbol que muestra el estado actual de las pruebas, es fácil detectar las áreas donde falta cobertura de prueba.

Un mapa de árbol que muestra el código sin cambios (gris), el código revisado/nuevo que se prueba (verde), el código revisado que no se prueba (naranja) y el código nuevo que no se prueba (rojo).

¿Por qué podría importar el Análisis de brechas de prueba en el proceso de prueba?

En un artículo de 2013, investigadores de la Universidad Técnica de Múnich realizaron un estudio para analizar la correlación entre el código nuevo no probado y los errores de software futuros. Trabajaron con Munich Re (una gran compañía de seguros), monitoreando su sistema de TI de larga duración a través de 2 lanzamientos. Durante el lanzamiento, establecieron qué código era nuevo y también observaron qué código se probó y qué código se liberó sin probar. Después de eso, monitorearon el sistema durante mucho tiempo y rastrearon todos los errores reportados hasta la fuente original. Descubrieron dos cosas clave. En primer lugar, aproximadamente un tercio de todo el código se estaba publicando sin probar. En segundo lugar, cuando rastrearon los errores que descubrieron, en general, entre el 70 y el 80% de todos los errores estaban en código no probado. El gráfico siguiente muestra esto con mayor claridad.

Como puede ver, el antiguo código probado no tenía errores. El nuevo código probado tenía entre el 22 y el 30% de los errores y los errores restantes se distribuyeron de manera bastante uniforme entre el nuevo código no probado y el antiguo código no probado. Sin embargo, dado que el nuevo código solo representaba el 15% del código total, puede ver que el nuevo código no probado representaba un número desproporcionadamente alto de errores.

El análisis de brechas de prueba está diseñado para identificar este nuevo código no probado. Sin embargo, también puede ayudarte de otras maneras. Por ejemplo, debido a que supervisa lo que está probando, puede identificar áreas de código existente que están desactualizadas (por ejemplo, todavía se están probando, pero en realidad no están siendo llamadas por ningún código). También puede resaltar en qué áreas necesita concentrar sus recursos de prueba. Al ejecutarlo regularmente, los gerentes pueden mejorar la planificación de pruebas, centrándose en probar código nuevo e intentando garantizar una cobertura de pruebas uniforme.

Desarrolladores y probadores alineados a través del Análisis de Brechas de Prueba

El Análisis de brechas de prueba es claramente un concepto poderoso. Pero también está claro que no todos los equipos se beneficiarán por igual. Los equipos que se beneficiarán más son aquellos que mantienen bases de código de larga duración con versiones monolíticas periódicas. En las bases de código de larga duración, los desarrolladores a menudo trabajan en código escrito por otras personas. Los evaluadores pueden confiar en planes de prueba producidos varias versiones antes. Tomados en combinación, estos factores pueden significar que nadie tiene muy claro qué código se está probando o cómo interactúa ese código con otras partes del sistema. Aquí, TGA puede permitir a los probadores ver exactamente qué código ha cambiado, lo que les permite centrarse en esto. También pueden identificar código en el sistema existente que no se haya probado.

Los equipos que utilizan CI / CD también pueden beneficiarse de este enfoque, ya que permitirá a los evaluadores identificar rápidamente qué código se cambia y así concentrarse en eso. También puede evitar el problema mencionado anteriormente, donde un fragmento de código se altera inmediatamente después de haber sido probado y luego se libera con los cambios no probados.

Por otro lado, los equipos que trabajan en código nuevo o de corta duración se beneficiarán menos, ya que, por definición, la mayoría del código no se probará al principio. Aquí es importante utilizar metodologías de prueba estándar para garantizar que sus pruebas sean buenas. Sin embargo, puede ser útil para dichos equipos comenzar a monitorear la cobertura de la prueba usando TGA, ya que eso les permitirá evitar problemas futuros.

¿Cuáles son los problemas potenciales?

Hay algunos problemas con TGA. Una de las mayores se relaciona con el hecho de que no puede decirte qué código se está llamando activamente en la base de código. Los desarrolladores a menudo agregan código nuevo en preparación para futuras versiones, pero como esto está inactivo, el conjunto de pruebas no puede llamarlo. Como resultado, este código siempre se mostrará como nuevo código no probado. Igualmente, muchas bases de código grandes contienen bloques de código antiguo o huérfano. Estos deben limpiarse periódicamente, pero de nuevo distorsionarán la imagen para el Análisis de Brechas de prueba.

Otra observación importante es que el hecho de que se pruebe un fragmento de código no impide que ese código active errores en otro lugar. Algunos de los peores errores son aquellos en los que un pequeño cambio en una pieza de código hace que una función o método falle en un bloque de código totalmente no relacionado. Por lo tanto, es vital seguir haciendo pruebas exploratorias y pruebas de regresión. Lo que TGA puede hacer es identificar áreas en su base de código existente que no se están probando adecuadamente durante las pruebas de regresión.

¿Qué otras alternativas ayudan a cerrar la brecha?

El análisis de brechas de prueba es definitivamente una herramienta útil para algunos equipos. Sin embargo, hay otras maneras de evitar un desajuste entre lo que sus probadores están probando y lo que sus codificadores están codificando. Una forma es utilizar una automatización de pruebas más inteligente que sea capaz de identificar dónde y cuándo han cambiado las cosas, tanto en el frontend como, lo que es más importante, en el backend. Aquí en Functionize, nuestras pruebas utilizan huellas digitales inteligentes junto con aprendizaje automático y autocuración para reducir el mantenimiento de las pruebas. Esto permite que las pruebas se adapten proactivamente a los cambios en el frontend, así como monitorear cosas como llamadas al servidor, tiempos de respuesta y si los botones/funciones son realmente visibles. Esto significa que sus probadores no se verán atrapados por los cambios realizados en el código del backend o los cambios de diseño/CSS que alteren el diseño del frontend.

Nuestro sistema inteligente también puede crear pruebas al monitorear cómo los usuarios interactúan con el sistema. Esto ayuda a garantizar que haya menos huecos en la cobertura de la prueba. Una de nuestras herramientas más nuevas le permite escribir nuevas pruebas en inglés sencillo. Estos son analizados por nuestra herramienta de Procesamiento de Lenguaje Natural y convertidos en pruebas utilizables. Esto significa que durante el desarrollo, los desarrolladores pueden simplemente especificar lo que se necesita probar usando el inglés normal,cerrando así la brecha entre las dos disciplinas.

Conclusiones

El análisis de brechas de prueba le ayuda a identificar qué código se está publicando sin probar y, por lo tanto, puede ayudarlo a enfocar sus recursos de prueba de manera más efectiva. Como era de esperar, resulta que el código no probado es mucho más probable que contenga errores, por lo que cualquier herramienta que pueda ayudar a garantizar que este código se pruebe correctamente es útil. Sin embargo, como hemos visto, el TGA solo puede complementar las mejores prácticas existentes. Es vital mantener sus pruebas de regresión y pruebas exploratorias. Muchos de los beneficios de TGA también se pueden lograr mediante el uso de herramientas de prueba inteligentes. Pero, en general, lo más importante que debes evitar es aislar a tu equipo de pruebas del trabajo de tus desarrolladores. Para citar mal un viejo adagio, debes asegurarte de que la mano izquierda sepa lo que está haciendo la mano derecha.