¿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

Adelante el UAT para dejar atrás los problemas

Uno de los principios del Manifiesto Agil dice “Colaboración con el cliente antes que negociación de un contrato“. Este principio es uno de los que más cuesta implementar en la práctica, ya que no depende del propio equipo, sino que implica a un tercero (el cliente, a quien, justamente, hay que incluir en el equipo para ser exitosos).

El UAT (User Acceptance Test) es uno de los momentos en que más se anhela que el cliente adopte una actitud colaborativa. Sin embargo, suele pasar que el cliente mantiene una postura típica de proyectos waterfall, donde esperaba pasivamente a que el software le fuera demostrado y se sentía en posición de mostrar el pulgar arriba o el pulgar abajo, a la manera del Emperador romano, con la potestad de aprobar o no.

Gladiator

Una forma de incentivar mayor colaboración del cliente, además de otros beneficios, es adelantar el UAT en el proceso de desarrollo. Se lo ubica antes del Testing, e incluso antes del code review, haciendo que el cliente revise la user story recién desarrollada y confirme que es exactamente lo que esperaba.

Creía que quería A, pero en realidad quiero B

El motivo más frecuente por el que una user story no pasa el UAT es que el cliente se da cuenta de que aquello que pidió no es exactamente lo que quería o necesitaba. O, lo que produce el mismo resultado, que se entendió mal el requerimiento.

O bien se da cuenta de que la funcionalidad resultaría mejor con algunos cambios. En todo caso, salen a la luz aquellas cosas que no tuvo en cuenta en un primer momento y que al ver el producto terminado se le hacen evidentes.

Con el UAT temprano, podemos identificar antes esos problemas, ahorrando ciclos y re-trabajo. Además, se produce el efecto de que el cliente asume mayor responsabilidad por sus requerimientos, lo cual facilita también las negociaciones cuando se decide que los cambios que solicita no se van a hacer.

Testing aliviado

Otro de los beneficios de adelantar el UAT es que se alivianan las tareas de Testing, ya que los Testers no tienen que preocuparse por las validaciones básicas de si se entendieron bien los requerimientos, si se cumplió con lo que quería el cliente, lo cual siempre implica idas y vueltas de preguntas y diálogos que llevan tiempo.

De esta manera, los Testers pueden concentrarse en detectar errores, haciendo su trabajo más eficiente (y divertido), acelerando los tiempos y minimizando los ciclos.

Desarrollo más seguro

El beneficio más visible para los Desarrolladores es que se sienten más seguros de que están desarrollando el requerimiento correcto, porque se minimizan los malos entendidos. Y, en los casos en que hay que rehacer el trabajo, esto se hace antes, cuando tienen el código más fresco y les cuesta menos introducir modificaciones.

Ahorro de tiempo y dinero

Lo más importante: menos ciclos, menos re-trabajo, menos tareas de Testing equivale a un significativo ahorro en los costos del proyecto.

Esto puede hacerse claramente visible después de un tiempo de implementada esta práctica. Al principio, puede resultar incómodo para el equipo tener al cliente involucrado tan tempranamente, cuando los desarrollos parece que todavía están un poco “verdes”. Pero a la larga, los beneficios son muy claros.

Estas son algunas de las ventajas de adelantar el UAT a una etapa más temprana. Claro está que una vez que se pasó la etapa de Testing, el cliente puede darle una mirada final para formalizar el sign off. Pero esto será un paso mucho más simple y directo porque el cliente ya vio el desarrollo tempranamente y lo aprobó. Se evita asimismo la ansiedad de esperar para ver qué le van a mostrar, en qué se convirtió su requerimiento. Y algunas sesiones de UAT en las que nos ha tocado estar donde el aire se corta con un cuchillo, porque el clima es tenso, como cuando el Emperador muestra su pulgar y nadie está seguro de si lo va a mover felizmente hacia arriba o trágicamente hacia abajo.

Esta práctica viene funcionando muy bien para nosotros y en proyectos donde algunos colegas nos cuentan que la han implementado. Los invitamos a probarla y contarnos cuál es su experiencia.