Tareas de prueba en Scrum

Melé

Grace es una directora de proyectos que supervisa directamente un equipo de probadores y analistas de negocios. Su empresa utiliza una metodología de proyectos tradicional y ha recibido comentarios de su equipo de que este enfoque no está funcionando. Existe una interacción mínima entre los desarrolladores y los evaluadores porque cada uno se involucra solo durante su etapa del proceso. Esto conduce a problemas de comunicación y solicitudes de cambio significativas. Grace cree que cambiar a la metodología del proyecto Scrum sería beneficioso.

Scrum es una metodología que se enmarca en Agile, un enfoque de gestión de proyectos que busca ofrecer una alternativa a las metodologías de proyectos tradicionales. El objetivo de Scrum es abordar el trabajo del proyecto en segmentos más pequeños, conocidos como historias de usuario, que identifican la funcionalidad de alto nivel deseada para usuarios específicos. También implica periodos de tiempo más cortos y repetidos conocidos como sprints . En este enfoque, todo el equipo puede participar de manera constante, colaborar entre sí y ser más eficiente. Además, las partes interesadas ven el trabajo con más frecuencia, por lo que los cambios que deben realizarse tienen menos impacto.

El énfasis de Scrum aborda directamente las preocupaciones y frustraciones del equipo de Grace. Confía en que toda la empresa se beneficiará del uso de Scrum. Sin embargo, antes de presentar la idea a la empresa, quiere que su equipo comprenda Scrum y, en particular, cómo funcionarán en él, para obtener realmente su apoyo. En particular, se centra en las pruebas, respondiendo a las preguntas de quién lo hace, qué implica y cuándo ocurre.

Quién completa las tareas de prueba

Al discutir quién completa las tareas de prueba, Grace está abordando dos elementos clave con su equipo. El primero es quién completa estas tareas. El segundo es el papel de sus evaluadores o cómo encajan en el equipo del proyecto en su conjunto.

Rol versus función

En una metodología de proyecto tradicional, como la que utiliza actualmente el equipo de Grace, la función de testeo y el rol del tester son uno en este mismo. Las tareas de prueba son realizadas por personas designadas a quienes, en función del desempeño de esta función, se les asigna el rol de probador. Esto significa que los probadores se centran exclusivamente en las tareas de prueba. El beneficio es que las pruebas las realizan personas calificadas, pero lo que se pierde es la participación y el compromiso de estas personas en el proceso más allá de las pruebas.

En Scrum, las pruebas son una de las funciones realizadas por un equipo que es multifuncional. La responsabilidad y la capacidad para completar estas tareas recae en todo el equipo, no solo en un grupo específico de personas. En la práctica, las pruebas a menudo las completan personas con habilidades en esta área y normalmente cumplirían un rol de evaluador, pero esto no se requiere ni se define explícitamente en Scrum. En cambio, los roles son intencionalmente más ambiguos, de modo que la participación individual no se limita a un conjunto de tareas, sino que puede ser cualquier área del proyecto donde puedan agregar valor. Las habilidades que se utilizan para completar las tareas de prueba son aplicables a todo el proyecto.

Tareas de prueba

Una vez que Grace ayuda a su equipo a comprender la diferencia entre la función y el rol de las pruebas, y cómo eso encaja en el equipo Scrum, pasa a lo que implican las pruebas. Las tareas de prueba tradicionales están presentes, pero hay funciones adicionales que pueden completar las personas que tienen el conjunto de habilidades útiles en las pruebas, como el pensamiento crítico, dividir elementos de alto nivel en detalles de nivel más bajo e identificar lo que se espera y lo que realmente ocurre.

En Scrum, el equipo de Grace estará involucrado desde el principio, a medida que se establezcan los requisitos del proyecto. Las historias de usuario se escriben en un nivel alto con la intención de que los detalles de nivel inferior se desarrollen mediante la discusión y la colaboración. Los detalles de nivel inferior son condiciones que deben cumplirse para que las historias de usuario se consideren completas, que se denominan criterios de aceptación . Por lo general, los escriben probadores porque consisten en acciones y resultados esperados, al igual que los casos de prueba.

Una vez que se escriben los criterios de aceptación y el equipo asume las historias de los usuarios, las tareas de prueba no se detienen. Los criterios de aceptación tienen una influencia significativa en cómo se desarrollan las historias de usuarios. A medida que se realiza el desarrollo, existe una colaboración entre las personas que desarrollan historias de usuarios y las personas que las probarán para abordar de forma proactiva tantas áreas como sea posible que podrían crear errores o tener resultados no deseados. Luego, a medida que se completa el desarrollo, se realizan pruebas para verificar que se hayan cumplido los criterios de aceptación. Esto puede implicar cualquier combinación de pruebas manuales, automatizadas y de rendimiento.

Una vez completada la prueba de las historias de usuario, queda una tarea de prueba restante. Esto es para mostrar las historias de los usuarios a las partes interesadas a fin de recibir comentarios y aprobación. Normalmente, las demostraciones se dan en vivo en un entorno de prueba para que las partes interesadas puedan ver la funcionalidad solicitada. Este paso es importante porque no solo obtiene la confirmación de que el trabajo está completo, sino que solicita comentarios que pueden abordarse antes de realizar trabajos adicionales que deberían rehacerse si se hicieran cambios.

¿Cuándo ocurren las pruebas?

Lo último que Grace comenta con su equipo es cuándo ocurren las distintas tareas y funciones de prueba. Si bien se hizo referencia indirectamente en la discusión sobre lo que implican las pruebas, ella quiere ser explícita con su equipo de que las pruebas están involucradas en cada sprint y en todo el proyecto hasta cierto punto. En Scrum, los probadores no se limitan a una etapa específica del proceso porque las pruebas no son solo una etapa específica del proceso. Las pruebas están involucradas de principio a fin en cada sprint, lo que significa que su equipo desempeñará un papel mucho más activo en sus proyectos.

Resumen de la lección

Scrum es un enfoque ágil para proyectos que divide el trabajo del proyecto en historias de usuario y divide la línea de tiempo del proyecto en sprints , durante los cuales se completan las historias de usuario. Esto permite que el equipo se involucre en todo momento, no solo en etapas específicas. En Scrum, las pruebas son una función para todo el equipo, no solo un conjunto específico de personas con el rol de tester. Además, las tareas de prueba que se completan no se limitan a un proceso de prueba. Desde el principio, las pruebas son una parte importante del proceso porque los criterios de aceptacióndebe estar escrito para historias de usuario, generalmente realizado por probadores. Esto influye en cómo se realiza el desarrollo en las historias de usuario, lo que lleva a la colaboración mientras se desarrolla. Una vez que se completa el desarrollo, se realizan pruebas para confirmar los criterios de aceptación. El paso final es revisar los criterios de aceptación con las partes interesadas. La clave es que las pruebas son vitales a lo largo de cada sprint y durante todo el proyecto, no solo en etapas específicas.