¿Cómo escribir Tests de Aceptación?

banner

Una habilidad clave para el Tester Agil

A partir de la proliferación de las metodologías ágiles, el rol del Tester ha sufrido un proceso de mutación. En las metodologías tradicionales, el Tester escribía casos de prueba detallados, partiendo de un documento funcional escrito por un Analista, incluso antes de que se escribiera la primera línea de código del proyecto. En el mundo Agil, en cambio, el documento funcional no existe, por lo que el Tester deberá completar las especificaciones para cada historia de usuario (user story), generalmente en forma de Tests de Aceptación.

descarga

¿Qué son los Tests de Aceptación?

A diferencia de las especificaciones tradicionales, las historias de usuario tienen un enfoque de negocio y están escritas por una persona con ese perfil (Product Owner).Típicamente, la historia de usuario tiene el siguiente formato:

Como usuario (X)… Quiero (Y)… De manera que (Z)…

(Y) representa una funcionalidad, (Z) es el beneficio para el negocio y (X) es la persona o rol que se beneficiará con esa funcionalidad.

Como puede verse, las historias de usuario se concentran en qué debe hacer el software para satisfacer una necesidad de negocio, pero dicen poco y nada sobre cómo debe hacerlo.
Esto implica un desafío para todo el equipo, pero especialmente para el Tester, que será el encargado de averiguar y documentar cómo deben ser implementadas cada una de las funcionalidades que el cliente está solicitando.
Para ello se utilizan los Tests de Aceptación (*), también llamados Tests de Historia de Usuario (Acceptance Tests/Story Tests). Los Tests de Aceptación verifican que la historia de usuario se ha desarrollado correctamente y por consiguiente, entregará al usuario el valor esperado para su negocio.

¿Cómo se escriben los Tests de Aceptación?

En primer lugar, el Tester deberá tomar cada una de las historias de usuario y escribir los Tests de Aceptación que verifiquen la funcionalidad solicitada. El formato que se recomienda para escribir dichos Tests es el siguiente:

Si… (X)
Cuando… (Y)
Entonces… (Z)

(X) representa el contexto, todas aquellas condiciones que deben cumplirse para que el usuario pueda realizar la acción y, por lo tanto, ejecutarse el Test.
(Y) es la acción que el usuario va a realizar en el contexto definido previamente.
(Z) es la respuesta esperada del sistema ante las acciones del usuario detalladas previamente.

De esta manera, el Tester comenzará a especificar cómo deberá comportarse el software ante los diferentes escenarios que se vayan planteando, de acuerdo a la funcionalidad requerida por la historia de usuario.
Deberán considerarse la mayor cantidad de escenarios posibles, tanto los normales como los alternativos, intentando abarcar todos los modos de uso del software que estarán a disposición de los usuarios.

¿Y cuando me falta información?

El proceso de escribir los Tests de Aceptación es un proceso iterativo, no es algo de se realiza de una vez. El Tester deberá comenzar con un pequeño set de Tests de acuerdo a la información con la que cuente, y se espera que a partir de ahí, vaya refinando los tests. Es decir, agregando mayor detalle y escribiendo nuevos Tests, a partir de los escenarios que se van disparando cuando va consiguiendo nueva información.
Es evidente que en este proceso, es fundamental la comunicación. El Tester deberá mantenerse en contacto permanente con el Product Owner o con el Analista de Negocio, si lo hubiera, y formular todas las preguntas necesarias para abarcar el mayor número de escenarios posible, llevándolos al mismo tiempo al máximo nivel de detalle necesario.
Resulta imprescindible que el Tester sepa ubicarse en los zapatos del cliente y entender a fondo sus negocios y las necesidades que del mismo se derivan. A su vez, es clave que sepa formular las preguntas correctas para obtener los requisitos. Algunas de esas preguntas podrían ser:

¿Cuál es el objetivo de esta funcionalidad?
¿Qué roles tienen objetivos relacionados a la funcionalidad?
¿Cómo podemos saber que la funcionalidad entregada es la correcta?
¿Cuáles son las salidas que el cliente espera?
¿Qué harán los usuarios antes y después de utilizar esta funcionalidad en particular?
¿Qué es lo peor que podría pasar cuando el usuario utiliza esta funcionalidad? ¿Qué es lo mejor?
¿Se pueden obtener ejemplos de cómo el usuario va a utilizar esta funcionalidad?
¿Existen requerimientos no funcionales que deban tenerse en cuenta?

Estas son sólo algunas de las preguntas que pueden hacerse y normalmente, las respuestas nos dispararán nuevas preguntas. Es por eso que decimos que la escritura de Tests de Aceptación es un proceso iterativo, que se irá refinando con el tiempo, a medida que vayamos obteniendo más información. E, incluso, que el propio cliente vaya teniendo mayor claridad sobre qué es lo que necesita.

Como conclusión, los Tests de Aceptación completos, resultarán sumamente útiles, no sólo para el Tester sino para todo el equipo, ya que los desarrolladores podrán basar su código en ellos, adaptándolo según la especificación de los tests. Por su parte, el Product Owner podrá saber cuándo una historia de usuario puede considerarse “terminada”, en función de que haya superado exitosamente todos los Tests de Aceptación.

 

(*) no confundir con las Pruebas de Aceptación, que se realizan junto con el usuario para validar que el software desarrollado está conforme a los requerimientos.

banner

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s