Tema 2.1 - Las diferencias entre las pruebas en los enfoques tradicionales y ágiles

Actividades de prueba y desarrollo

La principal diferencia entre los ciclos de vida tradicionales y los ciclos de vida ágiles es la idea de tener iteraciones cortas, cada iteración resulta del trabajo del software que entrega características de valor a las partes interesadas del negocio; al comienzo del proyecto, hay un periodo de planificación de lanzamiento, seguido por una secuencia de iteraciones; al comienzo de cada iteración, hay un periodo de planificación de esta, una vez el alcance de la iteración haya sido establecido, las historias de usuario seleccionadas son desarrolladas, se incorporan en el sistema y se prueban, estas iteraciones son altamente dinámicas, con actividades de desarrollo, integración y pruebas que toman lugar a lo largo de cada iteración y con un paralelismo y superposición considerables, las actividades de prueba ocurren a lo largo de la iteración, no como actividad final.

Probadores, desarrolladores e interesados del negocio tiene todos un rol en las pruebas, como sucede en los ciclos de vida tradicionales, los desarrolladores realizan pruebas unitarias a medida que desarrollan características desde las historias de usuario, los probadores evalúan todas esas características, los interesados del negocio prueban las historias durante la implementación, estos, podrían usar casos de prueba escritos, pero también pueden simplemente experimentar y usar la función para proporcionar comentarios como retroalimentación de una forma rápida al equipo de desarrollo.

En algunos casos, se producen iteraciones de endurecimiento o estabilización periódicamente para resolver cualquier defecto persistente y otras formas de deuda técnica, sin embargo, la mejor práctica es que ninguna función se considera realizada hasta que se haya integrado y probado con el sistema, otra buena práctica es abordar los defectos restantes de la iteración anterior al comienzo de la siguiente, como parte del trabajo pendiente para esa iteración (lo que se conoce como "corregir errores primero"). Sin embargo, algunos se quejan de que esta práctica da como resultado una situación en la que se desconoce el trabajo total a realizar en la iteración y será más difícil estimar cuándo se pueden realizar las características restantes, al final de la secuencia de iteraciones, puede haber un conjunto de actividades de lanzamiento para preparar el software para la entrega, aunque en algunos casos la entrega ocurre al final de cada iteración.

Cuando las pruebas basadas en el riesgo se utilizan como una de las estrategias de prueba, se produce un análisis de riesgo de alto nivel durante la planificación del lanzamiento, y los probadores suelen conducir ese análisis, sin embargo, los riesgos de calidad específicos asociados con cada iteración se identifican y evalúan en la planificación de la iteración, este análisis de riesgo puede influir en la secuencia de desarrollo, así como en la prioridad y profundidad de las pruebas de las funciones, también influye en la estimación del esfuerzo de prueba requerido para cada característica.

En algunas prácticas ágiles (por ejemplo, programación extrema), se utiliza el emparejamiento, el emparejamiento puede implicar que los probadores trabajen juntos de dos en dos para probar una función, el emparejamiento también puede involucrar a un evaluador que trabaje en colaboración con un desarrollador para desarrollar y probar una función, puede resultar difícil cuando el equipo de prueba está distribuido, pero los procesos y las herramientas pueden ayudar a habilitar el emparejamiento distribuido.

Los evaluadores también pueden servir como asesores de pruebas y calidad dentro del equipo, compartiendo el conocimiento de las pruebas y apoyando el trabajo de aseguramiento de la calidad dentro del equipo, esto promueve un sentido de propiedad colectiva de la calidad del producto.

La automatización de pruebas en todos los niveles de pruebas ocurre en muchos equipos ágiles, y esto puede significar que los evaluadores dediquen tiempo a crear, ejecutar, monitorear y mantener pruebas y resultados automatizados, debido al uso intensivo de la automatización de pruebas, un mayor porcentaje de las pruebas manuales en proyectos ágiles tiende a realizarse utilizando técnicas basadas en la experiencia y en los defectos, como ataques de software, pruebas exploratorias y adivinación de errores Mientras que los desarrolladores se centrarán en la creación de pruebas unitarias, los evaluadores deberían centrarse en la creación de pruebas automatizadas de integración, sistemas e integración de sistemas, esto conduce a una tendencia de los equipos ágiles a favorecer a los probadores con una sólida formación técnica y de automatización de pruebas.

Un principio básico de Agile es que pueden producirse cambios a lo largo del proyecto., por lo tanto, la documentación de productos de trabajo livianos se favorece en proyectos ágiles; los cambios en las características existentes tienen implicaciones de prueba, especialmente implicaciones de prueba de regresión; el uso de pruebas automatizadas es una forma de administrar la cantidad de esfuerzo de prueba asociado con el cambio, sin embargo, es importante que la tasa de cambio no exceda la capacidad del equipo del proyecto para lidiar con los riesgos asociados con esos cambios.

