Tema 2.2 - Estado de las pruebas en proyectos ágiles

Comunicación del estado de la prueba, el progreso y la calidad del producto

Los equipos ágiles progresan al tener software en funcionamiento al final de cada iteración, para determinar cuándo el equipo tendrá software en funcionamiento, deben monitorear el progreso de todos los elementos de trabajo en la iteración y el lanzamiento, los probadores de los equipos ágiles utilizan varios métodos para registrar el progreso y el estado de las pruebas, incluidos los resultados de la automatización de las pruebas, la progresión de las tareas de prueba y las historias en el tablero de tareas ágiles y gráficos de evolución que muestran el progreso del equipo, luego, estos se pueden comunicar al resto del equipo utilizando medios como paneles de control wiki y correos electrónicos con estilo de panel, así como verbalmente durante las reuniones de pie, los equipos ágiles pueden usar herramientas que generan automáticamente informes de estado basados ​​en los resultados de las pruebas y el progreso de las tareas, que a su vez actualizan los paneles de control y los correos electrónicos estilo wiki; este método de comunicación también recopila métricas del proceso de prueba, que se pueden utilizar en la mejora del proceso, comunicar el estado de la prueba de una manera tan automatizada también libera tiempo a los evaluadores para concentrarse en diseñar y ejecutar más casos de prueba.

Los equipos pueden usar gráficos de evolución para realizar un seguimiento del progreso en toda la versión y dentro de cada iteración, un gráfico de evolución representa la cantidad de trabajo que queda por hacer frente al tiempo asignado al lanzamiento o iteración.

Para proporcionar una representación visual instantánea y detallada del estado actual de todo el equipo, incluido el estado de las pruebas, los equipos pueden utilizar paneles de tareas ágiles, las tarjetas de historia, las tareas de desarrollo, las tareas de prueba y otras tareas creadas durante la planificación de la iteración se capturan en el tablero de tareas, a menudo usando tarjetas de colores coordinados para determinar el tipo de tarea, durante la iteración, el progreso se gestiona mediante el movimiento de estas tareas a través del tablero de tareas en columnas como hacer, trabajo en progreso, verificar y listo; los equipos ágiles pueden usar herramientas para mantener sus story cards y tableros de tareas ágiles, que pueden automatizar tableros y actualizaciones de estado.

Las tareas de prueba en el tablero de tareas se relacionan con los criterios de aceptación definidos para las historias de usuario, a medida que los scripts de automatización de pruebas, las pruebas manuales y las pruebas exploratorias para una tarea de prueba alcanzan un estado de aprobación, la tarea se mueve a la columna de terminado del panel de tareas, todo el equipo revisa el estado del tablero de tareas con regularidad, a menudo durante las reuniones diarias, para garantizar que las tareas se muevan en todos los ámbitos a un ritmo aceptable, si alguna tarea (incluidas las tareas de prueba) no avanza o avanza demasiado lento, el equipo revisa y aborda cualquier problema que pueda estar bloqueando el progreso de esas tareas.

La reunión diaria de pie incluye a todos los miembros del equipo Ágil, incluidos los probadores, en esta reunión, comunican su estado actual, la agenda de cada miembro es:

• ¿Qué ha completado desde la última reunión?
• ¿Qué planeas completar para la próxima reunión?
• ¿Qué se interpone en su camino?

Cualquier problema que pueda bloquear el progreso de la prueba se comunica durante las reuniones diarias, por lo que todo el equipo está al tanto de los problemas y puede resolverlos en consecuencia.

Para mejorar la calidad general del producto, muchos equipos Agile realizan encuestas de satisfacción del cliente para recibir comentarios sobre si el producto cumple con las expectativas del cliente, los equipos pueden utilizar otras métricas similares a las capturadas en las metodologías de desarrollo tradicionales, como tasas de aprobación / falla de prueba, tasas de descubrimiento de defectos, resultados de pruebas de confirmación y regresión, densidad de defectos, defectos encontrados y reparados, cobertura de requisitos, cobertura de riesgo, cobertura de código y código churn para mejorar la calidad del producto.

Como con cualquier ciclo de vida, las métricas capturadas y reportadas deben ser relevantes y ayudar a la toma de decisiones. Las métricas no deben usarse para recompensar, castigar o aislar a ningún miembro del equipo.

 

Gestión del riesgo de regresión con casos de prueba automatizados y manuales en evolución

En un proyecto ágil, a medida que se completa cada iteración, el producto crece, por lo tanto, el alcance de las pruebas también aumenta. Además de probar los cambios de código realizados en la iteración actual, los evaluadores también deben verificar que no se haya introducido ninguna regresión en las características que se desarrollaron y probaron en iteraciones anteriores, el riesgo de introducir regresión en el desarrollo ágil es alto debido a una gran cantidad de código (líneas de código agregadas, modificadas o eliminadas de una versión a otra), dado que responder al cambio es un principio ágil clave, también se pueden realizar cambios en las funciones entregadas anteriormente para satisfacer las necesidades comerciales, para mantener la velocidad sin incurrir en una gran cantidad de deuda técnica, es fundamental que los equipos inviertan en la automatización de pruebas en todos los niveles de prueba lo antes posible, también es fundamental que todos los activos de prueba, como las pruebas automatizadas, los casos de prueba manuales, los datos de prueba y otros artefactos de prueba, se mantengan actualizados con cada iteración, se recomienda encarecidamente que todos los activos de prueba se mantengan en una herramienta de gestión de la configuración para permitir el control de versiones, para garantizar la facilidad de acceso por parte de todos los miembros del equipo y para respaldar la realización de cambios según sea necesario debido a la funcionalidad cambiante mientras se conserva la información histórica de los activos de prueba.

