Criterios de Aceptación

La informalidad y uso del lenguaje natural para la captura de requerimientos a través de User Stories (US) no debe confundirse con un proceso laxo o ambiguo de desarrollo de software. Por el contrario, tal lenguaje acerca al usuario y cliente como acompañante del proceso en vez de posicionarlo únicamente bajo el rol de negociar un contrato. Este espíritu es uno de los puntos destacados del manifiesto ágil [1]. Si bien esto está claro para la redacción de US, muchas veces es dejado de lado al momento de especificar uno de los componentes fundamentales de una US: sus criterios de aceptación. Dichos criterios definirán si una cierta funcionalidad cumple sus objetivos o no, y como tal, es fundamental que sean redactados de manera clara, concisa, y sin subestimar su impacto. Siempre debe tenerse en cuenta que se debe abarcar los distintos escenarios de negocio, desde el principal pasando por las distintas alternativas y excepciones que puedan existir dentro del requerimiento. A continuación se describen consejos y heurísticas para la correcta especificación de criterios de aceptación que tienen respaldo y consenso dentro de referentes de la comunidad ágil comoRon Jeffries, uno de los fundadores de eXtreme Programming.

Criterios de Aceptación: definición y su rol dentro de las metodologías ágiles

Microsoft Press define a los criterios de aceptación como “las condiciones que un producto de software debe satisfacer para ser aceptado por un usuario, cliente o stakeholder. Para Google, son estándares pre-establecidos o requerimiento que un producto o proyecto debe satisfacer. Concretamente y yendo al mundo de las metodologías ágiles, en [2] se los define como un conjunto de sentencias redactadas de tal manera que conduzcan a una respuesta clara de “aceptado/rechazado”. Deben especificar tanto requerimientos funcionales como no funcionales. Un hecho importante es que una US bajo un dado criterio de aceptación, es un comportamiento binario: lo cumple o no lo cumple. No existe el concepto de cumplir parcialmente un criterio de aceptación. Este es, quizás, el aspecto a prestarle mayor atención al momento de especificar un criterio de aceptación: si bien son expresados mediante lenguaje natural deben ser “testeables”, es decir, conducir a una respuesta clara de funcionalidad aceptada o rechazada. Una buena heurística para ver si esto último se cumple es verificar que sea posible construir un caso de prueba a partir del criterio de aceptación. De no ser posible es un claro indicio de una mala redacción del mismo.

Es importante incluir en los criterios de aceptación tanto cuestiones funcionales como no funcionales. Es posible agregar, por ejemplo, un tiempo máximo para procesar una transacción como uno de los criterios de aceptación. Similarmente pueden agregarse cuestiones de disponibilidad (especificando por ejemplo tiempo máximo que puede estar caído un servicio), seguridad, mantenibilidad, o performance. Por último, es recomendable evitar cuestiones técnicas o de implementación. Una manera de lograr esto es expresar criterios de aceptación que denoten una intención, y no una solución. Por ejemplo: “el administrador puede aprobar o desaprobar el formulario de auditoría” en vez de una redacción como “el administrador puede hacer clic desde el radio button Aprobar/Desaprobar para aprobar una auditoría”. La segunda forma está atada a un tipo especial de componente (radio button) mientras que la primera es más flexible respecto a la implementación.

Tal como es mencionado en [3] el rol que juegan los criterios de aceptación de delimitar el alcance de una US le permite al equipo de desarrollo tener una noción más tangible de la funcionalidad detrás de cada US. También en [3] se enumeran los beneficios de acompañar una US con buenos criterios de aceptación:

• Fuerza al equipo a pensar una dada funcionalidad desde la perspectiva del usuario.
• Remueve ambigüedades de los requerimientos.
• Promueve la calidad del desarrollo desde el momento en que el equipo realiza las entregas de los requerimientos adhiriendo a los criterios de aceptación
• Constituirán la base para los casos de prueba que confirmarán si una dada funcionalidad está completa y se comporta como era esperado.

Finalmente, vale la pena mencionar la técnica de las tarjetas (en inglés es conocida como la regla de las 3 C´s [4]), propuesta por Ron Jeffries para redactar correctamente una US, incluyendo sus criterios de aceptación. Toda US debe surgir de aplicar las siguientes tarjetas:

• las US usualmente se anotan en tarjetas o stickers, las cuales contienen detalles adicionales, como los criterios de aceptación.
• conversar sobre detalles del alcance de la US que surgirán de la interacción con el Product Owner.
• los criterios de aceptación confirmarán la funcionalidad de una US.

A continuación se listan algunos posibles criterios de aceptación a modo de ejemplo:

1. Un usuario no puede enviar un formulario sin completar todos los campos obligatorios.
2. La información del formulario se almacena en la base de datos de participantes.
3. Está funcionando el filtro Anti-SPAM.
4. El pago puede efectuarse con tarjeta de crédito.
5. Se envía un mensaje de “Registración recibida” luego de recibir la información del formulario.
6. Un usuario no puede registrarse con la misma información de otro usuario.
7. Se deberá chequear por dirección de mail.
8. Se podrá acceder con el login de Facebook o Google+.

Referencias:

[1] http://agilemanifesto.org/

[2] http://www.seguetech.com/blog/2013/03/25/characteristics-good-agile-acceptance-criteria

[3] http://www.boost.co.nz/blog/2010/09/acceptance-criteria/

[4] http://ronjeffries.com/xprog/articles/expcardconversationconfirmation/