Historias de Usuario para testers

La semana pasada Arcadio Abad y Verónica Gamarra de Abstracta dieron un webinar titulado “Historias de Usuario contadas por testers”. Básicamente estuvieron hablando de User Stories, ese formato para especificar requerimientos tan usado en equipos ágiles. Lo contaron desde un punto de vista útil para testers, viendo desde qué es una historia de usuario, buenas prácticas, qué tener en cuenta para trabajar con ellas como testers.

En este post te quiero compartir la charla y además, las preguntas y respuestas que quedaron pendientes, Arcadio y Verónica las respondieron y las compartimos aquí mismo. Realmente te recomiendo ver la charla en especial si trabajas en un equipo ágil, seas tester o no (de paso te dejo este link a un artículo donde discutimos si puede haber testers en scrum).

Charla “Historias de Usuario contadas por testers

Otra recomendación es que te suscribas al canal de youtube de Abstracta ya que estamos publicando charlas, webinars y videos que te pueden ayudar a seguir aprendiendo sobre testing y estar informado de las mejores prácticas, aprendiendo de experiencias de referentes como Vero y Arcadio.

Preguntas y respuestas

Acá te dejamos las respuestas a las preguntas que quedaron pendientes:

Historias de usuario y criterios de aceptación

¿Tienen tips para escribir los criterios de aceptación o los MVP?

Esos son dos conceptos diferentes. El MVP se ve en el conjunto de historias de usuario. Esto es un ejercicio más enfocado al dueño del producto y los interesados del negocio. Existen técnicas como Story Mapping, hay mucho material en la web y quizá podemos hacer otro webinar al respecto más adelante.
Para los criterios de aceptación espero que estas guías como INVEST y los check list que mostramos en esta presentación te sean de utilidad.

¿Dónde se documentan los criterios de aceptación? Si uso confluence para las user stories, ¿las puedo colocar allí?

Los criterios de aceptación son parte de historia de usuario, tiene que quedar todo junto en la “misma tarjeta”. Diferentes herramientas tienen diferentes nombres, pero todo gira alrededor del mismo concepto ya sea que uses Trello, Clubhouse, Youtrack, o Jira.

La tarjeta debería tener al menos:

• como…, quiero…, para….
• Título
• Criterios de aceptación, conteniendo la lista de criterios.

El “para” lo termino poniendo yo a veces como UX

Sí, el para puede ser confuso de bajar a tierra, pero lo importante es que pueda responder a estas preguntas

• ¿Para qué lo estamos construyendo?
• ¿Cuál es el valor para el cliente?

¿Qué hacer cuando en los criterios de aceptación se genera un proceso adicional? Por ejemplo: mostrar en la lista de espera de la bandeja del médico. Eso implicaría que va a el médico, cómo lo va a ver, qué puede hacer el médico con ello? pueden ser otras historias de usuarios

¡Exacto! habla de poder entender todas las puntas que se desprende de esto, entender qué es lo mínimo que necesitamos para que todos los participantes obtengan valor. Si vemos que algo queda resonando, mejor seguir madurando la idea, si vemos que surge alguna aclaración lo agregamos.

¿Los criterios de aceptación deben tener una estructura específica para redactarlos? ¿Los puedo redactar tal cual los pienso? ¿Pueden ser también técnicos o estos se manejan de otra manera?

Exacto, en mi experiencia apuntó más a lenguaje natural. De este modo si el equipo es multidisciplinario todos llegamos a ese entendimiento común. Pero siempre siguiendo las pautas que les compartimos en la charla. Existen otras opciones más técnicas que luego pueden ser utilizadas en pruebas automatizadas como Gherkin.

En tu experiencia, ¿cuánta documentación y qué formas de documentar son las sugeridas? Hay expositores que dicen que en video es ok y luego se tienen horas y horas de pietaje.

Depende de la metodología del proyecto. He participado de proyectos donde las buenas historias de usuario eran clave. Muchas veces estos adjuntaban diseños de UI, diseño de API o referencias a otras historias, lo que sirve mucho.

Testing de historias de usuario

Hola, desde su experiencia, ¿han tenido que testear historias de usuario sin criterios de aceptación? Si ha sido ese el caso ¿qué estrategias se trazaron para poder llevar a cabo el testing de la Historia de usuario en sí?

Una historia de usuario debería tener criterios de aceptación para poder definir las expectativas de qué es lo que se espera. Además, son una guía que ayuda a determinar si una historia de usuario está terminada. Sin criterios de aceptación se pueden definir infinitas soluciones, podría nunca poder terminar el desarrollo ya que continuamente podríamos agregar nuevas cosas. Te cambio la pregunta, ¿una “historia de usuario” sin criterios de aceptación podemos aplicarle INVEST?

Hola! buena presentación ¿estos dos primeros puntos del ejemplo de los criterios de aceptación, no serían una especie de precondiciones de la historia, por ende de las pruebas?

Si y no, serían precondiciones de tus escenarios para las pruebas. De allí podría explorar pruebas como ¿qué pasa si el paciente no está logueado? y ¿qué pasa si esta logueado?
Quizá sirve verlo así: “Dada esta precondición, cuando surge un evento X, entonces obtengo el beneficio Y’. Aquí es importante recordar, los criterios de aceptación no son casos de pruebas, son escenarios donde luego en nuestro rol de tester vamos a basar nuestras pruebas.

¿Cuál consideran como documentación mínima e indispensable para que el tester puede realizar su trabajo?

