Intro
En el desarrollo de software ágil, las historias de usuario desempeñan un papel fundamental para comprender las necesidades de los usuarios y garantizar que el producto final entregue valor.
Desde nuestra perspectiva como testers, y a partir de la experiencia que hayamos adquirido en testing y en ciertos negocios, facilitan nuestra participación en el proyecto en el que nos encontremos pudiendo identificar detalles que falten y/o aspectos no funcionales que a simple vista no se aprecian, formulando preguntas abiertas y cerradas al Product Owner llegando de esa forma a confirmar los criterios de aceptación o hasta incluso a provocar que sean revisados para mejorarlos. En este sentido, la situación planteada aquí no es ni más ni menos la creación y/o mejoramiento colaborativo de una historia de usuario.
Recordar: la calidad del producto se persigue entre todos, y que el equipo de desarrollo está conformado por nosotros y los desarrolladores.
Las historias de usuario son oraciones bien estructuradas y comprensibles, escritas en un lenguaje coloquial (o sea habitual, de nuestro día a día) que sirven para registrar las necesidades específicas de los usuarios de manera ordenada y concisa. Son una herramienta clave tanto para los clientes como para los desarrolladores y testers, ya que permiten comunicar y comprender las necesidades del software de manera efectiva, desde la perspectiva del usuario.
Recordar: una historia de usuario no es un requerimiento.
En el contexto del Agile Testing, las historias de usuario se convierten en requisitos funcionales que provienen directamente del cliente. Al escuchar las necesidades del cliente y convertirlas en historias de usuario, se establece una base sólida para la comunicación y la validación.
Se puede validar una historia de usuario de manera colaborativa junto con el equipo scrum, aplicando la técnica INVEST, comprobando entre todos si la historia de usuario es: independiente, negociable, valiosa, estimable, pequeña y tiene la capacidad de ser probada. En caso de que con alguna de las características mencionadas nos quedemos pensando mucho tiempo pensando y debatiendo, es porque hay un punto a mejorar, ponernos a pensar en resolver el asunto, siempre en conjunto y llegando a un acuerdo. De esta forma habremos logrado alcanzar una historia de usuario lo suficientemente buena que no genere ningún impedimento a la hora de la planificación de la iteración donde se dan muchas veces que el equipo de desarrollo no termina de entender su alcance (de qué va) y hasta le resulta demasiado vaga y/o ambigüa y por ende terminan por recharzarla y consecuentemente obligan al Product Owner a que deba mejorarla.
Recordar: es muy importante trabajar de manera colaborativa con todo el equipo scrum.
¿De qué forma nosotros -los testers- aportamos valor durante una sprint planning en nuestro squad/tribu?
- pudiendo identificar riesgos que presente la historia de usuario y que nos lleve a pensar en tener que definir criterios de aceptación alineados a los mismos para después diseñar casos de prueba basados en riesgos;
- determinando el grado de testeabilidad que tiene la historia de usuario ya que de no poder visualizar su capacidad de prueba debemos levantar la mano para invitar a que todos hagamos un doble click de lo contrario no llegaremos a cumplir con los criterios de aceptación que se hayan definido;
- diseñando pruebas de aceptación tan cercanas a la descripción que haya hecho el Product Owner de la necesidad del usuario final;
- descomponiendo a la historia de usuario en tantas tareas como hicieran falta a fin de ir acompañando el desarrollo del incremento;
- estimando el esfuerzo del testing (y no me refiero únicamente al esfuerzo de prueba como puedo leer en muchos artículos) distribuido entre todas las tareas definidas y que esa estimación acompañe a la del equipo de desarrollo sobre la base de puntos de historia aplicando poker planning;
- reconociendo no sólo los aspectos funcionales de la historia de usuario sino además los aspectos no funcionales que hacen al todo y que muchas veces no se toman en cuenta hasta que nos llega el aviso de un bug en producción y debemos «correr» para entender de qué se trata, intentar reproducirlo, ubicar la causa raíz, coregir el código y todo lo que lo rodee, analizar el respectivo regresivo que se deberá ejecutar, preparar toda la data y ambientes necesarios, efectuar la correspondiente prueba y dejar evidencia del resultado obtenido versus el resultado esperado para llevarlo la corrección a producción.
- reconociendo casos de pruebas candidatos a ser automatizados porque cumplen con las condiciones para ello. En cuanto al tema automatización hay mucho para profundizar y dá para próximos artículos que estaré publicando. Ahora bien, en esta instancia (sprint planing) y con conocimiento en automatización, no sólo podremos estar estimando testing manual, sino además estimando esfuerzo para automatizar:
- casos de prueba
- regresiones
- tratamiento de datos
- otros
Recordar: Jeff Sutherland, creador de Scrum, destaca que las historias de usuario brindan una oportunidad valiosa para el diálogo y la interacción entre el cliente y el equipo de desarrollo.
¿Qué es eso de la relación entre las Historias de usuario y Gherkin?
El uso de Gherkin para escribir historias de usuario bajo Behavior-Driven Development (BDD) ofrece varios beneficios significativos para el Product Owner en un proyecto ágil. Gherkin es un lenguaje que ayuda a definir el comportamiento esperado del software a través de escenarios escritos en un formato estructurado y simple. Te comparto algunos de los beneficios que puede experimentar el Product Owner y que en definitiva, serán beneficios para todo el equipo scrum:
Se logra alcanzar una comunicación más efectiva entre los miembros del equipo
Gherkin proporciona una sintaxis clara y concisa que es fácilmente comprensible tanto para los equipos técnicos como para los no técnicos. Al utilizar un lenguaje común y legible por los seres humanos (Nota al lector: resalto los términos «seres humanos» ya que al haber iniciado una formación en inteligencia artificial dictada desde la UBA IALAB estoy adquiriendo conocimientos que me están haciendo replantear muchos aspectos relacionados con el desarrollo de software), se mejora la comunicación entre el product owner y el equipo de desarrollo. El product owner puede expresar claramente los requisitos y las expectativas del software utilizando escenarios que reflejen los comportamientos deseados.
Promueve la colaboración entre el Product Owner y el Equipo de desarrollo
Gherkin promueve la colaboración activa entre el Product Owner y el Equipo de desarrollo (Nota al lector: el equipo de desarrollo genéricamente hablando está compuesto por el testers y el desarrollador). Al escribir las historias de usuario en un formato estructurado utilizando Gherkin, tanto el Product Owner como el equipo técnico pueden revisar y discutir conjuntamente los detalles y las reglas del negocio y de esa forma lograr interpretar la descripción que se ha hecho de la necesidad del usuario final y llevarla a requisitos técnicos y luego a tareas para el desarrollador y para el tester. Esto ayuda a evitar malentendidos y garantiza que todos tengan una comprensión clara de los requisitos y las expectativas, por ende a lograr definir criterios de aceptación correctos.
Facilita la validación temprana de las historias de usuario
El formato de Gherkin permite que las historias de usuario se validen tempranamente antes de su implementación. El Product Owner puede revisar las historias escritas en Gherkin y verificar si reflejan correctamente los comportamientos deseados alineados a la descripción de la necesidad que tiene el usuario final. Esto ayuda a identificar posibles errores o inconsistencias en las historias de usuario antes de que se realice cualquier desarrollo adicional, lo que ahorra tiempo y esfuerzo en correcciones posteriores y de nuevo, logramos alcanzar una correcta definición entre todos de los criterios de aceptación.
Promueve la automatización de pruebas
Gherkin se puede utilizar como base para la automatización de pruebas funcionales. Al escribir las historias de usuario en un formato estructurado y legible, el equipo de desarrollo puede utilizar herramientas de automatización de pruebas como Cucumber para traducir automáticamente los escenarios de Gherkin en casos de prueba ejecutables. Esto permite una mayor eficiencia en la ejecución de pruebas y facilita la integración continua. De esta forma incluso logramos además más involucramiento del Product Owner en el desarrollo del producto ya que utilizando Cucumber podemos estar integrándolo con Selenium WebDriver y todos los scripts que automaticemos los podemos ejecutar luego a través de Jenkins y programar por ende, posteriores jobs que hasta incluso los puede ejecutar el Product Owner y así tener como resultado de la ejecución de dicho job un reporte por medio de Allure que le muestre el estado de la ejecución de los casos de prueba automatizados.
Fomenta la claridad y el enfoque en el valor del negocio
Gherkin enfatiza el comportamiento del software desde la perspectiva del usuario final y del negocio. Al utilizar este enfoque, el Product Owner puede centrarse en la entrega de valor a los usuarios finales, asegurándose de que las historias de usuario se enfoquen en los resultados deseados y en las necesidades del usuario. Esto ayuda a evitar la incorporación de funcionalidades innecesarias y garantiza que el software entregado cumpla con las expectativas del cliente.
Recordar: BDD brinda beneficios valiosos al Product Owner y al Equipo de desarrollo, ayudando a mejorar la comunicación, fomenta la colaboración, facilita la validación temprana, permite la automatización de pruebas y mantiene un enfoque claro en el valor del negocio. Al utilizar Gherkin, el Product Owner puede garantizar que las historias de usuario sean comprensibles y verificables.
Recordar: El objetivo de aplicar en las historias de usuario (Gherkin/BDD) es transmitir el contexto general y específico a todo el equipo de desarrollo. Esto promueve una comprensión compartida de las necesidades y objetivos del proyecto. Una vez que el equipo ha comprendido el contexto de la historia de usuario, se pueden incluir requisitos técnicos que definan las condiciones específicas que el software debe cumplir. Estos requisitos técnicos se generan a partir de los requisitos del cliente, lo que garantiza que el producto final cumpla con las expectativas y necesidades del usuario.
Recuerda que este mismo contenido está publicado en LinkedIn donde podrás participar en el debate que se genere con tu comentario y así conocer otras experiencias.
Espero que te haya ayudado este contenido.
Seguime también por LinkedIn.
