Devuelva la agilidad al desarrollo ágil con pruebas basadas en cambios

El pequeño secreto sucio del desarrollo ágil

Agile a menudo se vende erróneamente a la alta dirección como una forma de lograr más rápido time-to-market, cuando el objetivo es realmente más preciso entrega al mercado. El sucio secreto que no le contamos a nadie es que esto realmente tiene un costo ... ¡un tiempo de comercialización más lento! Sí, lanzamos con más frecuencia (es decir, "antes") pero, en última instancia, lleva más tiempo llevar la funcionalidad completa al mercado. ¿Por qué tarda más cuando todo lo que estamos haciendo es dividir el problema en partes más pequeñas? Bueno, con mucho, el mayor culpable es la detección de defectos de ciclo tardío y los cuellos de botella introducidos por las medidas para reducir el riesgo.

Gran parte de la velocidad prometida del desarrollo ágil se ve frustrada por los cambios de código incrementales, específicamente su impacto en las pruebas y la estabilidad general del sistema. Cada sprint normalmente concluye con una carrera hacia la línea de meta, ya que QA / testing se enfoca en validar la nueva funcionalidad implementada. Luego, debido a la falta de comprensión del impacto indirecto que tienen los cambios en el código, las organizaciones deben hacer una regresión completa a medida que se acerca el lanzamiento. Esto a menudo descubre numerosos problemas al final del ciclo, lo que resulta en horas tardías y decisiones comerciales difíciles.

¡Tiene que haber una mejor manera!

Centrarse en el riesgo

Debido a la complejidad de las bases de código actuales, cada cambio de código, por inofensivo que sea, puede afectar sutilmente la estabilidad de la aplicación y, en última instancia, "romper el sistema". Estas consecuencias no deseadas son imposibles de descubrir mediante la inspección manual, por lo que las pruebas son fundamentales para mitigar el riesgo que representan, pero a menos que comprenda lo que debe volver a descansar, no podrá lograr una práctica de prueba eficiente. Si está probando demasiado en cada sprint, está perdiendo muchas de las ganancias obtenidas por el desarrollo ágil. Si está probando muy poco, se expone a la detección de ciclo tardío.

Lo que se necesita es una forma de identificar qué pruebas deben volver a ejecutarse y centrar los esfuerzos de prueba (pruebas unitarias, pruebas funcionales automatizadas y pruebas manuales) en la validación de las funciones y el código relacionado que se ven afectados por los cambios más recientes. Usando una combinación de los motores de análisis de código de Parasoft (Jtest, C / C ++ test, dotTEST) y Process Intellligence Engine (PIE) dentro de Parasoft DTP, los desarrolladores y probadores pueden comprender los cambios en la base del código entre compilaciones y llegar a la promesa de Agile. Se llama Pruebas basadas en cambios.

Las pruebas basadas en cambios (CBT) mantienen el Sprint en marcha

La clave es saber qué pruebas están disponibles para validar los cambios de código, y aquí es donde la cobertura correlacionada de Parasoft ofrece los productos. Al comprender cuáles de estos archivos han cambiado y qué pruebas específicas afectaron a esos archivos, el motor de análisis de DTP (PIE) puede analizar el delta entre dos compilaciones e identificar el subconjunto de pruebas que deben volver a ejecutarse. La siguiente imagen muestra un widget del panel de DTP que muestra un gráfico circular de los resultados del análisis CBT. Este gráfico muestra el subconjunto de pruebas que están disponibles para validar los cambios de código, categorizados por su estado de prueba: aprobado, fallido, incompleto y que necesita una nueva prueba.

Esta vista de alto nivel indica que hay una serie de fallas que ha introducido el código modificado y que hay una serie de pruebas que aún no se han ejecutado pero que están disponibles para validar aún más los cambios.

 

 

 

 

 

 

 

 

Un estado de Contraseña errónea, or Incompleto indica que estas pruebas ya se ejecutaron contra la compilación, ya sea como parte de un proceso de prueba totalmente automatizado (como un paso de compilación impulsado por CI) o mientras se prueba la nueva funcionalidad. Las pruebas con el estado de volver a probar sin embargo, son pruebas manuales que aún no se ejecutaron o pruebas que forman parte de ejecuciones de automatización que no están programadas para ejecutarse durante el sprint actual.

Profundizando en el gráfico, podemos obtener rápidamente información sobre en qué parte del código se han producido los cambios, cómo se correlacionan las pruebas existentes con esos cambios y dónde deben centrarse los recursos de prueba.

A partir de aquí, podemos crear un plan de prueba, abordando los casos de prueba fallidos e incompletos con la máxima prioridad, y utilizando las recomendaciones de nueva prueba para enfocar la programación de ejecuciones automatizadas adicionales y priorizar los esfuerzos de prueba manual.

El Explorador de violaciones en DTP proporciona la interfaz para definir y administrar el plan de prueba. Al navegar por las pruebas y los resultados, el Explorador revela detalles sobre cada caso de prueba. Utilizando la Priorización view para establecer los metadatos de prueba, los usuarios pueden asignar propietarios, acciones y establecer prioridad para cada uno de los casos de prueba.

Cómo aplicar un flujo de trabajo CBT

Entonces, ¿cómo ayuda esto a un proceso ágil? Simplemente, es la capacidad de identificar rápida y sucintamente dónde deben aplicarse sus recursos de prueba. Al probar solo lo que se necesita frente a todo (o simplemente adivinar), el tiempo de prueba se reduce en gran medida. La calidad aumenta y el sprint se realiza a tiempo.

¿Cómo funcionaría esto en la práctica? Si bien los resultados del análisis de pruebas basadas en cambios (CBT) se pueden usar de varias formas diferentes, sugeriría que el siguiente flujo de trabajo sea el más práctico para enfocar los esfuerzos de pruebas basadas en sprints;

• Identifique su línea de base. Esta es la compilación con los esfuerzos de prueba completados que desea usar para una nueva prueba enfocada. Normalmente, esta sería la construcción desde el final del sprint o lanzamiento anterior.
• Ejecute pruebas unitarias y pruebas funcionales automatizadas disponibles. Integre pruebas automatizadas en su proceso de CI y mida / monitoree los resultados de CBT contra la última versión. Esto le permite ver cómo le está yendo y planificar el esfuerzo de volver a probar.
• Cierre el espacio para volver a probar. Pruebe con la compilación de destino y envíe los resultados de los esfuerzos de reevaluación para su análisis; y volver a revisar el resultado de la CBT.
• Restablece tu línea de base. Al final del sprint, mueva la línea de base a la compilación en la que ha finalizado la prueba y reinicie / repita para el próximo sprint.

Conclusión

Necesitamos aumentar la productividad de las pruebas en el desarrollo ágil. Las pruebas son un cuello de botella importante para la entrega continua, ya que se identifican demasiados defectos al final del ciclo de lanzamiento debido a pruebas incorrectas. Para obtener los mejores resultados, concentre los esfuerzos de prueba en el impacto de los cambios que está realizando y desbloquee la agilidad para acelerar la entrega al mercado.