Productos de trabajo del proyecto

Los productos de trabajo de proyectos de interés inmediato para los probadores ágiles generalmente se dividen en tres categorías:

1. Productos de trabajo orientados al negocio que describen lo que se necesita (por ejemplo, especificaciones de requisitos) y cómo usarlo por ejemplo (documentación del usuario)

2. Productos de trabajo de desarrollo que describen cómo se construye el sistema por ejemplo (diagramas de relación de entidad de base de datos), que realmente implementan el sistema por ejemplo (código), o que evalúan piezas individuales de código por ejemplo (pruebas unitarias automatizadas)

3. Probar productos de trabajo que describan cómo se prueba el sistema por ejemplo (estrategias y planes de prueba), qué realmente prueban el sistema (Pruebas manuales y automatizadas), o qué presentan resultados de pruebas (Paneles de prueba)

En un proyecto Agile típico, es una práctica común evitar producir grandes cantidades de documentación, en cambio, el enfoque está más en tener software que funcione, junto con pruebas automatizadas que demuestren el cumplimiento de los requisitos, este estímulo para reducir la documentación se aplica solo a la documentación que no aporta valor al cliente, en un proyecto Agile exitoso, se logra un equilibrio entre aumentar la eficiencia mediante la reducción de la documentación y proporcionar documentación suficiente para respaldar las actividades comerciales, de prueba, desarrollo y mantenimiento, el equipo debe tomar una decisión durante la planificación del lanzamiento sobre qué productos de trabajo se requieren y qué nivel de documentación de productos de trabajo se necesita.

• Los productos de trabajo típicos orientados a los negocios en proyectos ágiles incluyen historias de usuarios y criterios de aceptación:

• Los productos de trabajo de desarrollador típicos en proyectos ágiles incluyen código. 

• Los productos de trabajo típicos de los probadores en proyectos Agile incluyen pruebas automatizadas, así como documentos como planes de prueba, catálogos de riesgos de calidad, pruebas manuales, informes de defectos y registros de resultados de pruebas. 

En algunas implementaciones ágiles, especialmente proyectos y productos regulados, críticos para la seguridad, distribuidos o altamente complejos, se requiere una mayor formalización de estos productos de trabajo, por ejemplo, algunos equipos transforman las historias de usuario y los criterios de aceptación en especificaciones de requisitos más formales, se pueden preparar informes de trazabilidad vertical y horizontal para satisfacer a los auditores, las regulaciones y otros requisitos.

Niveles de prueba

Los niveles de prueba son actividades de prueba que están relacionadas lógicamente, a menudo por la madurez o la completitud del elemento bajo prueba.

En los modelos de ciclo de vida secuencial, los niveles de prueba a menudo se definen de manera que los criterios de salida de un nivel son parte de los criterios de entrada para el siguiente nivel, en algunos modelos iterativos, esta regla no se aplica, los niveles de prueba se superponen, la especificación de requisitos, la especificación de diseño y las actividades de desarrollo pueden superponerse con los niveles de prueba.

En algunos ciclos de vida ágiles, la superposición se produce porque los cambios en los requisitos, el diseño y el código pueden ocurrir en cualquier punto de una iteración, si bien Scrum, en teoría, no permite cambios en las historias de usuario después de la planificación de la iteración, en la práctica, estos cambios a veces ocurren, durante una iteración, cualquier historia de usuario determinada, normalmente progresará secuencialmente a través de las siguientes actividades de prueba:

• Prueba unitaria, generalmente realizada por el desarrollador
• Prueba de aceptación de funciones, que a veces se divide en dos actividades:

1. Las pruebas de verificación de funciones, que a menudo son automatizadas, pueden ser realizadas por desarrolladores o evaluadores, e implican pruebas con los criterios de aceptación de la historia del usuario.
2. Pruebas de validación de funciones, que generalmente son manuales y pueden involucrar a desarrolladores, evaluadores y partes interesadas del negocio que trabajen en colaboración para determinar si la función es apta para su uso, para mejorar la visibilidad del progreso realizado y para recibir comentarios reales de las partes interesadas del negocio.

Además, a menudo se produce un proceso paralelo de pruebas de regresión a lo largo de la iteración. Esto implica volver a ejecutar las pruebas unitarias automatizadas y las pruebas de verificación de características de la iteración actual y las iteraciones anteriores, generalmente a través de un marco de integración continua.