Debido a que rara vez es posible la repetición completa de todas las pruebas, especialmente en proyectos ágiles con plazos ajustados, los evaluadores deben asignar tiempo en cada iteración para revisar casos de prueba manuales y automatizados de iteraciones anteriores y actuales para seleccionar casos de prueba que pueden ser candidatos para la prueba de regresión suite y retirar los casos de prueba que ya no son relevantes; las pruebas escritas en iteraciones anteriores para verificar características específicas pueden tener poco valor en iteraciones posteriores debido a cambios de características o características nuevas que alteran la forma en que se comportan esas características anteriores.

Al revisar los casos de prueba, los evaluadores deben considerar la idoneidad para la automatización. el equipo necesita automatizar tantas pruebas como sea posible de iteraciones anteriores y actuales, esto permite que las pruebas de regresión automatizadas reduzcan el riesgo de regresión con menos esfuerzo del que requerirían las pruebas de regresión manual, este esfuerzo de prueba de regresión reducido libera a los probadores para probar más a fondo las nuevas características y funciones en la iteración actual.

Es fundamental que los evaluadores tengan la capacidad de identificar y actualizar rápidamente los casos de prueba de iteraciones y / o versiones anteriores que se ven afectados por los cambios realizados en la iteración actual, la definición de cómo el equipo diseña, escribe y almacena los casos de prueba debe ocurrir durante la planificación del lanzamiento, las buenas prácticas para el diseño y la implementación de pruebas deben adoptarse temprano y aplicarse de manera consistente; los plazos más cortos para las pruebas y el cambio constante en cada iteración aumentarán el impacto de las prácticas de implementación y el diseño de pruebas deficientes.

El uso de la automatización de pruebas, en todos los niveles de prueba, permite a los equipos ágiles proporcionar comentarios rápidos sobre la calidad del producto, las pruebas automatizadas bien escritas proporcionan un documento vivo de la funcionalidad del sistema, al verificar las pruebas automatizadas y sus resultados de prueba correspondientes en el sistema de gestión de la configuración, alineados con el control de versiones de las compilaciones del producto, los equipos ágiles pueden revisar la funcionalidad probada y los resultados de las pruebas para cualquier compilación dada en cualquier momento dado.

Las pruebas unitarias automatizadas se ejecutan antes de que el código fuente se registre en la línea principal del sistema de gestión de la configuración para garantizar que los cambios en el código no rompan la compilación del software, para reducir las interrupciones de la compilación, que pueden ralentizar el progreso de todo el equipo, el código no debe registrarse a menos que pasen todas las pruebas unitarias automatizadas, los resultados de las pruebas unitarias automatizadas brindan retroalimentación inmediata sobre el código y la calidad de construcción, pero no sobre la calidad del producto.

Las pruebas de aceptación automatizadas se ejecutan regularmente como parte de la compilación completa del sistema de integración continua, estas pruebas se ejecutan en una compilación completa del sistema al menos a diario, pero generalmente no se ejecutan con cada registro de código, ya que demoran más en ejecutarse que las pruebas unitarias automatizadas y podrían ralentizar los controles de código.

Los resultados de las pruebas de aceptación automatizadas proporcionan información sobre la calidad del producto con respecto a la regresión desde la última compilación, pero no proporcionan el estado de la calidad general del producto.

Las pruebas automatizadas se pueden ejecutar de forma continua contra el sistema, se debe crear un subconjunto inicial de pruebas automatizadas para cubrir la funcionalidad crítica del sistema y los puntos de integración inmediatamente después de que se implemente una nueva compilación en el entorno de prueba, estas pruebas se conocen comúnmente como pruebas de verificación de compilación, los resultados de las pruebas de verificación de compilación proporcionarán comentarios instantáneos sobre el software después de la implementación, para que los equipos no pierdan tiempo probando una compilación inestable.

Las pruebas automatizadas contenidas en el conjunto de pruebas de regresión generalmente se ejecutan como parte de la compilación principal diaria en el entorno de integración continua, y nuevamente cuando se implementa una nueva compilación en el entorno de prueba, tan pronto como falla una prueba de regresión automatizada, el equipo se detiene e investiga las razones de la prueba fallido, es posible que la prueba haya fallado debido a cambios funcionales legítimos en la iteración actual, en cuyo caso es posible que la prueba y / o la historia del usuario deba actualizarse para reflejar los nuevos criterios de aceptación. Alternativamente, es posible que sea necesario retirar la prueba si se ha creado otra para cubrir los cambios; sin embargo, si la prueba falló debido a un defecto, es una buena práctica que el equipo corrija el defecto antes de avanzar con nuevas funciones.

>Además de la automatización de pruebas, las siguientes tareas de prueba también pueden automatizarse:

• Generación de datos de prueba
• Carga de datos de prueba en sistemas
• Implementación de compilaciones en los entornos de prueba.
• Restauración de un entorno de prueba (por ejemplo, la base de datos o los archivos de datos del sitio web) a una línea de base
• Comparación de salidas de datos

La automatización de estas tareas reduce los gastos generales y permite que el equipo dedique tiempo a desarrollar y probar nuevas funciones.