Criterios de Aceptación

Cómo definir criterios de aceptación


Los criterios de aceptación nos permiten definir una historia de usuario en un producto agile. Pero aprender a escribir buenas historias de usuario y buenos criterios de aceptación no es algo trivial. ¿Qué formato deben tener?¿Hasta qué nivel de profundidad deben llegar?¿en qué se diferencian de las especificaciones de requisitos de toda la vida?¿cómo se complementan con los casos de test?

Criterios de aceptación

Los criterios de aceptación definen los requisitos del Product Owner sobre cómo debe comportarse la aplicación para que una determinada acción se pueda llevar a cabo, normalmente por parte de un usuario de la aplicación. Generalmente ayudan al equipo de desarrollo a responder a las preguntas:

  • ¿He construido el producto correcto?
  • ¿He construido el producto correctamente?

Los criterios de aceptación deben describir siempre un contexto, un evento y la respuesta o consecuencia esperada del sistema. La forma más utilizada para describir los criterios de aceptación es conocida como Given-When-Then. Aquí un ejemplo:

Dado un usuario que aún no se ha identificado en el sistema

Cuando intenta acceder a alguna funcionalidad de la parte privada

Entonces se le redirige automáticamente a la página de login para que pueda identificarse

Aunque describen comportamiento de la aplicación, se utiliza siempre un lenguaje de negocio, no técnico. En el ejemplo anterior usamos “cuando intenta acceder a alguna funcionalidad de la parte privada” y no “cuando hace clic en alguna opción de menú que requiere sesión”.

Criterios de Aceptación

Ejemplo

Veamos un ejemplo, algo conocido por todos, el formulario de búsqueda de Google. Podríamos listar algunos criterios de aceptación como:

  1. Dada una petición a la página de búsqueda cuando se carga la página en el navegador entonces el cursor se desplaza al cuadro de búsqueda para que el usuario pueda comenzar a teclear de inmediato
  2. Dado que el usuario está en el cuadro de búsqueda y el usuario ha hecho login con su cuenta de Google cuando el usuario pulsa sobre el mismo cuadro de búsqueda entonces se le muestra una lista con sus últimas búsquedas
  3. Dado que el usuario está en el cuadro de búsqueda cuando el usuario teclea algo entonces se le muestra una lista con sugerencias de búsqueda relacionadas con lo que ha tecleado
  4. Dada(s) una(s) palabra(s) en el cuadro de búsqueda cuando el usuario acepta entonces se le redirige a la página de resultados del texto introducido
  5. Dada(s) una(s) palabra(s) en el cuadro de búsqueda cuando el usuario selecciona la opción “me siento con suerte” entonces se le redirige a la página del primer resultado de la búsqueda
  6. Dado que el usuario está en la página de búsqueda cuando el usuario selecciona la opción “Búsqueda por voz” entonces se le redirige a la página de reconocimiento por voz y una vez interpretado el texto se le devuelve a la página de resultados del texto interpretado

Si fuera una única historia de usuario, seguramente estaríamos delante de una épica. Podríamos utilizar los criterios de aceptación para dividir ésta en historias de usuario más pequeñas. Podríamos hacer una historia de usuario con los criterios 1 y 4, y el resto constituir cada uno historias de usuario independientes.

Precisión de los criterios de aceptación

Una pregunta frecuente es ¿hasta qué punto tengo que ser preciso y extenso en esta definición?¿tengo que poner todos y cada uno de los casos?. La respuesta es depende. Depende de la madurez y la experiencia del equipo de desarrollo, y también de su potestad y libertad a la hora de participar en la definición del producto. En un entorno donde el equipo es inexperto o bien negocio espera algo muy concreto y controlado, donde en la demo se revisan textos, tenemos que cumplir con una normativa muy restrictiva, etc. necesitaremos unos criterios de aceptación muy concretos y precisos. Si por el contrario el equipo resuelve con efectividad estos pequeños detalles y conoce el dominio casi tan bien como el Product Owner, los criterios de aceptación serán el inicio de las conversaciones y no el final.

Buenos Criterios de aceptación

En el ejemplo anterior vemos cómo se especifica la expectativa del usuario, pero no se entra en los detalles. ¿Qué pasa si el texto introducido no ofrece resultados?¿Qué pasa cuando no se reconoce la voz?¿cuántas sugerencias mostramos como máximo?¿podemos utilizar el teclado para seleccionar de la lista desplegable? Todas estas preguntas son detalles que seguramente se discutirían al refinar y planificar estas historias con el Product Owner.

Otra cosa que no hacemos es especificar los casos límites. ¿Qué pasa si introduzco un texto con 2000 caracteres?¿Puedo utilizar palabras reservadas (AND, OR, DELETE, DROP?¿Qué pasa si hago doble clic en el botón de búsqueda?. Si queremos probar que nada de esto rompe nuestra aplicación podríamos añadirlos como casos de tests.

Conclusión

Utilizar criterios de aceptación en nuestras historias de usuario nos permitirá tener muy claro cuándo hemos terminado la implementación, que lo que hemos hecho funciona y además es lo que el usuario necesitaba. Es el complemento ideal a nuestra Definition of Done.

Al que los escribe (normalmente el Product Owner) también le ayudará a mantenerse en el dominio del problema (lenguaje de negocio) sin traspasar al dominio de la solución (generalmente competencia del equipo de desarrollo).

Para profundizar más sobre los criterios de aceptación puedes consultar los siguientes artículos:

También te puede interesar...

Cómo iniciar tu primera comunidad de práctica (II)... En el artículo anterior definimos las comunidades de práctica como un espacio abierto en el que cualquiera puede aportar y participar. En un entorno c...
Resumen Scrum by Jeff Sutherland Tenía muchas ganas de leer este libro. Ya no solo porque era leer sobre el framework Scrum que utilizo a diario en mi trabajo, sino porque me lo había...
Los 7 desperdicios LEAN del software (y II) Este post es la continuación al post anterior Los 7 desperdicios del desarrollo de software donde describía los primeros 3 desperdicios del desarrollo...

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *