Cómo Documentar Sus Diseños con Comportamiento Impulsado por Historias de Usuario

Un problema común al documentar requisitos es tomar una postura desde la perspectiva de sistema para describir lo que se necesita, olvidando que es el usuario que estará en el centro de las interacciones. Historias de usuario, presentados por el Agile, abordar este problema haciendo que el usuario del centro de la exigencia y Desarrollo Impulsado por Comportamiento (BDD) toma las cosas un paso más proporcionando un marco donde el comportamiento del usuario es lo que impulsa el desarrollo.

Técnicas de BDD para crear historias de usuario facilita la documentación requisitos escribir y leer. También, proporciona herramientas adicionales para comunicarse el usuario previsto experimentan de diseño, diseñadores, desarrolladores e ingenieros QA pueden utilizar fast track e incluso automatizar parte de su trabajo. En este artículo explorar este enfoque y muestran cómo se puede utilizar para documentar sus propios diseños, a partir de pequeñas historias a la organización de esas historias para comunicar las características completamente funcionales.

Requisitos de Interfaz de Usuario vs. Requisitos UX

Hay una distinción importante a hacer entre requisitos de interfaz de usuario (también conocido como especificaciones) y UX. Por un lado, requisitos de interfaz de usuario son documentos técnicos que detalles acerca de la interfaz de usuario, incluyendo tipos de fuentes, colores, dimensiones y disposición de elementos de la lista. Un buen ejemplo de este tipo de documentación son guías de estilo de vida.

Requisitos de UX, por el contrario, describen lo que la experiencia debe ser para un usuario específico, dado que este usuario está en un escenario específico haciendo una acción específica. Una historia de usuario puede capturar un requisito de UX de manera muy sucinta. Por ejemplo:

• Como un... usuario editor,
• Quiero.. ser capaces de revisar los artículos antes de su publicación,
• Para.. Puedo retroalimentar y asegurar calidad de manera oportuna.

Esta historia indica primero el papel del usuario, lo que quiere lograr, este usuario y luego explica la razón detrás de él. Esto es excelente ya que aporta conocimiento a desarrolladores y testers de cuál es el objetivo final: que es suficiente un usuario necesita. Tenga en cuenta que las palabras en negrita son la plantilla para escribir la historia. Siempre hay un usuario, que quiere hacer algo, por lo que puede lograr un objetivo específico. Puedes seguir estos consejos para escribir historias de usuario buena.

Con esta historia en mente, el equipo de diseño puede decidir que una acción de "aprobación" es necesario para lograr el objetivo del usuario. Para proporcionar detalles específicos sobre cómo esto realmente funciona, puede utilizar Gherkin syntax, que es una herramienta BBD para escritura legible requerimientos del negocio. Pepinillo sintaxis es similar a las historias de usuario ágil ya que proporciona una forma de escribir requisitos que también pueden ser utilizados como una plantilla. La ventaja es que puede entrar en más detalles, proporcionando situaciones y acciones que el usuario puede emprender sin entrar en cómo debe hacerse la aplicación. Echemos una ojeada cercano.

Escribir Historias de Usuario Mediante Gherkin syntax

Los fundamentos de una historia mediante Gherkin syntax pueden resumirse en estas partes:

• Una función
• Un escenario
• Una condición previa
• Una acción
• Un resultado

Una característica es un lugar para describir el valor general de la empresa de la aplicación. También puede utilizarse para proporcionar información adicional, como reglas de negocio, o cualquier otra cosa que la característica más fácil de entender (como enlaces a prototipos o requisitos de interfaz de usuario).

Un escenario describe las circunstancias concretas en que el usuario es. Desde una perspectiva de diseño de usuario, escenarios permiten comunicar las múltiples variables de un diseño, y cómo la interfaz de usuario debe manejarlos, según el usuario.

Una condición previa ayuda a construir el escenario y elimina cualquier ambigüedad. Por ejemplo, en un escenario que describe un usuario por primera vez acceder a una pantalla particular, puede aclarar la condición previa que el usuario está logueado.

