tiempo de lectura: 7 minutos

el éxito de cualquier proyecto depende de la capacidad de un equipo de desarrollo para satisfacer las necesidades de sus clientes. La comunicación entre el cliente y el equipo de desarrollo juega un papel vital en la entrega de una solución que se adapte a los requisitos del producto y del mercado., Los problemas surgen si los clientes explican sus necesidades de manera demasiado vaga y el equipo no puede entender los requisitos claros y, finalmente, el problema comercial detrás de ellos. Imagine que le pide a su equipo que permita a los usuarios buscar un producto en una Librería EN LÍNEA por categorías. Espera tener una interfaz clara con enlaces de categoría para hacer clic en ellos (por ejemplo, fantasía, no ficción, histórico, etc. Después de dos semanas de desarrollo, recibe una función de barra de búsqueda donde los usuarios deben escribir la categoría que les interesa, en lugar de navegar por las categorías pre-listadas., Si bien esto también funciona, su objetivo inicial era exponer todas las categorías disponibles y dejar que los usuarios exploren más.

esto es cuando la documentación de software de alta calidad podría ayudar a evitar el problema. Historias de usuario y criterios de aceptación (AC) como los principales formatos de documentación de requisitos. Una historia de usuario es una descripción en lenguaje natural de una característica. Suele ir acompañado de criterios de aceptación.

los criterios de aceptación (AC) son las condiciones que un producto de software debe cumplir para ser aceptado por un usuario, un cliente u otro sistema., Son únicos para cada historia de usuario y definen el comportamiento de la función desde la perspectiva del usuario final. Los criterios de aceptación bien escritos ayudan a evitar resultados inesperados al final de una etapa de desarrollo y aseguran que todos los interesados y usuarios estén satisfechos con lo que obtienen.

los criterios de aceptación son los requisitos funcionales de menor nivel

criterios de aceptación propósitos principales

aclarar los requisitos del stakeholder es un objetivo de alto nivel. Para que los propósitos de AC sean más claros, vamos a desglosarlos.,

Característica alcance detalization. AC define los límites de las historias de usuario. Proporcionan detalles precisos sobre la funcionalidad que ayudan al equipo a comprender si la historia se ha completado y funciona como se esperaba.

describiendo escenarios negativos. Yor AC puede requerir que el sistema reconozca las entradas de contraseña inseguras e impida que un usuario continúe. El formato de contraseña no válida es un ejemplo de un supuesto escenario negativo cuando un usuario hace entradas no válidas o se comporta inesperadamente. AC defina estos escenarios y explique cómo debe reaccionar el sistema ante ellos.

establecer comunicación., Los criterios de aceptación sincronizan las visiones del cliente y del equipo de desarrollo. Se aseguran de que todos tengan un entendimiento común de los requisitos: los desarrolladores saben exactamente qué tipo de comportamiento debe demostrar la característica, mientras que las partes interesadas y el cliente entienden lo que se espera de la característica.

optimización de las pruebas de aceptación. Los AC son la base de las pruebas de aceptación de historias de usuario. Cada criterio de aceptación debe ser comprobable de forma independiente y, por lo tanto, tener un escenario claro de aprobado o no aprobado. También se pueden utilizar para verificar la historia a través de pruebas automatizadas.

estimación de características., Los criterios de aceptación especifican qué debe ser desarrollado exactamente por el equipo. Una vez que el equipo tiene requisitos precisos, puede dividir las historias de usuario en tareas que se pueden estimar correctamente.

criterios de aceptación tipos y estructuras

AC se pueden escribir en diferentes formatos. Hay dos más comunes, y la tercera opción es idear su propio formato:

• orientado a escenarios (dado/cuando/entonces)
• orientado a reglas (lista de verificación)
• formatos personalizados

como el primero y el segundo formatos tienen estructuras muy específicas, nos centraremos principalmente en ellos., Sin embargo, es posible que otros formatos se adapten mejor a su producto, por lo que también los trataremos brevemente.

criterios de aceptación orientados a escenarios

El formato de escritura orientado a escenarios AC se conoce como el tipo/When / Then (GWT) dado.

• dada alguna precondición
• Cuando hago alguna acción
• entonces espero algún resultado

Este enfoque fue heredado de behavior-driven development (BDD) y proporciona una estructura consistente que ayuda a los evaluadores a definir cuándo comenzar y finalizar la prueba de una característica en particular., También reduce el tiempo dedicado a escribir casos de prueba, ya que el comportamiento del sistema se describe por adelantado.,

cada criterio de aceptación escrito en este formato tiene las siguientes declaraciones:

1. escenario – el nombre para el comportamiento que se describirá
2. dado – el estado inicial del escenario
3. Cuando – acción específica que el usuario realiza
4. Entonces – el resultado de la acción en «cuando»
5. y – se utiliza para continuar cualquiera de las tres declaraciones anteriores

cuando se combinan estas declaraciones cubren todas las acciones que toma para completar una tarea y experimentar el resultado.

veamos algunos ejemplos.,

Ejemplo 1

historia de usuario: como usuario, quiero poder recuperar la contraseña de mi cuenta, para poder acceder a mi cuenta en caso de que olvide la contraseña.,

Cuando: el usuario seleccionó la opción forgot password

Y: ingresó un correo electrónico válido para recibir un enlace para recuperar la contraseña

luego: el sistema envió el enlace al correo electrónico introducido

dado: el usuario recibió el enlace a través del correo electrónico

Cuando: el usuario navegó a través del enlace recibido en el correo electrónico

luego: el sistema permite al usuario establecer una nueva contraseña

Ejemplo 2

p >

historia de usuario: como usuario, quiero poder solicitar el efectivo de mi cuenta en cajeros automáticos para poder recibir el dinero de mi cuenta rápidamente y en diferentes lugares.,tapa

Y: dispensador contiene efectivo

Cuando: el cliente solicita el efectivo

a Continuación: asegúrese de que la cuenta se debita

Y: garantizar el efectivo se dispensa

Y: asegúrese de que la tarjeta se devuelve

los criterios de Aceptación 2:

Dado: que la cuenta está sobregirada

Y: la tarjeta es válida

Cuando: el cliente solicita el efectivo

a Continuación: asegúrese de que el rechazo se mostrará el mensaje de

Y: garantizar el efectivo no está dispensado

Regla orientada a los criterios de aceptación del formato

En algunos casos, es difícil ajustar los criterios de aceptación en la/Cuando/Entonces la estructura., Por ejemplo, GWT difícilmente sería útil para los siguientes casos:

• está trabajando con historias de usuarios que describen la funcionalidad a nivel de sistema que necesita otros métodos de garantía de calidad.
• el público objetivo para los criterios de aceptación no necesita detalles precisos de los escenarios de prueba.
• Los escenarios GWT no se ajustan a describir las restricciones de diseño y experiencia de usuario de una característica. Los desarrolladores pueden perder una serie de detalles críticos.

puede abordar estos casos con el formato AC orientado a reglas.,

la forma orientada a reglas implica que hay un conjunto de reglas que describen el comportamiento de un sistema. Basándose en estas reglas, puede dibujar escenarios específicos.

por lo general, los criterios compuestos usando este formulario parecen una simple lista de viñetas. Echemos un vistazo a un ejemplo.

ejemplo

historia de usuario: como usuario, quiero usar un campo de búsqueda para escribir una ciudad, nombre o calle, de modo que pueda encontrar opciones de hotel que coincidan.,

criterios básicos de aceptación de la interfaz de búsqueda

• el campo de búsqueda se coloca en la barra superior
• La búsqueda comienza una vez que el usuario hace clic en «Buscar»
• el campo contiene un marcador de posición con un texto de color gris:»»
• El marcador de posición desaparece una vez que el usuario comienza a escribir
• La búsqueda se realiza si un usuario escribe en una ciudad, nombre de hotel, calle o todos los combinados
• La búsqueda está en inglés, francés, alemán y ucraniano
• El Usuario no puede escribir más de 200 símbolos
• La búsqueda no admite símbolos especiales (caracteres)., Si el Usuario ha escrito un símbolo especial, muestre el mensaje de advertencia: «Search input cannot contain special symbols.»

otros formatos

La mayoría de las historias de usuario se pueden cubrir con los dos formatos mencionados anteriormente. Sin embargo, usted puede inventar sus propios criterios de aceptación dado que sirven a sus propósitos, están escritos claramente en un Inglés sencillo y no pueden ser malinterpretados. Algunos equipos incluso usan texto sin formato.,

a veces, sus criterios se pueden especificar como un ejemplo de comportamiento del sistema:

un conjunto simple de AC para contraseñas seguras por Mark Levison para agilepainpainrelief.com

este enfoque proporciona directrices claras para las pruebas de características de contraseñas.

Roles responsables y cómo se crean los criterios de aceptación

algunos de los criterios son definidos y escritos por el propietario del producto cuando crea el backlog del producto. Y los demás pueden ser especificados por el equipo durante las discusiones de historias de usuario después de la planificación de sprint., No hay recomendaciones estrictas para elegir a la persona responsable de escribir los criterios. El cliente puede documentarlos si tiene amplios conocimientos técnicos y de documentación de productos. En este caso, el cliente negocia los criterios con el equipo para evitar malentendidos mutuos. De lo contrario, los criterios son creados por un propietario de producto, analista de negocios, analista de requisitos o un gerente de proyecto.,

el proceso comienza con la priorización de la historia del usuario y termina con los detalles de negociación con todo el equipo

los principales desafíos y las mejores prácticas de redacción de los criterios de aceptación

los criterios de aceptación parecen muy fáciles de escribir. A pesar de sus formatos simplistas, la escritura plantea un desafío para muchos equipos. Echemos un vistazo más profundo a las mejores prácticas que ayudan a evitar errores comunes.

criterios del documento antes del desarrollo. Los criterios de aceptación deben documentarse antes de que comience el desarrollo real., De esta manera, el equipo probablemente capturará todas las necesidades del cliente por adelantado. Al principio, es suficiente establecer los criterios para un pequeño número de historias de usuario para llenar los retrasos de dos sprints (si practicas Scrum o un método similar). Deben ser acordadas por ambas partes. Luego, los desarrolladores utilizan los criterios de aceptación documentados para planificar el proceso técnico.

no haga que AC sea demasiado estrecho. Los criterios de aceptación pueden ser demasiado específicos viviendo pocas o ninguna opción de maniobra para los desarrolladores. Para evitar esto, recuerde que AC debe transmitir la intención, pero no una solución final., Además, AC estrecho puede estar privado de múltiples comportamientos de usuario que no están cubiertos.

Mantenga sus criterios alcanzables. Este punto se cruza estrechamente con el anterior. Los criterios de aceptación efectivos definen la parte mínima razonable de funcionalidad que puede entregar. Pero en caso de que sucumbas a describir todos los pequeños detalles, existe el riesgo de que tu equipo se quede atascado con cientos de pequeñas tareas.

mantenga la CA medible y no demasiado amplia. Los amplios criterios de aceptación hacen que una historia de usuario sea vaga., Los criterios de aceptación efectivos deben describir el alcance del trabajo para que los desarrolladores puedan planificar y estimar su esfuerzo adecuadamente.

Evite los detalles técnicos. Como mencionamos, los criterios de aceptación deben estar escritos en un Inglés sencillo. Esto los hará claros y fáciles de entender para todos: sus partes interesadas o gerentes pueden no tener antecedentes técnicos.

Llegar a un consenso. El mismo problema puede ser resuelto de manera diferente por un equipo y las partes interesadas, dependiendo de sus puntos de vista. Asegúrate de haber comunicado tu ca a las partes interesadas y de haber llegado a un acuerdo mutuo., Lo mismo se aplica a los miembros del equipo. Todos deben revisar el AC y confirmar que entienden y están de acuerdo con cada línea.

escribir AC comprobable. Esto permitirá a los evaluadores verificar que se cumplieron todos los requisitos. De lo contrario, los desarrolladores no entenderán si se completa la historia de usuario.

palabra final

no descuide los criterios de aceptación, ya que, al ser simples y accesibles, resuelven múltiples problemas a la vez., Documentan las expectativas de los clientes, proporcionan una perspectiva del usuario final, aclaran los requisitos y evitan la ambigüedad, y finalmente ayudan al control de calidad a verificar si se cumplieron los objetivos de desarrollo. Independientemente de si utiliza métodos ágiles o no, asegúrese de elegir el mejor formato o experimente con los suyos propios. Los diferentes tipos de historias de usuario y, finalmente, las características pueden requerir diferentes fromats y probar los nuevos que funcionan para usted es una buena práctica.