Share
Un problema común cuando se documenta los requisitos es tomar una posición desde la perspectiva del sistema para describir lo que se necesita, olvidando que es el usuario el que estará en el centro de las interacciones. Las historias de usuario, introducidas por Agile, abordan este problema haciendo que el usuario sea el centro del requisito, y Behavior Driven Development (BDD) lleva las cosas un paso más allá al proporcionar un marco donde el comportamiento del usuario es lo que impulsa el desarrollo..
El uso de técnicas BDD para crear historias de usuario hace que la documentación de requisitos sea más fácil de escribir y leer. Además, proporciona herramientas adicionales para comunicar la experiencia de usuario prevista de un diseño, que los diseñadores, desarrolladores e ingenieros de control de calidad pueden utilizar para acelerar e incluso automatizar parte de su trabajo. En este artículo, exploraré este enfoque y mostraré cómo puede usarlo para documentar sus propios diseños, comenzando desde historias pequeñas hasta organizar esas historias para comunicar características totalmente funcionales..
Existe una distinción importante entre los requisitos de UI (también conocidos como especificaciones) y los requisitos de UX. Por un lado, los requisitos de UI son documentos técnicos que enumeran detalles específicos sobre la interfaz de usuario, incluidos los tipos de fuente, colores, dimensiones y diseño de los elementos. Un buen ejemplo de este tipo de documentación son las guías de estilo de vida..
Los requisitos de UX, por otro lado, describen cómo debería ser la experiencia para un específico usuario, dado que este usuario se encuentra en un escenario específico realizando una acción específica. Una historia de usuario puede capturar un requerimiento de UX de una manera muy sucinta. Por ejemplo:
Esta historia indica primero el rol del usuario, lo que este desea lograr y luego explica la razón detrás de él. Esto es excelente, ya que proporciona información a los desarrolladores y evaluadores sobre cuál es el objetivo final: satisfacer las necesidades de los usuarios. Tenga en cuenta que las palabras en negrita son la plantilla utilizada para escribir la historia. Siempre hay un usuario que quiere hacer algo para poder lograr un objetivo específico. Puedes seguir estos consejos para escribir buenas historias de usuario..
Con esta historia en mente, el equipo de diseño puede decidir que se necesita una acción de "aprobación" para lograr el objetivo del usuario. Luego, para proporcionar información específica sobre cómo funcionará esto, puede utilizar la sintaxis de Gherkin, que es una herramienta de BBD para escribir requisitos legibles para el negocio. La sintaxis de Gherkin es similar a las historias de usuarios ágiles, ya que proporciona una forma de escribir requisitos que también se pueden usar como plantilla. La ventaja es que puede obtener más detalles, brindando escenarios y acciones que el usuario tomaría sin entrar en cómo se debe hacer la implementación. Echémosle un vistazo de cerca..
Los conceptos básicos de una historia que utiliza la sintaxis de Gherkin se pueden resumir en estas partes:
Una característica es un lugar para describir el valor comercial general de la implementación. También se puede usar para proporcionar información adicional, como reglas de negocios, o cualquier cosa que facilite la comprensión de la función (como enlaces a prototipos o requisitos de UI).
Un escenario Describe las circunstancias específicas en las que se encuentra el usuario. Desde la perspectiva del diseño del usuario, los escenarios permiten comunicar las múltiples variables de un diseño y cómo la UI debe manejarlas, según el usuario..
Una precondición Ayuda a construir el escenario y elimina cualquier ambigüedad. Por ejemplo, en un escenario que describe a un usuario que accede por primera vez a una pantalla en particular, la condición previa puede aclarar que el usuario ha iniciado sesión.
Una acción indica exactamente lo que el usuario hace en la interfaz, y suele ser un "activador", como hacer clic en un botón, enviar un formulario o navegar a otro lugar.
Un resultado Es la consecuencia de la acción, y siempre debe ser algo que pueda ser probado..
Con estas partes en mente, escribamos una historia de usuario para la característica que describimos anteriormente:
Usando la sintaxis de Gherkin, esta historia se vería así:
| Característica | Permitir a los editores revisar artículos antes de la publicación final y sellar su aprobación en ellos. |
| Guión | Aprobar un artículo que está listo para su publicación.. |
| Condición previa |
|
| Acción |
|
| Salir |
|
Puede ver cómo la historia inicial se convierte en un flujo más detallado que el usuario puede seguir y, por lo tanto, se puede probar. Además, tenga en cuenta que las palabras en negrita son las que el software, como el pepino, utiliza para automatizar la ejecución de las pruebas. Explicaré más sobre esto más adelante, pero por ahora, quiero señalar que estas palabras clave son muy útiles también para escribir la historia porque ayudan a distinguir las diferentes partes de la historia..
Otra cosa a destacar es que aunque la historia proporciona más detalles sobre el flujo de usuarios, la interfaz no se describe. La razón de esto es que la descripción de la interfaz de usuario puede convertir rápidamente la historia en requisitos de interfaz de usuario, lo que presenta un gran problema, ya que pueden quedar obsoletos con bastante rapidez. Por ejemplo, si la historia describe cómo se ve la alerta de éxito y qué debería decir el mensaje específico, entonces la historia puede desincronizarse si algo de esto cambia, creando el potencial de pruebas que fallan..
Entonces, el truco es proporcionar suficientes detalles, sin hacer el trabajo de herramientas más adecuadas, como maquetas de diseño, prototipos y guías de estilo. A este respecto, notará que la acción indica "seleccionar aprobar" en lugar de usar "aprobar". "Seleccionar aprobar" no es específico en cuanto a cómo se ve este control (podría ser un botón, un botón que parece un enlace o un cuadro en el que se puede hacer clic), pero implica que un elemento en la interfaz de usuario se activa. También indica que este elemento ha escrito "aprobar". Esta es un área gris donde deberá usar el sentido común, ya que en algunos casos querrá ser tan específico para que las acciones puedan distinguirse de otras. Por ejemplo, si hay otra forma de aprobar un artículo en la misma página, lo que indica que en este escenario el usuario tiene que "seleccionarlo", permite hacer la diferenciación..
Además de la sintaxis reflexiva que proporciona Gherkin, una de las cosas que me parece más útil es usar la parte de "escenarios". Los escenarios son poderosos porque se pueden usar para probar el diseño y asegurarse de que todas las bases estén cubiertas.
Por lo general, los diseños de cualquier tipo comienzan con el "camino feliz", es decir, qué sucede cuando todo va bien en la interfaz y cómo se aplica a la mayoría de los usuarios. En nuestro ejemplo anterior teníamos:
| Guión | Aprobar un artículo que está listo para su publicación.. |
Además, dado que sabemos que los artículos tienen fechas de publicación, también podemos decir: Este es nuestro primer escenario porque en la mayoría de los casos, los artículos que deben ser aprobados deben estar listos para su publicación. Pero esto plantea la pregunta: ¿qué sucede cuando un artículo no está listo para su publicación y el editor accede a él? ¿Deben incluso poder acceder a esos artículos??
Todas estas preguntas son parte del proceso de diseño y lo más probable es que para el momento en que salte a los requisitos de documentación, sepa las respuestas. La buena noticia es que el uso de escenarios en la documentación de su historia lo ayudará a estructurarlos y, en muchos casos, lo ayudará a realizar un control de calidad de sus propios diseños, asegurándose de que haya un diseño y un flujo para cada uno de ellos..
Veamos cómo nuestra historia tomaría forma con los escenarios adicionales:
| Característica | Permitir a los editores revisar artículos antes de la publicación final y sellar su aprobación en ellos. |
| Escenario 1 | Aprobar un artículo que está listo para su publicación..
|
| Escenario 2 | Accediendo a un artículo que no está listo para su publicación..
|
| Escenario 3 | Aprobar un artículo que tiene una fecha de vencimiento pasada
|
| Escenario 4 | Desaprobación de un artículo que tenga una fecha de publicación en el futuro.
|
| Escenario 5 | Desaprobación de un artículo que ha sido publicado.
|
Dependiendo de la característica, puede haber muchos escenarios a considerar. La clave es mantenerlos cortos, para que puedas describirlos y probarlos fácilmente. También puedes intentar agruparlos, usando denominadores comunes. Por ejemplo, si algunos escenarios comparten la misma condición previa, puede encapsular esto en un "Fondo" que puede ser usado por múltiples escenarios. Por ejemplo:
| Fondo | El escritor ha enviado un artículo para su publicación y el editor ha accedido a la vista de edición de artículos.. |
| escenario 1 | Aprobar un artículo que está listo para su publicación..
|
| Escenario 2 | Aprobar un artículo que tiene una fecha de vencimiento pasada.
|
| Escenario 3 | Desaprobación de un artículo que tenga una fecha de publicación en el futuro..
|
Un desafío común que surge cuando se documentan los requisitos es decidir qué orden hacer. La razón es que, en la mayoría de los casos, todo está en construcción, lo que dificulta probar una interacción cuando las partes de las interacciones aún no están construidas. Por ejemplo, en la interacción simple de "aprobar" un artículo, muchas cosas deben estar listas:
Un enfoque para documentar los requisitos para cada una de estas dependencias, para registrarlas como características diferentes que luego pueden ser priorizadas de acuerdo a su valor comercial..
| Característica | Descripción | Prioridad |
|---|---|---|
| Sistema de alerta | La interfaz de usuario debe poder devolver un mensaje de éxito, así como un mensaje de error, en caso de que haya un problema en el sistema | 2 |
| Sistema de etiquetado | La interfaz de usuario debe poder "etiquetar" los artículos según lo aprobado | 4 |
| Sistema de publicación | La interfaz de usuario debe poder mostrar el artículo de acuerdo con la lógica comercial "publicada" | 1 |
| Sistema de notificaciones | Las notificaciones del sistema deben estar habilitadas, para que los escritores puedan recibir alertas cuando se produzca la aprobación | 3 |
Luego puedes crear una historia de "integración" para reunirlos a todos. Por ejemplo, una historia de usuario para el sistema de etiquetado le gustaría esto:
| Característica | Permitir que los usuarios y el sistema etiqueten artículos según un estado determinado (no publicado, aprobado, publicado o archivado). |
| Escenario 1 | Etiquetando un artículo como no publicado.
|
| Escenario 2 | Etiquetando un artículo como aprobado.
|
| Escenario 3 | Etiquetando un artículo como publicado.
|
| Escenario 4 | Etiquetando un artículo como archivado.
|
En la historia de integración, puede hacer referencia a la historia de etiquetado, en el caso de que los detalles de ese escenario deban verificarse nuevamente o si simplemente desea saber si esos casos ya se han verificado..
| Característica | Permitir a los editores revisar los artículos antes de la publicación final y sellar su aprobación en ellos. |
| Escenario 1 | Aprobar un artículo que está listo para su publicación..
|
El punto es evitar repetir la documentación que no solo consume tiempo innecesariamente, sino que también puede desincronizarse..
Hemos visto cuán útiles pueden ser las Historias de usuario dirigidas por el comportamiento para escribir requisitos que sean específicos, concisos, pero también completos y descriptivos. A partir de la fase de diseño, esta herramienta puede proporcionar una buena guía para que los ingenieros de control de calidad escriban casos de prueba reales.
Además de estas grandes ventajas, las Historias de usuario impulsadas por el comportamiento pueden convertirse en pruebas funcionales con la ayuda de un software, como el pepino o la lechuga. La idea básica es que una vez que las historias se escriben utilizando la sintaxis de Gherkin, puede colocarlas en una .característica Archivo dentro de su aplicación, y luego ejecútelos como pruebas para mostrar si tuvieron éxito o no. Para obtener un tutorial en profundidad sobre cómo usar Lettuce para una implementación en Python, consulte el tutorial de David Sale:
Escribir historias de usuario utilizando los principios de BDD puede servir para comunicar en detalle los requisitos comerciales y de diseño, con un enfoque centrado en el usuario, mientras se usa un lenguaje que es legible para los humanos pero extensible para la interpretación de software. Adicionalmente se puede utilizar para probar:
Esto significa más capas para que pasen los errores, lo que evita las brechas en el diseño y hace que su aplicación no sufra fallas en los fallos..
Accentsconagua