Criterios de aceptación

El tester se encarga de ayudar al cliente a definir los criterios de calidad para cada historia de usuario. Estos criterios son necesarios para los programadores a la hora de estimar la duración de cada historia. Cuanto más precisos sean los criterios más exactas serán las estimaciones [Crispin.2001].

Un criterio de aceptación es el criterio por el cual se define si una historia de usuario fue desarrollada según la expectativa del Product Manager/Owner (como representante de los criterios del cliente) y se si puede dar como hecha. Una metáfora que se usa para describir un criterio de aceptación es el viejo truco del palillo en repostería: si se mete un palillo en una tarta y sale limpio es que la tarta está hecha.

Deben ser definidos lo antes posible porque complementan la historia de usuario y ayudan al equipo de desarrollo a entender mejor cómo se espera que el producto se comporte. Así que, si estas expectativas están claras antes de empezar a desarrollar, el desarrollo será más fluido. Asimismo, la estimación de una historia de usuario también se hace más fácil y más exacta.

Además, los criterios de aceptación sirven de guía para el desarrollo de los test. Deben cubrir los casos de uso posititvos o comunes (el trayecto feliz) pero también los casos extremos o “corner case”, por ejemplo, en una aplicación para grabar vídeos, el usuario está grabando un vídeo y se queda sin batería.

Las calidades de un criterio de aceptación eficaz se definen bajo el método SMART. SMART significa Specific (Especifico), Measurable (Medible), Achievable (Alcanzable), Relevant (Relevante) y Time-bound (Temporalmente limitado).

Existen dos técnicas para escribir criterios de aceptación:

1.      Técnica de comportamiento: Dado/a una condición, Cuando ocurre un evento o acción, Entonces sucederá una consecuencia. Así se consigue una estructura consistente que se trasladará fácilmente a test automáticos.

2.      Técnica de escenarios: Suele definir “el trayecto feliz” y un trayecto alternativo de la funcionalidad en cuestión y debe describir cómo el usuario ejecutaría o intentaría ejecutar los diferentes pasos en dichos trayectos. Al restringirse sólo a la forma en que el usuario procedería y el sistema correspondería, elimina toda la información innecesaria. Tiene la ventaja de que permite al equipo de desarrollo ir dando por hechas las funcionalidades y los casos que de ella se origina mientras las van implementando. Su mayor beneficio es que estos criterios de aceptación no pueden ser trasladados directamente de la historia de usuario a un test de aceptación automático. Eso puede resultar en escribir un test de aceptación que compruebe más de un criterio de aceptación, que es lo recomendado. Además, nos permiten usar más de un usuario para describir el escenario del criterio.

El uso de Criterios de aceptación aporta muchas ventajas, las que me parecen más importantes:

1.      Fomentan la comunicación entre Product Owner y equipo.

2.      Ayudan en la estimación de la historia al imponerle límites.

3.      Garantizan que el trabajo realizado será lo solicitado por el Product Owner.

4.      Reducen las necesidad de hacer consultas al Product Owner durante el sprint, con la consiguiente pérdida de productividad del equipo y del Product Owner.