domingo, 18 de octubre de 2015

¿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.

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 y 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, si la historia de usuario se puede dar como hecha y finalizada.
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 nos estamos planteándonos 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 el sistema [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

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".

No hay comentarios:

Publicar un comentario