Pruebas ágiles - Scrum
Defensores de Scrum Whole Team Approach, en el sentido de que todos los miembros del equipo deben participar en todas las actividades del proyecto. El equipo de Scrum se autoorganiza y se responsabiliza de los entregables del proyecto. La toma de decisiones se deja en manos del equipo, lo que da como resultado que se tomen las acciones adecuadas en el momento adecuado sin demoras. Este enfoque también fomenta el uso adecuado del talento del equipo en lugar de limitarse a una actividad. Los probadores también participan en todos los proyectos y actividades de desarrollo aportando su experiencia en pruebas.
Todo 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.
Creación colaborativa de historias de usuario
Los probadores participan en la creación de historias de usuario. Los probadores aportan sus ideas sobre el posible comportamiento del sistema. Esto ayuda a que el cliente y / o el usuario final comprendan el sistema en el entorno real y así obtengan claridad sobre lo que realmente quieren como resultado. Esto da como resultado una congelación más rápida de los requisitos y también reduce la probabilidad de cambios en los requisitos más adelante.
Los evaluadores también elaboran los Criterios de aceptación para cada escenario acordado por el cliente.
Los probadores contribuyen a la creación de historias de usuarios comprobables.
Planificación de lanzamiento
La planificación de la versión se realiza para todo el proyecto. Sin embargo, el marco de Scrum implica una toma de decisiones iterativa a medida que se obtiene más información a su debido tiempo de la ejecución de los sprints. Por lo tanto, la sesión de Planificación de la versión al comienzo del proyecto no necesita producir un plan de entrega detallado para todo el proyecto. Puede actualizarse continuamente, a medida que se disponga de información relevante.
Cada sprint-end no necesita tener un lanzamiento. Una liberación puede ser después de un grupo de sprints. El criterio principal de un lanzamiento es entregar valor comercial al cliente. El equipo decide la duración del sprint con la planificación del lanzamiento como entrada.
La planificación de la versión es la base del enfoque de prueba y el plan de prueba para la versión. Los probadores estiman el esfuerzo de prueba y planifican las pruebas para el lanzamiento. Cuando los planes de lanzamiento cambian, los evaluadores deben manejar los cambios, obtener una base de prueba adecuada considerando un contexto más amplio de lanzamiento. Los probadores también proporcionan el esfuerzo de prueba que se requiere al final de todos los sprints.
Planificación de Sprint
La planificación del sprint se realiza al comienzo de cada sprint. El backlog del sprint se crea con las historias de usuario recogidas del backlog del producto para su implementación en ese sprint en particular.
Los probadores deberían:
- Determinar la capacidad de prueba de las historias de usuario seleccionadas para el sprint.
- Crea pruebas de aceptación
- Definir niveles de prueba
- Identificar la automatización de pruebas
Los evaluadores actualizan el plan de pruebas con las estimaciones del esfuerzo y la duración de las pruebas en el sprint. Esto asegura la provisión de tiempo para las pruebas requeridas durante los sprints encuadrados en el tiempo y también la responsabilidad del esfuerzo de prueba.
Análisis de prueba
Cuando comienza un sprint, mientras los desarrolladores realizan el análisis de historias para el diseño y la implementación, los evaluadores realizan análisis de prueba para las historias en el backlog del sprint. Tester crea los casos de prueba necesarios, tanto pruebas manuales como automatizadas.
Pruebas
Todos los miembros del equipo Scrum deben participar en las pruebas.
Los desarrolladores ejecutan las pruebas unitarias a medida que desarrollan el código para las historias de usuario. Las pruebas unitarias se crean en cada sprint, antes de que se escriba el código. Los casos de prueba unitaria se derivan de especificaciones de diseño de bajo nivel.
Los probadores realizan características funcionales y no funcionales de las historias de usuario.
Los evaluadores asesoran a los otros miembros del equipo scrum con su experiencia en pruebas para que todo el equipo tenga una responsabilidad colectiva por la calidad del producto.
Al final del sprint, el cliente y / o los usuarios finales llevan a cabo las pruebas de aceptación del usuario y brindan comentarios al equipo de scrum. Esto se forma como una entrada para el próximo sprint.
Los resultados de las pruebas se recopilan y mantienen.
Pruebas de automatización
Las pruebas de automatización tienen una gran importancia en los equipos Scrum. Los probadores dedican tiempo a crear, ejecutar, monitorear y mantener pruebas y resultados automatizados. Como los cambios pueden ocurrir en cualquier momento en los proyectos scrum, los evaluadores deben adaptarse a las pruebas de las características cambiadas y también a las pruebas de regresión involucradas. Las pruebas de automatización facilitan la gestión del esfuerzo de prueba asociado con los cambios. Las pruebas automatizadas en todos los niveles facilitan lograr una integración continua. Las pruebas automatizadas se ejecutan mucho más rápido que las pruebas manuales sin ningún esfuerzo adicional.
Las pruebas manuales se centran más en las pruebas exploratorias, la vulnerabilidad del producto y la predicción de defectos.
Automatización de actividades de prueba
La automatización de las actividades de prueba reduce la carga del trabajo repetido y genera ahorros de costos. Automatizar
- Generación de datos de prueba
- Carga de datos de prueba
- Construya la implementación en el entorno de prueba
- Gestión del entorno de prueba
- Comparación de salida de datos
Pruebas de regresión
En un sprint, los probadores prueban el código nuevo / modificado en ese sprint. Sin embargo, los evaluadores también deben asegurarse de que el código desarrollado y probado en los sprints anteriores también funcione junto con el nuevo código. Por lo tanto, se le da importancia a las pruebas de regresión en scrum. Las pruebas de regresión automatizadas se ejecutan en integración continua.
Gestión de la configuración
En los proyectos Scrum se utiliza un sistema de gestión de la configuración que utiliza marcos de prueba y compilación automatizados. Esto permite ejecutar análisis estáticos y pruebas unitarias repetidamente a medida que se ingresa un nuevo código en el Sistema de gestión de la configuración. También gestiona la integración continua del nuevo código con el sistema. Las pruebas de regresión automatizadas se ejecutan durante la integración continua.
Los casos de prueba manuales, las pruebas automatizadas, los datos de prueba, los planes de prueba, la estrategia de prueba y otros artefactos de prueba deben estar controlados por versiones y requieren los permisos de acceso pertinentes para garantizarse. Esto se puede lograr manteniendo los artefactos de prueba en el sistema de gestión de la configuración.
Prácticas de prueba ágiles
Los probadores de un equipo Scrum pueden seguir las siguientes prácticas ágiles:
Pairing- Dos miembros del equipo se sientan juntos y trabajan en colaboración. Las dos personas pueden ser dos probadores o un probador y un desarrollador.
Incremental Test Design - Los casos de prueba se desarrollan a medida que los Sprints progresan de forma incremental y se suman las historias de usuario.
Métricas ágiles
Durante el desarrollo del software, la recopilación y el análisis de métricas ayudan a mejorar el proceso y así lograr una mejor productividad, entregables de calidad y satisfacción del cliente. En el desarrollo basado en Scrum, esto es posible y los evaluadores deben prestar atención a las métricas que necesitan.
Se sugieren varias métricas para el desarrollo de Scrum. Las métricas importantes son:
Ratio of Successful Sprints - (Number of successful Sprints / Total number of Sprints) * 100. Un Sprint exitoso es aquel en el que el equipo podría cumplir con su compromiso.
Velocity- La velocidad de un equipo se basa en la cantidad de Story Points que un equipo ganó durante un sprint. Los puntos de historia son la medida de las historias de usuario contadas durante la estimación.
Focus Factor - (Velocity / Team’s Work Capacity) / 100. El factor de enfoque es el porcentaje del esfuerzo del equipo que da como resultado historias terminadas.
Estimation Accuracy - (Estimated effort / Actual effort) / 100. La precisión de la estimación es la capacidad del equipo para estimar el esfuerzo con precisión.
Sprint Burndown- Trabajo (en Story Points o en horas) restante vs. Trabajo que debe quedar idealmente restante (según la estimación).
Si es más, significa que el equipo ha asumido más trabajo del que puede hacer.
Si es menor, significa que el equipo no estimó con precisión.
Defect Count- Número de defectos en un Sprint. El recuento de defectos es la cantidad de defectos en el software en comparación con la acumulación.
Severity of Defects- Los defectos se pueden clasificar como menores, mayores y críticos según su gravedad. Los evaluadores pueden definir la categorización.
Retrospectivas de Sprint
En Sprint Retrospectives, todos los miembros del equipo participarán. Ellos comparten -
- Las cosas que salieron bien
- Metrics
- El alcance de las mejoras
- Elementos de acción para aplicar