Una acción indica exactamente lo que el usuario hace en la interfaz, y es típicamente «desencadenante», como hacer clic en un botón, enviar un formulario, o desplazarse a otro lugar.

Un resultado es la consecuencia de la acción y siempre debe ser algo que se puede probar.

Con estas partes en mente, vamos a escribir una historia de usuario para la función que hemos descrito anteriormente:

• Como un... usuario editor,
• Quiero.. ser capaces de revisar los artículos antes de su publicación,
• Para.. Puedo retroalimentar y asegurar calidad de manera oportuna.

Mediante Gherkin syntax esta historia tendría este aspecto:

Se puede ver cómo la historia inicial se convierte en un flujo más detallado que el usuario pueda seguir y por lo tanto, que puede ser probado. También, tenga en cuenta que las palabras en negrita son las palabras clave que utiliza software como cucumber para automatizar la ejecución de pruebas. Explicaré más sobre esto más adelante, pero por ahora, quiero señalar que estas palabras clave son muy útiles, así como para escribir la historia porque ayudan a distinguir las diferentes partes de la historia.

Otra cosa a señalar es que aunque la historia proporciona más detalles sobre el flujo de usuarios, la interfaz no es descrita. La razón de esto es que describe la interfaz de usuario pueda girar rápidamente hacia la historia en los requisitos de interfaz de usuario, que presenta un gran problema ya que pueden llegar bastante rápidamente anticuados. Por ejemplo, si la historia describe cómo la alerta de éxito parece y lo que debe decir el mensaje específico, entonces la historia puede obtener fuera de sincronización si esto cambia, creando el potencial de la falta de pruebas.

Así que el truco es proporcionar suficientes detalles, sin hacer el trabajo de las herramientas más adecuadas, como diseño de maquetas, prototipos y guías de estilo. En este sentido, se dará cuenta que la acción indica "seleccionar aprobar" vs usando "aprobar". "Selección de aprobar" no es específica en cuanto a lo que parece este control (puede ser un botón, un botón que parece un enlace o una caja que se puede hacer clic), pero supone que es accionado por un elemento de la interfaz de usuario. También indica que este elemento ha escrito en él "aprobar". Se trata de un área gris donde usted tendrá que utilizar el sentido común, como en algunos casos que tendrá que ser específico para que las acciones pueden distinguirse de los demás. Por ejemplo, si hay otra forma de aprobar un artículo en la misma página, indicando que en este escenario, el usuario tiene que "seleccionar", permite hacer la diferenciación.

La Importancia de los Escenarios

Además de la sintaxis reflexiva que proporciona pepinillo, una de las cosas que más útil está utilizando la parte de "escenarios". Los escenarios son poderos porque pueden ser utilizados para probar el diseño y asegúrese de que todas las bases cubiertas.

Diseños de cualquier tipo de inicio con el "camino feliz", lo que significa lo que sucede generalmente, cuando todo va bien en la interfaz, y cómo se aplica a la mayoría de los usuarios. En nuestro ejemplo anterior tenemos:

También, porque sabemos que los artículos tienen las fechas de publicación, también podemos afirmar: este es nuestro primer escenario porque en la mayoría de los casos los artículos que tienen que ser aprobadas deben ser listos para su publicación. Pero esto trae la pregunta: ¿Qué sucede cuando un artículo no está listo para su publicación y el editor acceda al mismo? ¿Deberían incluso ser capaces de acceder a esos artículos?

• ¿Qué pasaría si un artículo es aprobado tiene una fecha de publicación en el pasado? ¿Debe publicar inmediatamente el artículo, o si entran en una cola?
• Y yendo un paso más allá, ¿qué pasa si un editor aprueba un artículo por error? ¿Cuál es el procedimiento para deshacer esta acción? ¿Que debe obtener notificaciones?

