Criterios de aceptación

Los Criterios de Aceptación (CA’s) son un conjunto de escenarios o comportamientos en formato checklist o lista de comprobación añadidos a las historia de usuario (HU) para, por un lado definir qué espera el usuario, o negocio, de esa HU cuando esté acabada, y por otro lado para que las personas que desarrollan esa HU y la persona con la responsabilidad de Product Owner o Product Manager puedan validar que cumple con las expectativas.

Generalmente, están escritos por el Product Owner (a veces en colaboración con desarrollo) o por la persona con el rol de QA. 

Para formalizar los Criterios de Aceptación, a menudo se usa una estructura inspirada en el lenguaje Gherkin dedicado a la descripción de comportamientos de software (BDD o Behavior Driven Development) en lugar de la tradicional  descripción basada en pruebas (TDD o Test Driven Development).

Esta estructura usa la regla DADO-CUANDO-ENTONCES:

• DADO (Given) un contexto inicial.  Definimos el estado del software antes de la ejecución de la HU, situación inicial.
• CUANDO (When) se produce un evento. La acción que desencadena o detona un proceso.
• ENTONCES (Then) se produce un resultado. El estado del software después de la ejecución, situación final.

Por ejemplo, para una HU relacionada con un formulario de inicio de sesión, un Criterio de Aceptación sería: «DADO un usuario sin loguearse en la página de inicio de sesión con un nombre de usuario y una contraseña correctas escritas en los campos de usuario y contraseña, CUANDO haga clic en el botón «Conectar» ENTONCES navega a la página de inicio del sitio».

Un Criterio de Aceptación no debe ofrecer una solución técnica, debe estar escrito desde el punto de vista del usuario y describir el comportamiento o escenario esperado por el producto al recibir un comportamiento natural de un usuario.

A la hora de escribir Criterios de Aceptación, una buena práctica sería escribir el escenario ideal o el happy path y después en los siguientes CA’s ir rompiendo ese escenario ideal.

En el ejemplo anterior habríamos descrito el escenario ideal, por tanto, para escribir los siguientes escenarios podríamos hacernos las siguientes preguntas (entre otras):

• Qué ocurre si el usuario o la contraseña son incorrectas
• Qué ocurre si uno de los campos o los dos están vacíos
• Qué ocurre si pulsa varias veces en el botón de «Conectar»
• Existe algún número máximo de reintentos
• Qué ocurre si nuestro sistema está caído y da un time out
• Etc.

A veces, se pueden dar escenarios complejos donde concatenamos varias condiciones, eventos y resultados.

Para el ejemplo anterior:  «DADO un usuario sin loguearse en la página de inicio de sesión con un nombre de usuario y una contraseña correctas escritas en los campos de usuario y contraseña y cuyo navegador sea chrome con una pestaña de incógnito, CUANDO haga clic en el botón «Conectar» y no ha aceptado la política de privacidad y no ha aceptado las cookies, ENTONCES navega a la página de inicio del sitio y aparece un popup solicitando que acepte las políticas de privacidad y aparece el banner de cookies».

Este tipo de Criterios de Aceptación tan complejos suelen trabajarse de forma independiente dividiéndolo en 3 CA’s diferentes. Por ejemplo:

1.  «DADO un usuario sin loguearse en la página de inicio de sesión con un nombre de usuario y una contraseña correctas escritas en los campos de usuario y contraseña, CUANDO haga clic en el botón «Conectar» ENTONCES navega a la página de inicio del sitio».
2. «DADO un usuario cuyo navegador sea chrome con una pestaña de incógnito, CUANDO inicie sesión sin aceptar la política de privacidad, ENTONCES aparece un popup solicitando que acepte las políticas de privacidad en la página de inicio».
3.  «DADO un usuario cuyo navegador sea chrome con una pestaña de incógnito, CUANDO inicie sesión aceptar las cookies, ENTONCES aparece el banner de cookies en la página de inicio».

Para el desarrollo de buenos Criterios de Aceptación solemos recomendar el uso de talleres de alineación como Tres Amigos, donde involucramos a una persona que represente a desarrollo o IT, a una persona que representa a Diseño y a una persona que representa a negocio como es el Product Owner.

No es necesario que haya tres personas, pero sí deben estar representadas las 3 áreas de responsabilidad o competencias. 

Se pondrán de acuerdo sobre los escenarios de los criterios de aceptación y luego compartirán la redacción usando Gherkin.

Para saber más: descarga el libro Agile Product Management

Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy