Tutorial de metodología de pruebas Scrum

Scrum en pruebas de software

Scrum en pruebas de software Scrum es una metodología para la creación de aplicaciones de software complejas. Proporciona soluciones sencillas para la ejecución de tareas complicadas. Scrum ayuda al equipo de desarrollo a centrarse en todos los aspectos del desarrollo del producto de software, incluyendo la calidad, el rendimiento y la usabilidad. Ofrece transparencia, inspección y adaptación durante el desarrollo del software para evitar la complejidad.

Pruebas Scrum

Pruebas Scrum Las pruebas se realizan en la metodología Scrum para verificar que se cumplan los requisitos de la aplicación de software. Implica comprobar parámetros no funcionales como la seguridad, la usabilidad y el rendimiento. No hay un rol activo de probador en el proceso, por lo que generalmente lo realizan los desarrolladores con pruebas unitarias. A veces se necesitan equipos de prueba dedicados dependiendo de la naturaleza y complejidad del proyecto. Los equipos modernos a menudo coordinan este trabajo en Jira, Linear, Azure DevOps, o Asana.

Características clave de la metodología Scrum

A continuación se presentan las características clave de Scrum:

• Scrum tiene un cronograma corto y fijo de ciclos de lanzamiento con alcance ajustable, conocido como Sprintspara abordar las necesidades de desarrollo que cambian rápidamente. Cada lanzamiento puede tener múltiples Sprints. Cada proyecto Scrum puede tener múltiples ciclos de lanzamiento.
• una secuencia repetitiva de reuniones, eventos e hitos.
• Una práctica de probar e implementar nuevos requisitos, conocida como Historias, para asegurarnos de que algún trabajo esté listo para su lanzamiento después de cada Sprint.

Scrum se basa en los siguientes 3 pilares:

Analicémoslos uno por uno.

1. Roles en Scrum

En las pruebas Scrum, existen tres roles principales: el propietario del producto, el Scrum Master y el equipo de desarrollo. Analicemos cada uno de ellos en detalle.

Dueño del Producto	Scrum Master	Equipo
Él o ella define las características del producto.	Él o ella dirige el equipo y vela por su productividad.	El equipo suele estar formado por entre 5 y 9 miembros.
El Product Owner decide la fecha de lanzamiento y las características correspondientes.	Él o ella mantiene la lista de bloqueos y elimina los obstáculos al desarrollo.	Incluye desarrolladores, diseñadores y, en ocasiones, evaluadores.
Priorizan las características en función del valor de mercado y la rentabilidad del producto.	Él o ella coordina con todos los roles y funciones.	El equipo organiza y planifica su trabajo por su cuenta.
Él o ella es responsable de la rentabilidad del producto.	Él o ella protege al equipo de interferencias externas.	Tiene derecho a hacer todo dentro de los límites del proyecto para cumplir con los requisitos. Sprint Gol.
Él o ella puede aceptar o rechazar los resultados de la tarea.	Invitaciones a la reunión diaria de Scrum, Sprint Revvistas y reuniones de planificación.	Participa activamente en las ceremonias diarias.

2. Artefactos de Scrum

Un proceso Scrum incluye:

• Historias de usuarios: Se trata de una breve explicación de las funcionalidades del sistema que se está probando. Un ejemplo para una compañía de seguros sería: «La prima se puede pagar mediante el sistema en línea».
• Pila de Producto: Se trata de una colección de historias de usuario recopiladas para un producto Scrum. El Product Owner se prepara y mantiene el Product Backlog. Es priorizado por el Product Owner, y cualquiera puede agregarle con la aprobación del Product Owner. Los equipos modernos mantienen el Product Backlog en Jira, Linear, Azure DevOps, o Asana.
• Pendientes de lanzamiento: Un lanzamiento es un período de tiempo durante el cual se completan varias iteraciones. El Product Owner coordina con el Scrum Master para decidir qué historias deben incluirse en una versión. Las historias en el Release Backlog están destinadas a completarse en una versión.
• Sprints: Se trata de un periodo de tiempo determinado para completar las historias de usuario, acordado por el Product Owner y el equipo de desarrollo, que suele ser de 2 a 4 semanas.
• Sprint Reserva: Es un conjunto de historias de usuario que deben completarse en un Sprint. Durante Sprint Backlog, el trabajo nunca se asigna y el equipo se inscribe para trabajar por su cuenta. Es propiedad del equipo y está gestionado por él, mientras que el trabajo restante estimado se actualiza diariamente. Es la lista de tareas que deben realizarse en un Sprint.
• Lista de bloqueos: Es una lista de bloqueos y decisiones pendientes a cargo del Scrum Master, que se actualiza diariamente.
• Cuadro de incendio: El gráfico de progreso (burndown chart) representa el avance general del trabajo en curso y del trabajo completado a lo largo del proceso. Representa gráficamente las historias y funcionalidades que aún no se han completado.

3. Ceremonias (Procesos) en Scrum