En algunos proyectos ágiles, puede haber un nivel de prueba del sistema, que comienza una vez que la primera historia de usuario está lista para dicha prueba, esto puede implicar la ejecución de pruebas funcionales, así como pruebas no funcionales de rendimiento, confiabilidad, usabilidad y otros tipos de pruebas relevantes.

Los equipos ágiles pueden emplear varias formas de pruebas de aceptación, las pruebas alfa internas y las pruebas beta externas pueden ocurrir, ya sea al final de cada iteración, después de la finalización de cada iteración o después de una serie de iteraciones, las pruebas de aceptación del usuario, las pruebas de aceptación operativa, las pruebas de aceptación reglamentaria y las pruebas de aceptación del contrato también pueden ocurrir, ya sea al final de cada iteración, después de la finalización de cada iteración o después de una serie de iteraciones.

Pruebas y gestión de la configuración

Los proyectos ágiles a menudo implican un uso intensivo de herramientas automatizadas para desarrollar, probar y administrar el desarrollo de software, los desarrolladores utilizan herramientas para análisis estático, pruebas unitarias y cobertura de código, los desarrolladores verifican continuamente el código y las pruebas unitarias en un sistema de administración de configuración, utilizando marcos de prueba y compilación automatizados, estos marcos permiten la integración continua de nuevo software con el sistema, con el análisis estático y las pruebas unitarias que se ejecutan repetidamente a medida que se comprueba el nuevo software

Estas pruebas automatizadas también pueden incluir pruebas funcionales en los niveles de integración y sistema, dichas pruebas funcionales automatizadas se pueden crear utilizando arneses de pruebas funcionales, herramientas de prueba funcionales de interfaz de usuario de código abierto o herramientas comerciales, y se pueden integrar con las pruebas automatizadas ejecutadas como parte del marco de integración continua. En algunos casos, debido a la duración de las pruebas funcionales, las pruebas funcionales se separan de las pruebas unitarias y se ejecutan con menos frecuencia, por ejemplo, se pueden ejecutar pruebas unitarias cada vez que se registra un nuevo software, mientras que las pruebas funcionales más largas se ejecutan solo cada pocos días.

Uno de los objetivos de las pruebas automatizadas es confirmar que la compilación funciona y se puede instalar, si falla alguna prueba automatizada, el equipo debe corregir el defecto subyacente a tiempo para la próxima verificación del código, esto requiere una inversión en informes de pruebas en tiempo real para proporcionar una buena visibilidad de los resultados de las pruebas, este enfoque ayuda a reducir los ciclos costosos e ineficientes de “compilación-instalación-falla-reconstrucción-reinstalación” que pueden ocurrir en muchos proyectos tradicionales, ya que los cambios rompen la compilación o hacen que el software no se instale rápidamente.

Las pruebas automatizadas y las herramientas de construcción ayudan a gestionar el riesgo de regresión asociado con el cambio frecuente que a menudo ocurre en los proyectos ágiles, sin embargo, la dependencia excesiva de las pruebas unitarias automatizadas para gestionar estos riesgos puede ser un problema, ya que las pruebas unitarias a menudo tienen una eficacia de detección de defectos limitada. También se requieren pruebas automatizadas en los niveles de integración y sistema.

Opciones de organización para pruebas independientes

Los evaluadores independientes suelen ser más eficaces para encontrar defectos, en algunos equipos Agile, los desarrolladores crean muchas de las pruebas en forma de pruebas automatizadas, uno o más probadores pueden estar integrados en el equipo, realizando muchas de las tareas de prueba, sin embargo, dada la posición de esos evaluadores dentro del equipo, existe el riesgo de pérdida de independencia y evaluación objetiva.

Otros equipos ágiles retienen equipos de prueba separados y completamente independientes, y asignan probadores a pedido durante los últimos días de cada sprint, esto puede preservar la independencia, y estos probadores pueden proporcionar una evaluación objetiva e imparcial del software, sin embargo, las presiones de tiempo, la falta de comprensión de las nuevas características del producto y los problemas de relación con las partes interesadas del negocio y los desarrolladores a menudo generan problemas con este enfoque.

Una tercera opción es tener un equipo de prueba independiente y separado en el que los evaluadores se asignen a equipos ágiles a largo plazo, al comienzo del proyecto, lo que les permitirá mantener su independencia mientras obtienen una buena comprensión del producto y relaciones sólidas con otros miembros del equipo, además, el equipo de prueba independiente puede tener probadores especializados fuera de los equipos ágiles para trabajar en actividades a largo plazo y / o independientes de la iteración, como desarrollar herramientas de prueba automatizadas, realizar pruebas no funcionales, crear y respaldar entornos de prueba y datos y la realización de niveles de prueba que podrían no encajar bien dentro de un sprint (por ejemplo, pruebas de integración del sistema).