Todas estas preguntas son parte del proceso de diseño y es muy probable que cuando saltas en los requisitos de documentación que se sabe las respuestas. La buena noticia es que usando escenarios en la documentación de la historia le ayudará a estructurarlos y en muchos casos ayudará a QA sus propios diseños, asegurándose de que hay un diseño y un flujo para cada uno de ellos.

Vamos a ver cómo nuestra historia iba a tener forma con los escenarios adicionales:

Dependiendo de la función, puede haber muchos escenarios a considerar. Es mantener corto, para que pueda describir y prueba de ellos fácilmente. También puedes agruparlos, con denominadores comunes. Por ejemplo, si unos escenarios comparten la misma condición, se puede encapsular esta en un "fondo" que puede ser utilizado por múltiples escenarios. Por ejemplo:

Organización de Historias Para Comunicar una Función

Un desafío común que surge cuando la documentación de requisitos está en decidir en qué orden hacerlo. La razón de ser que en la mayoría de los casos todo está en construcción, que hace difícil probar una interacción cuando las partes de las interacciones no están todavía incorporadas. Por ejemplo, en la simple interacción de la "aprobación" de un artículo, muchas cosas tienen que estar listos:

1. La interfaz de usuario debe ser capaces de devolver un mensaje de éxito si la aprobación es exitosa y un fracaso del mensaje en caso de un problema del sistema.
2. La interfaz de usuario debe ser capaces de artículos de "etiqueta" aprobado.
3. La interfaz de usuario debe ser capaz de mostrar el artículo según la lógica de negocio "publicado".
4. Notificaciones del sistema deben estar habilitadas, por lo que los escritores pueden obtener alertados cuando se produce la aprobación.

Un acercamiento a la documentación de requisitos para cada una de estas dependencias para registrarlas características tan diferentes que luego pueden priorizarse según su valor para el negocio.

Se puede crear una historia de "integración" para llevarlos todos juntos. Por ejemplo, una historia de usuario para el sistema de etiquetado sería asi:

En la historia de la integración, puede hacer referencia a la historia marcada, en el caso de que los detalles de ese escenario deban ser verificado otra vez o si usted simplemente quiere saber si los casos han sido ya verificadas.

Se trata de evitar la repetición de documentación que no solamente consume tiempo innecesariamente, pero también que puede llegar a ser sincronizado.

Convertir las Historias de Usuario en Casos de Prueba

Hemos visto cómo útil comportamiento impulsado por User Stories puede ser para escribir requisitos enfocados, concisa, pero también completa y descriptiva. A partir de la fase de diseño, esta herramienta puede prestar una buena cartilla para los ingenieros QA para escribir casos de prueba reales.

Además de estas grandes ventajas, comportamiento impulsado por historias de usuario se pueden convertir realmente en pruebas funcionales con la ayuda de software, como Cucumber o Lettuce. La idea básica es que una vez que las historias se escriben utilizando la sintaxis de pepinillo, puede colocarlos en un archivo .feature dentro de tu aplicación y luego ejecutarlos como pruebas para demostrar si tuvieron éxito o no. Para un detallado tutorial de cómo utilizar lechuga para una implementación de Python consulte el tutorial de David Sale:

• 
  Python
  Desarrollo Orientado a Comportamiento en Python
  David Sale

Conclusión

Escribir historias de usuario utilizando los principios de BDD puede servir para comunicarse en los requisitos del negocio y diseño de detalle, con un enfoque centrado en el usuario, utilizando un lenguaje que es humano legible pero extensible para la interpretación del software. Además puede ser utilizado para probar:

• sus propios diseños como documentan requisitos
• la aplicación manualmente, una vez convertido en casos de prueba por un ingeniero de control de calidad
• la aplicación automáticamente, cuando se convirtió en pruebas funcionales utilizando el software de BDD.

Esto significa más capas para errores pasar, prevención de deficiencias en el diseño y más blindaje a su solicitud de fallos de error.