• Sprint Planificación: A Sprint comienza con el equipo importando historias del Release Backlog al Sprint Backlog; está alojado por el Scrum Master. Los evaluadores estiman el esfuerzo para probar las distintas historias en el Sprint Atrasos
• Levantamiento diario: También llamado Daily Scrum, es presentado por el Scrum Master y dura aproximadamente 15 minutos. Durante el Daily Stand-up, los miembros discuten el trabajo completado el día anterior, el trabajo planificado para el día siguiente y los problemas encontrados durante un SprintEl progreso del equipo es tracked aquí.
• Sprint RevVista / Retrospectiva: También está dirigida por el Scrum Master, dura entre 2 y 4 horas y analiza lo que el equipo ha logrado en el último período. Sprint y qué lecciones se aprendieron.

Una vez establecidos los roles, artefactos y ceremonias de Scrum, es importante aclarar exactamente dónde encajan los evaluadores dentro de este marco.

Papel del probador en Scrum

No existe un rol activo de Tester en Scrum proceso. Por lo general, las pruebas las lleva a cabo un desarrollador con pruebas unitarias, mientras que el propietario del producto también participa frecuentemente en el proceso de pruebas durante cada Sprint. Algunos proyectos Scrum cuentan con equipos de prueba dedicados, dependiendo de la naturaleza y complejidad del proyecto..

La siguiente pregunta es: ¿qué hace un tester en Scrum? La siguiente sección responderá a esa pregunta.

Actividades de prueba en Scrum

Los evaluadores realizan las siguientes actividades durante las distintas etapas de Scrum:

Sprint Planificación

• In Sprint En la fase de planificación, el evaluador debe elegir una historia de usuario del Product Backlog que deba ser probada.
• Como probador, debe decidir cuántas horas (estimación del esfuerzo) debería tomar. para terminar pruebas para cada una de las historias de usuario seleccionadas.
• Como evaluador, debe saber qué es lo que se debe hacer. Sprint Los objetivos son.
• Como evaluador, contribuye al proceso de priorización.

Sprint

• Brindar soporte a los desarrolladores en las pruebas unitarias.
• Pruebe la historia de usuario una vez finalizada. Se realiza la ejecución de la prueba. en un laboratorio donde tanto el probador como el desarrollador trabajan mano a mano. Los defectos se registran en un Herramienta de gestión de defectos y tracSe revisan diariamente. Los defectos se pueden comunicar y analizar durante la reunión de Scrum. Los defectos se vuelven a probar tan pronto como se detectan. resuelto y se implementó para pruebas. Los equipos Scrum modernos suelen usar Jira, Linear, Azure DevOps, o Asana para este flujo de trabajo.
• Como evaluador, asiste a todas las reuniones diarias de seguimiento para expresar su opinión.
• Como probador, puede traer cualquier elemento pendiente que no se pueda completar en el actual. Sprint y ponerlo en el siguiente Sprint.
• El probador es responsable del desarrolloping scripts de automatización. Él o ella programa pruebas de automatización con un Sistema de integración continua (CI)La automatización cobra importancia debido a los plazos de entrega ajustados. La automatización de pruebas se puede lograr utilizando diversas herramientas de código abierto o de pago disponibles en el mercado. Esto resulta eficaz para garantizar que se cubra todo lo que se necesita probar. Se puede lograr una cobertura de pruebas suficiente con una comunicación fluida dentro del equipo.
• RevRevisar los resultados de la automatización de CI y enviar informes a las partes interesadas.
• Realizar pruebas no funcionales para las historias de usuario aprobadas.
• Coordinar con el cliente y el propietario del producto para definir los criterios de aceptación para las pruebas de aceptación.
• Al final de la Sprint, el probador también realiza pruebas de aceptación (UAT) en algunos casos y confirma la completitud de las pruebas para el actual Sprint.

Sprint Retrospectivo

• Como probador, él o ella determinará qué salió mal y qué salió bien en el actual Sprint.
• Como evaluador, identifica las lecciones aprendidas y las mejores prácticas.

Una vez que estas actividades de prueba estén en marcha, SprintLos equipos dependen de métricas claras para comunicar el progreso, y es ahí donde la elaboración de informes de pruebas se vuelve esencial.

Informe de prueba

Los informes de métricas de pruebas de Scrum brindan transparencia y visibilidad a las partes interesadas sobre el proyecto. Las métricas que se informan permiten a un equipo analizar su progreso y planificar su estrategia futura para mejorar el producto. Herramientas como Jira, Linear, Azure DevOps y Asana Generan automáticamente muchos de estos informes. Hay dos métricas que se utilizan con frecuencia para informar.

Cuadro de incendio: Cada día, el Scrum Master registra el trabajo restante estimado para el SprintEste es el gráfico de progreso, actualizado diariamente.

Un gráfico de quebrado ofrece una visión general rápida del progreso del proyecto. Este gráfico contiene información como la cantidad total de trabajo del proyecto que debe completarse, la cantidad de trabajo completado durante cada Sprint, Y así sucesivamente.

Gráfico de historial de velocidad: El gráfico del historial de velocidad predice la velocidad que alcanza el equipo en cada SprintSe trata de un gráfico de barras que representa cómo ha cambiado el rendimiento del equipo a lo largo del tiempo.

Otras métricas que pueden resultar útiles son el avance del cronograma, el avance del presupuesto, el porcentaje de temas completados, las historias completadas, las historias restantes, etc.

Preguntas Frecuentes