¿Cómo escribir los criterios de aceptación?

Después de 50 años de historia de ingeniería de software hemos llegado a la conclusión de que los criterios de aceptación, que son el detalle de las historias de usuarios desde el punto de vista de testing y se traducen en pruebas, son un excelente lenguaje para especificar requisitos funcionales, y es por ello que toman tanta importancia en las historias de usuario.

Buenas prácticas con criterios de aceptación
Cortesía de Miguel Angel Sobrino

Para medir la calidad de un criterio de aceptación se utiliza el método SMART en el que se han de cumplir en lo máximo posible los siguientes criterios:

• S - Specific (Específicos)
• M - Measurable (Medibles)
• A - Achievable (Alcanzables)
• R - Relevant (Relevantes)
• T - Time-boxed (Limitados en el tiempo)

Se suelen escribir en forma de checklist o descripción de un flujo en cuanto se obtengan historias de usuario susceptibles de entrar en un sprint, y se acaban de refinar en la planificación de sprint. Los criterios de aceptación ayudan al equipo de desarrollo a entender el funcionamiento del producto, de manera que estimarán mejor el tamaño de la historia subyacente y, cuando el equipo se encuentre en fase de desarrollo servirá de guía cuando el desarrollador tenga que tomar una decisión, tomará la más acertada.

Finalmente, y a modo del viejo truco del palillo en repostería, como lo describe Tamara Vázquez en su post sobre criterios de aceptación, si se mete un palillo en la porción de tarta, que representa el incremento del sprint, y sale limpio, es que la porción de tarta está bien hecha, de la misma manera que el Propietario del Producto comprueba en la revisión de sprint, a través de estos criterios de aceptación y la definición de hecho, si la historia de usuario se puede dar como hecha y finalizada.

Diferentes formatos para escribir criterios de aceptación:

Comprobar [Criterios]

Demostrar [Comportamiento esperado]

Verificar que cuando [Rol] hace [Acción] consigue [Resultado / Comportamiento esperado]

Dado que [Contexto] y adicionalmente [Contexto] cuando [Evento]

entonces [Resultado / Comportamiento esperado]

Sintaxis gherkin para describir el comportamiento del software

Actualmente estoy acompañando a una serie de proyectos en los que estamos escribiendo los criterios de aceptación con el lenguaje natural, tal como el Propietario del Producto se expresa. Mirando hacia el futuro estamos planteándonos si escribirlos con la técnica del comportamiento por escenarios. Así, cuando implantemos BDD (Behavior Driven Development), los usuarios de negocio y los Propietarios del Producto estarán acostumbrados a escribirlos de esa forma, en concreto pensamos en implantar gherkin, el lenguaje específico creado especialmente para las descripciones de comportamiento de software. La sintaxis de gherkin es la siguiente:

(Scenario) Escenario [Número de escenario] [Titulo del escenario]:

(Given) Dado que [Contexto] y adicionalmente [Contexto],

(When) cuando [Evento],

(Then) entonces [Resultado / Comportamiento esperado]

Derivado de esta sintaxis los elementos de los criterios de aceptación son:

• Número de escenario: Número (ejemplo 1, 2, 3 ó 4), que identifica al escenario asociado a la historia.
• Título del escenario: Describe el contexto del escenario que define un comportamiento.
• Contexto: Proporciona mayor descripción sobre las condiciones que desencadenan el escenario.
• Evento: Representa la acción que el usuario ejecuta, en el contexto definido para el escenario.
• Resultado / Comportamiento esperado: Dado el contexto y la acción ejecutada por el usuario, la consecuencia es el comportamiento del sistema en esa situación.

Ejemplo:

Partimos de la siguiente historia de usuario:

Como cliente

Quiero retirar dinero del cajero automático

Para poder evitar ir al banco a hacer una cola

y escribimos los criterios de aceptación en gherkin:

Escenario 1: Cuenta tiene crédito

Dado que la cuenta tiene crédito

y que la tarjeta es válida

y que el cajero tiene dinero disponible

Cuando el cliente pide dinero

Entonces la cuenta es debitada

y el dinero es entregado al cliente

y el cliente recupera su tarjeta

Escenario 2: La cuenta excede el límite negativo acordado con el banco

Dado que la cuenta excede el límite negativo acordado con el banco

y que la tarjeta es válida

Cuando el cliente pide dinero

Entonces el cajero muestra un mensaje negando el pedido

y el dinero no es entregado al cliente

y el cliente recupera su tarjeta

Plantilla para criterios de aceptación,
cortesía de La Oficina de Proyectos de Informática

PMOInformática.com nos propone una excelente plantilla para recoger y documentar las historias de usuario y sus criterios de aceptación, plantilla que está libre de derechos de autor y puede ser usada libremente (descargar plantilla) :-)

En su página muestran el siguiente ejemplo de un criterio de aceptación:

Escenario 1: Dado que existe una categoría sin productos asociados, cuando el cliente despliegue el listado de categorías para realizar su búsqueda, entonces el sistema mostrará el siguiente texto al lado de la categoría "Actualmente no poseemos productos para esta categoría".