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.

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

22 comentarios:

  1. Respuestas
    1. De nada, mi recompensa es cuando mis posts aportan :-D

      Saludos,

      Alex

      Eliminar
    2. espero que estes bien, tus notas me han ayudado cuatro años despues. gracias

      Eliminar
  2. Estimado Alexander , me gustaría ponerme en contacto contigo, para si en caso puedes ayudarme a despejar unas dudas , espero puedas mi correo es jhonathan.polino@gmail.com.
    Qué tengas buen día.

    ResponderEliminar
    Respuestas
    1. Hola Jhonathan,

      Por supuesto estoy a tu disposición para ayudarte en las dudas que tengas. Te envío email para que puedas escribirme.

      Un saludo,

      Alex

      Eliminar
  3. Concreto y específico, muy buen aporte, representa la experiencia y el dominio del tema. Felicitaciones.

    ResponderEliminar
    Respuestas
    1. Muchas gracias, ver que lo que publico sirve a otros es mi recompensa. Gracias por escribir :-)

      Eliminar
    2. Hola buenas tardes habla con HEIDY me puede dar su número por favor

      Eliminar
  4. Todo este jodido blog es impresionante. Gracias no se si estan vivos pero que excelente trabajo !!!

    ResponderEliminar
    Respuestas
    1. Jajajaja, gracias por el reconocimiento :-) Si, estamos vivos, intentando compartir todo lo vamos aprendiendo y viviendo.

      Eliminar
    2. Alexander, me gustaria poder contactarme contigo por Gherkin
      Muy interesante post, mi correo es eder.andrades@gmail.com

      Eliminar
  5. Hola Alexander, espero te encuentres muy bien

    Me sería de gran ayuda que me brindarás una pequeña asesoria conforme a la realización de los criterios de aceptación de proyecto que me encuentro realizando.

    te agradecería enormemente.


    Saludos.
    andrescamilo_g@hotmail.com

    ResponderEliminar
  6. Hola Alexander,

    Información muy clarificadora. Es posible hacerte consultas por email relacionadas con procesos de calidad y/o testing?

    Gracias por tu aportación,
    fran.gramuntell.desco@gmail.com

    ResponderEliminar
    Respuestas
    1. Hola Fran,

      Al igual que lo estuve para Andrés (comentario anterior al tuyo) estoy disponible para consultas. Te he enviado un email.

      Saludos y gracias por leer el blog,

      Alex

      Eliminar
  7. Buenas tardes Alexander, agradezco me ayudes con una consulta sobre la parte del "dado" del cirterio de aceptación, esta parte puede ser algo como "dado que se ingresó al modulo de reportes como coordinador de ventas" (algo de interacción con el sistema, uso de menús y paths)? o necesariamente debe ser un dado de negocio como "dado que ya se ha realizado el cierre mensual de ventas".

    Muchas gracias por tu respuesta y disposición.

    ResponderEliminar
    Respuestas
    1. Hola,

      Los criterios de aceptación definen a través de escenarios de prueba el comportamiento de una determinada historia de usuario o funcionalidad, por ejemplo:

      Dado un límite de velocidad
      Cuando el coche está en marcha
      Entonces su velocidad no debe de superar el límite de velocidad

      Éstos escenarios ejemplificados se convierten en pruebas funcionales, por ejemplo:

      Dado un límite de velocidad de 50 km/h
      Cuando el coche está en marcha
      Entonces su velocidad no debe de ser = 49 km/h o inferior

      Los criterios de aceptación describen el comportamiento de la solución y pueden reflejar tanto interacción como reglas de negocio:

      Dado que se ingresó al modulo de reportes como coordinador de ventas
      Cuando el usuario pida un reporte
      Entonces se incluirá un resumen general de ventas de todos los vendedores

      Dado que se ha realizado el cierre mensual de ventas
      Cuando el coordinador haya comprobado los beneficios del negocio
      Entonces se realiza el proceso contable del periodo

      Espero haberte ayudado, saludos,

      Alex

      Eliminar
    2. Buenas noches Alexander. Me parece muy bueno su artículo, pero me queda una duda. En caso que esté describiendo el comportamiento de una solución, ¿en que parte de la historia de usuario o criterios de aceptación pondría los atributos que va a tener un formulario determinado?
      P.Ej.:
      Dado que se accedió en un e-commerce al servicio de tienda online como Cliente
      Cuando el usuario pida COMPRAR los productos que añadió a su carrito de compras
      Entonces el sistema mostrará un formulario para registrar los datos del beneficiario de la compra

      ¿Dónde debo incluir los atributos (campos) que conforman ese formulario?

      Eliminar
    3. Ah! ¿y otra cosa, donde se detallarían las validaciones de esos campos del formulario? Es decir, q tipo de caracteres acepta, longitud, etc.

      Eliminar
    4. Hola,

      Perdona el retraso. Una cosa es la descripción y entendimiento de la funcionalidad, y otra la información técnica detallada que necesites o generes.

      En tu ejemplo incluiría la lista de campos del formulario en los criterios de aceptación. Quizá hasta tendría más de una historia de usuario para grupos de campos según su importancia... eso si fuera un historia grande que necesite más de un sprint.

      Puedes adjuntar documentación técnica a la historia de usuario, como por ejemplo el tipo de campo, validaciones tipo longitud, fecha, etc. Nosotros tenemos una wiki donde recogemos toda esa información y la linkamos a la historia de usuario. Lo que hace el PO es explicar en el refinamiento al equipo lo que es requerido, diseñan juntos y luego el equipo, que sabe de tecnología, va construyendo/enriqueciendo la página de la wiki.

      Espero haberte ayudado, gracias por preguntar,

      Alex

      Eliminar
    5. Entendido!! Como lo hago no está tan alejado de lo q me sugieres, actualmente el listado de campos los incluyo en los criterios de aceptación y las validaciones las pongo como notas adjuntas en la propia historia de usuario. Muchas gracias por responder👍😊

      Eliminar