Más que documentación mínima indispensable pienso en que realmente tenga entendido el valor de la historia y sus criterios. Empezar por historias de usuario escritas de manera que se genere ese común entendimiento es clave, puede ser un buen comienzo. Además de buena comunicación con el equipo.

¡Hola para todos! Si el criterio de aceptación no se cumple, ¿cuál es el tipo de respuesta que devuelven al desarrollador? ¿Sobre la HU o directamente sobre este criterio que no cumple?

El común acuerdo con el equipo es vital, esto me ha variado dependiendo el equipo. En la mayoría de los casos dejo la historia bloqueada en testing y genero un bug asociado al criterio haciendo referencia a la historia. Una vez corregido el bug, y todos sus criterios de aceptación validados, la historia quedó finalizada para testing. En otras oportunidades si el criterio no se cumple y no puedo continuar en toda la historia, devuelvo la historia entera.

Pruebas Exploratorias o Tradicionales

¿Esto quiere decir que se está mucho más enfocado a pruebas exploratorias en lugar del enfoque tradicional donde se describen una gran cantidad de casos de pruebas?

No necesariamente, los criterios de aceptación son escenarios en los cuales nos vamos a basar en el diseño de nuestros casos de prueba. Por ejemplo, si al hacer el diseño de pruebas entendemos que facilita crear una máquina de estados para que luego nos guíe en nuestras sesiones exploratorias o casos de pruebas para cada transición, ¡bienvenido sea!. La elección de qué estrategia seguir está afectada de otras variables, como por ejemplo el tiempo, si necesitamos realizar un entregable de métricas de prueba al final, la experiencia de los testers, etc.

Apoyarnos en el diseño de UI

Muy interesante la conferencia, tengo una consulta, ¿será correcto que la historia de usuario debería apoyarse con las pantalla diseñadas por el UI o diseñador? ya que una HU no tiene el detalle de todos los elementos.

¡Qué pregunta interesante! Todo material generado alrededor de la historia aporta. Lo importante es generar el entendimiento común de qué se va a desarrollar. Si los criterios de aceptación complementan la información que da el diseño, ¡excelente! Si duplica información, ahí evaluaría ese nivel de granularidad.

Estimación de historias de usuario

Para estimar una historia de usuario ¿recomiendan estimar usando horas o puntos de historia?

Uh! Estimaciones, ¡es todo un tema! En mi experiencia me gustan más los puntos. Da un común entendimiento al equipo del tamaño de la historia.

Es cierto que es otro aspecto que trae consigo el mundo ágil, en metodologías tradicionales se estima en tiempo, pensando cuánto duraría cada etapa del desarrollo y eso forma parte de un contrato. Es más natural entonces dividir nuestras tareas en tiempo para cumplir con lo establecido. En metodologías ágiles también estimamos cuánto puede durar la implementación del producto, pero al tener ciclos cortos, al decidir qué historias o tareas vamos a asumir para el siguiente ciclo, se suele hacer en función de puntos porque lo importante es saber, como equipo, qué esfuerzo necesitamos emplear para darle solución a cada historia. El tiempo lo marca el largo del ciclo y el equipo aprende a conocerse en cuanto a cuál es el número de puntos que puede asumir en un ciclo. No se trata de la suma de puntos que cree tomará el desarrollo más los puntos que cree el testing, sino en ponderar en equipo el tamaño de esa historia y el esfuerzo total que comprendería según la escala de valores definida y su propia experiencia con otras historias.

Historias de usuario “técnicas”

¿Existen historias de usuario técnicas? como por ejemplo tareas de ejecución automáticas.

No estamos seguros si entendemos bien la pregunta. Si te refieres a si se escribe en formato de Historias de Usuario tareas meramente técnicas, como por ejemplo configurar un ambiente o capacitarse en un tema específico, la respuesta es que no es necesario. Si bien son tareas importantes para el desarrollo, no se ven como un valor tangible del producto al usuario final. Así que no cumpliríamos con eso de escribirlo siempre desde la perspectiva del usuario. En ese caso recomendamos escribirlo como una tarea sencilla describiendo el qué se necesita hacer.

Roles involucrados

¿Qué roles son los involucrados a la hora de definir los criterios de aceptación? Intuyo que un representante de cada área

El responsable es el dueño del producto (PO, Product Owner), pero para hacer la tarea pueden participar quienes se vea necesario. Sobre la misma historia se puede iterar muchas veces, los criterios de aceptación invitan a la conversación. Una primera iteración puede darse a nivel negocio y luego en etapa de refinamiento, bienvenidos todos los aportes. Ojo, el equipo podría darse cuenta de nuevos criterios de aceptación en el medio del desarrollo o testing. Aquí será cuestión de negociar con el equipo esos casos, si se incorpora allí o se crea algo para priorizar más adelante.

Bibliografía y materiales

Un saludo al equipo. Más que una pregunta lo que quisiera saber es ¿qué bibliografía recomendarían si se quiere profundizar en el tema? Junto otra pregunta: ¿alguna guía o libro o ejercicios para mejorar la calidad de nuestras historias de usuario?

Afortunadamente hay mucho en internet. Un libro puede ser User Stories Applied for Agile Software Development de Mike Cohn y Kent Beck

Cerrando

Si vieran nuestras US les daría un infarto jajaja

¡Esperemos que después de esta charla salgan algunas oportunidades de mejoras en sus equipos! 😀

Muchas gracias, estuvo espectacular la charla!!!!

¡Gracias a ustedes por sumarse! 😀