Rol de prueba en Scrum

Antecedentes de Scrum

Madison planea comenzar a usar Scrum, una metodología ágil, con su equipo de proyecto. Su equipo ha escuchado un poco sobre Agile y Scrum, incluido el objetivo de que el equipo sea multifuncional. Los evaluadores de su equipo han mostrado cierta preocupación. No conocen el desarrollo web y les preocupa que no sean útiles en Scrum y eventualmente sean reemplazados. Madison comprende sus preocupaciones pero les asegura que no son ciertas. No solo serán útiles en Scrum, sino que también desempeñarán un papel más importante que nunca antes.

Propósito

Agile es un enfoque de proyectos que se aleja de las metodologías tradicionales que dividen los proyectos en fases que deben completarse en orden secuencial. Esto requiere poca interacción entre los individuos de cada fase. En cambio, Agile enfatiza la participación de las personas durante todo el proceso, creando más colaboración e interacciones. El objetivo es llegar a un entendimiento común de lo que se necesita, generar la propiedad de todos los involucrados a través del compromiso y luego producir resultados de calidad.

Hay una serie de metodologías que se utilizan para implementar Agile. Scrum es el más popular. Desglosa el trabajo del proyecto y los plazos del proyecto para hacerlos más manejables. El trabajo toma la forma de historias de usuario , que brindan funcionalidad para usuarios finales específicos. Están escritos a un alto nivel para que los miembros del equipo puedan agregar más detalles a través de la discusión. Las historias de usuario se completan en ciclos repetidos conocidos como sprints , que son la forma desglosada de la línea de tiempo. La producción de resultados tangibles en intervalos más frecuentes (y en cantidades más pequeñas) tiene como objetivo mejorar la calidad.

Equipo

Único en Scrum son los diferentes roles que componen el equipo Scrum. Estos incluyen el Product Owner, Scrum Master y el equipo de desarrollo. El propietario del producto es el principal interesado responsable de las historias de los usuarios. Otros dan su opinión, pero el propietario del producto es quien toma las decisiones, asegurando que se construya el producto correcto. El Scrum Master supervisa el proceso de Scrum y facilita las interacciones del equipo del proyecto. El objetivo es garantizar que las cosas se hagan de la manera correcta.

El equipo de desarrollo completa el equipo de Scrum y es responsable de desarrollar y probar el producto según los criterios de las historias de usuario. En Scrum, el objetivo es que el equipo de desarrollo sea multifuncional, que es lo que intimida a los evaluadores del equipo de Madison. Lo interpretan como multifuncional, pensando que deben poder desarrollarlo y probarlo. Madison les asegura que este no es el caso y que el énfasis no está en poder realizar todas las funciones, sino en funcionar y estar comprometido con las historias de los usuarios a lo largo del sprint.

Rol de prueba

Para Madison y su equipo, el rol de prueba en Scrum no es un puesto o trabajo específico para un individuo. El uso de este enfoque, como hacen las metodologías tradicionales, mantiene los roles distintos o separados, lo que reduce las interacciones porque es innecesario. Esto va directamente en contra de la colaboración que está en el corazón de Scrum. En Scrum, la función de prueba ya no se limita a la función de medición. En cambio, la función de prueba tiene más que ver con el conjunto de habilidades de las personas que sobresalen en esa función. Las habilidades utilizadas en las pruebas, como resolución de problemas, análisis, pensamiento crítico, etc., son valiosas a lo largo del proyecto. Esta es la razón por la que los probadores de Madison tendrán un papel más importante en Scrum porque contribuirán a cada aspecto del proceso.

Requisitos

En Scrum, las historias de usuario describen la funcionalidad a un alto nivel, pero el objetivo es agregar detalles específicos a través de la discusión entre el Product Owner y el equipo de desarrollo. Estos detalles específicos se conocen como criterios de aceptación , que proporcionan las condiciones que deben cumplirse en la historia del usuario. Por ejemplo, una historia de usuario que se centre en la funcionalidad de inicio de sesión tendría criterios de aceptación sobre la capacidad de ingresar un nombre de usuario, la capacidad de ingresar una contraseña, la validación para determinar si el nombre de usuario y la contraseña son correctos, etc. Un aspecto del rol de prueba es escribir, o al menos contribuir a los criterios de aceptación.

Además de la función específica asociada con los criterios de aceptación, la función de prueba tiene una participación más amplia en los requisitos. Las habilidades analíticas y la atención al detalle que son necesarias para las pruebas se pueden aplicar a la revisión de los requisitos para asegurarse de que sean válidos y que detallen todo lo que se necesita sin que falte nada. Sin esto, aumenta la probabilidad de confusión y malentendidos.

Desarrollo

Una vez que se escriben las historias de usuario y los criterios de aceptación, puede comenzar el desarrollo. La función de prueba en el desarrollo no requiere realizar un desarrollo web real, como creían los evaluadores de Madison. Tampoco significa que los probadores simplemente estén esperando que se entregue el código como en las metodologías tradicionales. En cambio, los evaluadores pueden trabajar junto con los desarrolladores para ayudar a asegurarse de que los requisitos se comprendan completamente y brindar información sobre los escenarios negativos que podrían no abordarse explícitamente.

Por ejemplo, en el escenario de inicio de sesión, un evaluador podría pensar en hacer clic en el botón de inicio de sesión varias veces seguidas. Esto puede llevar al desarrollador a deshabilitar el botón después del primer clic mientras se carga la página. Conocer las formas en que el evaluador intentaría descifrar el código podría afectar la forma en que está construido y evitar que se vuelva a trabajar más adelante.

Pruebas

Una vez finalizado el desarrollo, se deben confirmar los criterios de aceptación. Este aspecto del rol de evaluador se alinea más con las metodologías tradicionales. Sin embargo, en Scrum, las pruebas no consisten únicamente en medir los resultados reales contra los resultados esperados. También implica trabajar junto con el propietario del producto una vez que se completan las pruebas para confirmar que la funcionalidad cumple con las expectativas. El probador proporciona demostraciones en vivo al propietario del producto y potencialmente a otras partes interesadas, obteniendo la aprobación del trabajo.

Resumen de la lección

Agile pone énfasis en el compromiso, la colaboración y las interacciones para producir calidad. Scrum , una de las metodologías utilizadas para implementar Agile, divide el trabajo del proyecto en historias de usuario y la línea de tiempo del proyecto en sprints para lograr los énfasis de Agile. Único en Scrum es el equipo Scrum, que está formado por un Product Owner , Scrum Mastery el equipo de desarrollo, y su tratamiento de los roles tradicionales, particularmente el rol de prueba. La función de prueba en Scrum implica participar en los diversos aspectos del proceso del proyecto, incluidos los requisitos, el desarrollo y las pruebas, con las habilidades necesarias para la función de prueba. Para los requisitos, la función de prueba implica analizar historias de usuarios, así como escribir criterios de aceptación para ellas. En el desarrollo, la función de prueba es trabajar junto con los desarrolladores para asegurarse de que se comprendan los requisitos explícitos e implícitos. En las pruebas, el rol se expande más allá de la función para incluir interacciones con el propietario del producto para mostrar la funcionalidad y confirmar que se cumplen las expectativas.