Antes de comenzar a trabajar en una historia de usuario, es muy importante determinar sus criterios de aceptación. Esto se puede hacer cuando detalla el trabajo atrasado o planifica el próximo sprint. Algunos equipos para esto celebran reuniones especiales llamadas 3 Amigo (más sobre ellos en el último
artículo ), manifestaciones, patadas de acuerdo a las especificaciones o reuniones-estudios.
No lo llames, para la mayoría de los equipos esto es difícil. La principal dificultad es que tales reuniones no están estructuradas y sus resultados son incomprensibles. Son lentos y simplemente aburridos. Como resultado, las sesiones se vuelven irregulares o completamente abandonadas.
Pero hay una manera fácil de hacer que tales reuniones sean cortas y muy productivas. Y este método se llama Ejemplo de mapeo o mapeo de casos de prueba.
Como funciona
Los casos de prueba específicos (ejemplos) son una excelente manera de explorar un área temática. Pueden ser una buena base para sus pruebas de aceptación. Cuando hablamos de casos de prueba, surgen otros aspectos que también deben mencionarse.
- Las reglas que resumen diferentes casos o viceversa limitan la aplicabilidad del caso de prueba.
- Preguntas sobre escenarios en los que nadie sabe qué es realmente cierto. O hipótesis que presentamos para avanzar de alguna manera en el desarrollo de requisitos.
- Nueva historia de usuario que se reveló durante la discusión.
Ejemplo de mapeo utiliza un conjunto de tarjetas en cuatro colores diferentes y bolígrafos para registrar nueva información mientras habla. Durante la reunión, la información se registra en las tarjetas y se coloca en el tablero, como en la imagen de arriba.
Primero, en la etiqueta amarilla, debe escribir
la historia y colocarla en la parte superior del pizarrón. A continuación, en las etiquetas azules, indique cada uno de los
criterios o reglas de aceptación que hemos desarrollado anteriormente. Colocamos tarjetas azules debajo del amarillo.
Cada regla generalmente se puede ilustrar con varios
casos de prueba . Cada caso de prueba tiene su propia etiqueta verde, que se coloca bajo la regla correspondiente.
Mientras estamos compilando un mapa y discutiendo casos, pueden surgir
preguntas que ninguno de los presentes puede responder. Los fijamos en calcomanías rojas y continuamos la discusión.
La reunión continúa hasta que todos estén convencidos de que la historia se comprende por completo o que el tiempo asignado termina.
Retroalimentación instantánea
En el proceso de dicha conversación, se construye fácil y rápidamente una representación visual de la comprensión actual de la historia.
- Un tablero cubierto con pegatinas rojas (preguntas) dice que queda mucho por ver.
- Un tablero cubierto con pegatinas azules (reglas) indica que la historia es grande y compleja. Quizás necesites descomponerlo. Tal vez necesite tomar otra pegatina amarilla (historias) y poner parte de las historias en la cartera.
- Si una regla tiene demasiados casos de prueba, entonces tal vez sea demasiado complicada y necesite resaltar varias reglas que pueden describirse con más detalle por separado.
Es posible que algunas reglas sean tan obvias que no necesiten casos de prueba. Por ejemplo, si todos entienden la regla de la misma manera, entonces no necesita perder tiempo y torturar un número fijo de casos de prueba.
Piensa por tiempo limitado
Un grupo de varios amigos debe hacer una historia decente, decente en
unos 25 minutos .
Si no puede cumplir con el tiempo asignado, entonces hay varias opciones posibles:
- Todavía está aprendiendo a usar este método (esto es normal);
- su historia es demasiado grande (esto definitivamente ya no es bueno);
- Hay demasiada incertidumbre en su historia.
Que se puede hacer Intente dividir la historia en varias, o déle al dueño de la tarea la tarea, para que más tarde regresen juntos a esta historia en la siguiente sesión mediante un mapeo de ejemplo, pero con respuestas.
Matt Wynne de Cucumber invita a los participantes de la reunión a votar en 25 minutos si la historia está lista para ser presentada para su desarrollo. Incluso si algunos problemas permanecen sin resolver, el equipo puede decidir que no hay mucha incertidumbre y que puede desarrollarse aún más en el camino.
Beneficio
El mapeo de ejemplo ayuda a cambiar la escala y enfocarse en las piezas más pequeñas del comportamiento de la historia. Al compilar un mapa, puede seleccionar las reglas, encontrar la esencia del comportamiento deseado y posponer el resto para más adelante. Debido a la minuciosidad de la investigación, el mapeo de ejemplo actúa como un filtro, evitando que grandes historias audaces entren en el sprint y luego den sorpresas desagradables en el último minuto. Además, este enfoque ahorra tiempo y ayuda a mantener la participación de las personas interesadas en el proceso.
A algunos les parece que 3 amigos deberían escribir pruebas de aceptación
durante esta reunión (por ejemplo, guiones para Pepino). En principio, en algunos casos esto puede tener sentido, pero más a menudo este enfoque solo distraerá el verdadero propósito de la conversación.
Está claro de dónde proviene esa opinión: el objetivo obvio es tomar una historia de usuario, que ya tiene algunos criterios de aceptación predefinidos, y encontrar casos de prueba que puedan convertirse en pruebas de aceptación.
El objetivo real es lograr una
comprensión común de lo que se necesita para crear una historia. Puede avanzar rápidamente hacia este objetivo sin alta tecnología.
Simplifica la grabación
Por lo tanto, en lugar de usar los scripts formales de Gherkin, solo intente compilar rápidamente una lista de
casos de
prueba usando la convención de nomenclatura.
Por ejemplo:
- donde el cliente ha olvidado su recibo;
- donde se compró el producto hace 15 días.
Cuando la incertidumbre se oculta detrás de este nombre de caso, instintivamente desea detalles y detalles. Pero incluso entonces, no es necesario adherirse a la estructura rígida
Dado cuándo entonces.Si el resultado ("entonces") no está claro, el ejemplo no funcionará, pero la pregunta sí.
Conocido desconocido
Si la conversación comienza a circular, entonces no hay suficiente información. Quizás la reunión no tiene la persona adecuada, o necesita investigar un poco o usar
Spike .
En lugar de escuchar la
opinión de cada participante sobre cuál debería ser el resultado desde su punto de vista, simplemente escriba la pregunta en la tarjeta roja y continúe. Entonces lo
desconocido se convertirá en un
desconocido conocido . Este es un gran progreso.
Por experiencia, incluso este aspecto de los ejemplos de mapeo puede convertir 3 reuniones de Amigo de aburridas a rápidas y productivas.
¿Quién debería participar?
El mínimo es su amigo 3: desarrollador, probador y propietario del producto (analista comercial). Esto es solo un mínimo. Además, puede invitar a alguien de la operación, un especialista en UX o cualquier otra persona relacionada con la historia en discusión. Cualquier persona que pueda ayudar a encontrar nuevas preguntas o convertir las preguntas en respuestas durante una conversación será útil.
Mientras domina esta técnica, es conveniente encontrar a alguien para el rol de facilitador. Su tarea formal será asegurarse de que todo lo dicho se grabe de inmediato en calcomanías. Los casos de prueba y las preguntas se discuten rápidamente durante la sesión, y se necesita disciplina para escribirlos en calcomanías de manera oportuna para ver lo que se dice.
Entonces, ¿cuándo escribir sobre pepinillo?
No se equivoque, usar Gherkin es de gran valor, especialmente en los primeros días del proyecto, cuando desarrolla un lenguaje común. Es vital que los escenarios se expresen para que todos en el equipo los crean.
Pero describir los casos de prueba de esta manera requiere una forma diferente de pensar. Es necesario no solo decidir qué casos entran en el área en cuestión y establecer reglas generales para ellos.
Para un equipo que trabaja con un lenguaje de dominio bastante maduro, es más rentable para el propietario del producto gastar su tiempo y energía en el mapeo, y dejar la tarea de escribir Gherkin a otros dos amigos. Después de desarrollar la especificación Gherkin, el propietario del producto podrá dar su opinión. Haciéndose la pregunta: "¿Escribiría así?" Puede verificar cuán efectivo fue el mapeo en términos de transferir el conocimiento del producto a su amigo.
¿Con qué frecuencia haces esto?
En la práctica, se recomienda reunirse
cada dos días . Simplemente seleccione una historia de usuario y preste 25 minutos de atención, y luego vuelva a trabajar. Si intentas hacer más, solo desperdicia tu energía.
¡Pero tengo un equipo distribuido!
Para esto, ya hemos encontrado soluciones, por ejemplo, listas de calcomanías en Google Keep o tableros en línea con calcomanías de colores. Puedes usar el mapa mental. Lo principal es
que debe poder trabajar de manera simple y rápida
para poder concentrarse en la conversación .
Algunos consejos finales
Es importante distinguir claramente entre
reglas y casos de prueba antes de usar el mapeo de ejemplo. Hay un
ejercicio divertido para esto.
Recuerde, el objetivo final de dicha reunión es
descubrir lo que aún no sabe . No hay preguntas estúpidas, todas ayudan a investigar realmente el problema.
Con esta técnica, descubrirá que las reglas crean líneas naturales de desarrollo para su historia. Trate de relacionarse con calma con las preguntas, sepárelas y póngalas a un lado. Entonces puedes concentrarte en resolver el problema principal. Puede complicar y llevar al ideal más tarde.
Hablaremos sobre la práctica de 3 Amigo para resolver los requisitos y construir tarjetas de casos de prueba en la conferencia QualityConf . Además, la lista de informes aceptados contiene otros enfoques prácticos extremadamente interesantes para crear un producto de TI de alta calidad. La conferencia QualityConf se llevará a cabo por primera vez como parte del festival RIT ++ los días 27 y 28 de mayo, tenga tiempo para unirse.