Tema 3.1 - Métodos de prueba ágiles

TDD – ATDD – BDD

TDD - Test-Driven Development (Desarrollo orientado a pruebas) es una práctica de ingeniería que consiste en codificar pruebas, desarrollar y refactorizar de forma continua el código construido. La idea principal de esta, es realizar inicialmente las pruebas unitarias para el código a implementar.

 El proceso para el desarrollo orientado a pruebas es:

• Agregar una prueba que capture el concepto del programador del funcionamiento deseado de un pequeño fragmento de código
• Ejecute la prueba, que debería fallar ya que el código no existe
• Escriba el código y ejecute la prueba en un circuito cerrado hasta que pase la prueba
• Refactorice el código después de que se apruebe la prueba, vuelva a ejecutar la prueba para asegurarse de que sigue pasando contra el código refactorizado
• Repita este proceso para el siguiente fragmento de código, ejecutando las pruebas anteriores y las pruebas agregadas.

Las pruebas escritas son principalmente a nivel de unidad y se centran en el código, aunque las pruebas también se pueden escribir a nivel de integración o de sistema, el desarrollo basado en pruebas ganó popularidad a través de Extreme Programming, pero también se utiliza en otras metodologías ágiles y, a veces, en ciclos de vida secuenciales. Ayuda a los desarrolladores a centrarse en los resultados esperados claramente definidos, las pruebas están automatizadas y se utilizan en integración continua.

 

ATDD – Acceptance Test-Driven Development (Desarrollo orientado a pruebas de aceptación), define los criterios de aceptación y las pruebas durante la creación de historias de usuario. El desarrollo impulsado por pruebas de aceptación es un enfoque colaborativo que permite a todas las partes interesadas comprender cómo debe comportarse el componente de software y qué necesitan los desarrolladores, evaluadores y representantes comerciales para garantizar este comportamiento.

El desarrollo impulsado por pruebas de aceptación crea pruebas reutilizables para pruebas de regresión. Las herramientas específicas apoyan la creación y ejecución de tales pruebas, a menudo dentro del proceso de integración continuo. Estas herramientas pueden conectarse a capas de datos y servicios de la aplicación, lo que permite que las pruebas se ejecuten a nivel del sistema o de aceptación. El desarrollo basado en pruebas de aceptación permite la resolución rápida de defectos y la validación del comportamiento de las funciones. Ayuda a determinar si se cumplen los criterios de aceptación para la función.

 

BDD. Behavior Driven Development (Desarrollo orientado al comportamiento): permite que un desarrollador se centre en probar el código en función del comportamiento esperado del software. Debido a que las pruebas se basan en el comportamiento exhibido del software, las pruebas son generalmente más fáciles de entender para otros miembros del equipo y partes interesadas.

Se pueden usar marcos de desarrollo específicos basados ​​en el comportamiento para definir los criterios de aceptación basados ​​en el formato given / when / then:

Given: un contexto inicial.

When: ocurre un evento.

Then: verifica algunos resultados.

Dentro de las herramientas que soportan este marco de comportamiento para los criterios de aceptación es el de Cucumber que usa el lenguaje Gherkin con el formato visto, un ejemplo de ello es la imagen que aparece a continuación.

A partir de estos requisitos, el marco de desarrollo basado en el comportamiento genera código que los desarrolladores pueden utilizar para crear casos de prueba, el desarrollo impulsado por el comportamiento ayuda al desarrollador a colaborar con otras partes interesadas, incluidos los evaluadores, para definir pruebas unitarias precisas centradas en las necesidades comerciales.

 

La pirámide de prueba de software

La pirámide de prueba también conocida como La Pirámide de Cohn es la estrategia más aceptada actualmente para realizar pruebas de software en metodologías ágiles, estos pueden probarse en diferentes niveles, los niveles de prueba típicos son, desde la base de la pirámide hasta la parte superior: unidad, integración, sistema y aceptación.

La pirámide de pruebas enfatiza tener una gran cantidad de pruebas en los niveles inferiores (parte inferior de la pirámide) y, a medida que el desarrollo se mueve hacia los niveles superiores, el número de pruebas disminuye (parte superior de la pirámide), por lo general, las pruebas de nivel de unidad y de integración están automatizadas y se crean utilizando herramientas basadas en API, en los niveles de sistema y aceptación, las pruebas automatizadas se crean utilizando herramientas basadas en GUI, el concepto de pirámide de prueba se basa en el principio de prueba de control de calidad y prueba tempranos (es decir, eliminar defectos lo antes posible en el ciclo de vida).

 

Cuadrantes de prueba, niveles de prueba y tipos de prueba

Los cuadrantes de prueba, definidos por Brian Marick, alinean los niveles de prueba con los tipos de prueba apropiados en la metodología Agile, el modelo de cuadrantes de prueba y sus variantes ayudan a garantizar que todos los tipos y niveles de prueba importantes se incluyan en el ciclo de vida del desarrollo, este modelo también proporciona una forma de diferenciar y describir los tipos de pruebas a todas las partes interesadas, incluidos desarrolladores, evaluadores y representantes comerciales.

En los cuadrantes de prueba, las pruebas pueden ser comerciales (usuario) o tecnológicas (desarrollador), algunas pruebas respaldan el trabajo realizado por el equipo Agile y confirman el comportamiento del software, otras pruebas pueden verificar el producto, las pruebas pueden ser completamente manuales, completamente automatizadas, una combinación de manual y automatizado, o manuales pero con el apoyo de herramientas.

Los cuatro cuadrantes son los siguientes:

• El cuadrante Q1: es a nivel de pruebas unitarias, orientado hacia la tecnología y apoyo a los desarrolladores. Este cuadrante contiene pruebas unitarias, estas pruebas deben automatizarse e incluirse en el proceso de integración continua.
• El cuadrante Q2:  es a nivel de sistema, orientado al negocio y confirma el comportamiento del producto. Este cuadrante contiene pruebas funcionales, por ejemplo, pruebas de historias, prototipos de experiencia de usuario y simulaciones, estas pruebas verifican los criterios de aceptación y pueden ser manuales o automatizadas, amenudo se crean durante el desarrollo de la historia del usuario y, por lo tanto, mejoran la calidad de las historias, son útiles al crear conjuntos de pruebas de regresión automatizados.
• El cuadrante Q3: es el nivel de aceptación del sistema o del usuario, orientado al negocio y contiene pruebas que critican el producto, utilizando escenarios y datos realistas, este cuadrante contiene pruebas exploratorias, escenarios, flujos de procesos, pruebas de usabilidad, pruebas de aceptación del usuario, pruebas alfa y pruebas beta, estas pruebas suelen ser manuales y están orientadas al usuario.
• El cuadrante Q4: es el nivel de aceptación operativa o del sistema, que enfrenta la tecnología y contiene pruebas que critican el producto, este cuadrante contiene pruebas de rendimiento, carga, estrés y escalabilidad, pruebas de seguridad, mantenibilidad, administración de memoria, compatibilidad e interoperabilidad, migración de datos, infraestructura y pruebas de recuperación, estas pruebas suelen estar automatizadas.

Durante cualquier iteración dada, es posible que se requieran pruebas de cualquiera o todos los cuadrantes; los cuadrantes de prueba se aplican a pruebas dinámicas en lugar de pruebas estáticas.

 

El papel de un probador

A lo largo de lo estudiado, se ha hecho referencia general a los métodos y técnicas ágiles, y al papel de un evaluador dentro de varios ciclos de vida ágiles, esta subsección analiza específicamente el rol de un evaluador en un proyecto que sigue un ciclo de vida de Scrum

Trabajo en equipo:

El trabajo en equipo es un principio fundamental en el desarrollo ágil, agile enfatiza el enfoque de equipo completo que consiste en desarrolladores, evaluadores y representantes comerciales que trabajan juntos, las siguientes son las mejores prácticas organizacionales y de comportamiento en los equipos Scrum:

• Interfuncional: cada miembro del equipo aporta un conjunto diferente de habilidades al equipo, el equipo trabaja en conjunto en la estrategia de prueba, planificación de prueba, especificación de prueba, ejecución de prueba, evaluación de prueba e informes de resultados de prueba.

• Autoorganización: el equipo puede estar formado únicamente por desarrolladores, pero, lo ideal sería que hubiera uno o más probadores.

• Ubicación conjunta: los probadores se sientan junto con los desarrolladores y el propietario del producto.

• Colaborativo: los probadores colaboran con los miembros de su equipo, otros equipos, las partes interesadas, el propietario del producto y el Scrum Master.

• Empoderado: las decisiones técnicas con respecto al diseño y las pruebas las toma el equipo en su conjunto (desarrolladores, probadores y Scrum Master), en colaboración con el propietario del producto y otros equipos si es necesario.

• Comprometido: El tester se compromete a cuestionar y evaluar el comportamiento y las características del producto con respecto a las expectativas y necesidades de los clientes y usuarios.

• Transparente: el progreso del desarrollo y las pruebas es visible en el panel de tareas de Agile 

• Creíble: el evaluador debe garantizar la credibilidad de la estrategia de prueba, su implementación y ejecución; de lo contrario, las partes interesadas no confiarán en los resultados de la prueba, esto se hace a menudo proporcionando información a las partes interesadas sobre el proceso de prueba.

• Abierto a comentarios: los comentarios son un aspecto importante para tener éxito en cualquier proyecto, especialmente en proyectos ágiles, las retrospectivas permiten a los equipos aprender de los éxitos y los fracasos.

• Resiliente: las pruebas deben poder responder al cambio, como todas las demás actividades en proyectos ágiles.

Estas mejores prácticas maximizan la probabilidad de pruebas exitosas en proyectos Scrum.

Sprint cero:

Sprint zero es la primera iteración del proyecto en la que se llevan a cabo muchas actividades de preparación. El evaluador colabora con el equipo en las siguientes actividades durante esta iteración:

• Identificar el alcance del proyecto (es decir, la cartera de productos)

• Crear una arquitectura de sistema inicial y prototipos de alto nivel.

• Planificar, adquirir e instalar las herramientas necesarias por ejemplo, (para la gestión de pruebas, gestión de defectos, automatización de pruebas e integración continua)

• Crear una estrategia de prueba inicial para todos los niveles de prueba, abordando (entre otros temas) el alcance de la prueba, los riesgos técnicos, los tipos de prueba y los objetivos de cobertura.

• Realizar un análisis de riesgo de calidad inicial

• Definir métricas de prueba para medir el proceso de prueba, el progreso de las pruebas en el proyecto y la calidad del producto.

• Especificar la definición de "hecho"

• Cree el tablero de tareas

• Definir cuándo continuar o detener la prueba antes de entregar el sistema al cliente.

Sprint zero establece la dirección de lo que las pruebas deben lograr y cómo las pruebas deben lograrlo a lo largo de los sprints.

Integración

En los proyectos ágiles, el objetivo es ofrecer valor al cliente de forma continua (preferiblemente en cada sprint). Para permitir esto, la estrategia de integración debe considerar tanto el diseño como las pruebas; para habilitar una estrategia de prueba continua para la funcionalidad y las características entregadas, es importante identificar todas las dependencias entre las funciones y características subyacentes.

Planificación de pruebas:

Dado que las pruebas están completamente integradas en el equipo Agile, la planificación de las pruebas debe comenzar durante la sesión de planificación del lanzamiento y actualizarse durante cada sprint.

La planificación de Sprint da como resultado un conjunto de tareas para colocar en el tablero de tareas, donde cada tarea debe tener una duración de uno o dos días de trabajo, además, se debe rastrear cualquier problema de prueba para mantener un flujo constante de pruebas.