La calidad del software es como un dado con muchas caras. Entregar valor a los clientes es una de esas caras, y lo logramos solamente entregándoles lo que realmente necesitan.

Es alto el riesgo de no entregar exactamente lo que el cliente necesita porque no hacemos las preguntas correctas, no indagamos lo suficiente o nos concentramos demasiado en un feature específico olvidándonos del “big picture“. Te has enfrentado a una alta tasa de historias que no pasan la aprobación final (del usuario)? Te ha tocado re-trabajar historias cuando creías que estaban listas para ir a producción?

Para lograr una buena definición (buen diseño del feature) es necesario generar conversaciones para aclarar y confirmar con los clientes aquello que se convierte en nuestro Criterio de Aceptación.

Muchas veces refinando historias nos encontramos con “me puedes dar un ejemplo?”. De eso de trata el example mapping, un core practice del Agile Testing: Desarrollo guiado por ejemplos (ATDD, BDD).

Qué es example mapping?

Es una técnica de definición de requerimientos que nos permite explorar soluciones a un problema utilizando ejemplos de reglas y, haciendo las preguntas que nos permitirán cubrir la mayor cantidad de reglas posibles con el fin de diseñar una solución.

Cada regla puede tener más de un ejemplo.

En el libro Agile Testing Condensed encontramos un capítulo completo llamado ¨guiando el desarrollo con ejemplos¨ en el que lo define como una de las prácticas principales del agile testing: “ejemplos concretos de comportamientos deseados y no deseados ayudan a los equipos a tener un entendimiento colectivo de cada funcionalidad“.

Cómo ayuda a los equipos?

Nos ayuda a construir las soluciones correctas. Si sabemos cuáles son los comportamientos deseados y los no deseados podremos construir funcionalidades menos propensas a ser rechazadas por los usuarios. Se convierten en nuestros UAC (User Acceptance Criteria) para cada historia de usuario o tarea. Por supuesto, las historias se discuten y se refinan, se dividen y demás.

Reduce el tiempo de desarrollo, ya que reducen/eliminan incertidumbre y es una de las cosas que más perseguimos en la agilidad: reducir incertidumbre (y no para bajar las estimaciones en el sprint planning pero eso es historia de otro post).

Hacen super fácil implementar TDD, ya que usa las reglas definidas a través de los ejemplos para diseñar y codificar primero los tests.

Hacen super fácil implementar BDD, ya que las reglas definidas a través de los ejemplos están escritas en lenguaje natural y son convertibles a Gherkin (Given/When/Then) sin mayor esfuerzo y nos ayudan a establecer todos nuestros escenarios de test.

Nos da la oportunidad de involucrar a los usuarios (o el equipo de producto) al 100% al trabajarlos en lenguaje natural. El usuario no necesita ningún conocimiento técnico para participar de estas sesiones. Los detalles técnicos aparecen cuando estamos refinando historias como equipo de desarrollo.

Cómo lo desarrollamos?

Se trata, básicamente, de generar conversación alrededor de la funcionalidad que deseamos construir. Tenemos:

Reglas, que definen lo que el sistema/plataforma debería o no debería hacer. Serán nuestros criterios de aceptación.

Ejemplos, que describen cómo y cuándo tienen lugar las reglas, qué incluyen, qué eventos específicos los disparan, cómo el usuario interactúa con el sistema/plataforma a través de estas reglas y cuáles son sus roles.

Preguntas que nos ayudan a identificar las suposiciones correctas o incorrectas o explorar escenarios no identificados, profundizar escenarios identificados y descubrir lo “no conocido”.

Necesitaremos algunas tarjetas, un espacio en blanco (pizarra si es físico) o un board si es online, y estamos listos para conversar y escribir.

 

 

Story

Escribimos la historia (o lo que inicialmente pensamos que es la historia, ésto también se va refinando) en la tarjeta amarilla.

Rule

Escribimos los criterios de aceptación del usuario (o los que inicialmente pensamos que son, basado en la conversación con los usuarios, ésto también se va refinando). Están representadas en las tarjetas azules.

Example

Escribimos todos los ejemplos posibles que cumplan los criterios de aceptación del usuario. Son las tarjetas verdes y se colocan debajo de cada regla (la que consideremos más acertada según el ejemplo).

Questions

Aquí registramos todas aquellas preguntas que nadie en la sesión puede responder. Requieren mayor investigación o la presencia de otros usuarios o interesados en el proyecto o quizás, de algún experto en la solución que queremos implementar.

Dicho ésto, iniciamos la conversación y dejamos fluir preguntas y respuestas, discusiones de puntos de vista u opiniones, hasta que hayamos satisfecho todo o se nos acabe el tiempo.

 

Vamos a la práctica: proyecto de tracking de gastos

Historia: Como usuario quiero registrar mis transacciones de inversiones en mi registro personal de gastos.

Tengo una aplicación de registro de gastos en el que registro todas mis transacciones de ingresos y gastos por categorías, tengo registro de saldos en cuentas bancarias y manejo de presupuesto por categorías. Quisiera registrar mis transacciones de inversiones, que no son gastos corrientes, necesito establecer otro tipo de “cuenta de inversión” en el que registre mis inversiones y sus rendimientos y poder ver reflejados los cambios en mi patrimonio neto.

Ejemplo de mi estado inicial

Regla 1:

Cuando transfiero dinero a “cuenta de inversión”, el monto de inversión será descontado de mi cuentas bancarias pero no de mi patrimonio neto, y a su vez será aumentada mi “cuenta de inversión”.

Ejemplo 1

Si invierto 1000$, se transfieren 1000$ de mi cuenta bancaria a mi “cuenta de inversión”, y mi patrimonio neto permanece igual.

 

Regla 2:

Cuando retiro dinero de mi “cuenta de inversión”, el monto retirado deberá ser reflejado como ingreso en la cuenta bancaria pero no como aumento de mi patrimonio neto.

Ejemplo 2

Si retiro 300$, se transfieren 300$ de mi “cuenta de inversión” a mi cuenta bancaria, y mi patrimonio neto permanece igual.

 

Regla 3:

Si vendo un activo de mi cuenta de inversión, se registra el monto de diferencia respecto al precio de la compra del activo.

Ejemplo 3

Vendo una acción en 115$, que costó 100$, tuve un rendimiento de 15$. Ese valor aumenta mi “cuenta de inversión” y mi patrimonio neto

 

Ejemplo 4

Vendo una acción en 85$, que costó 100$, tuve un rendimiento negativo de 15$. Ese valor disminuye mi “cuenta de inversión” y mi patrimonio neto.

 

Preguntas

  1. Qué pasa si no registro los rendimientos al momento de vender acciones?
  2. Cómo registro el saldo inicial de mi cuenta de inversión? si ya había invertido antes y no lo había registrado
  3. Cómo registro un dividendo?
  4. Que pasa si hay un split de la acción?

Puedes ver la imagen más grande aquí

 

Conclusiones

Como tester, aún si no aplicas esta técnica para definir requerimientos, estoy segura que te puede ayudar a definir escenarios de tests al tener muy bien definidos los User Acceptance Criteria y hasta automatizar con BDD.

Cuando estoy diseñando las pruebas, mi primer insumo es el UAC, busco muchos posibles ejemplos y hasta puedo imaginar casos que salen de los ejemplos en los que se basó la definición de requerimientos.

Escribir todos estos escenarios parece fácil pero conlleva bastante práctica llegar a simplificar casos para escribir tests.

Entregamos valor a los clientes, construyendo el producto correcto de la mejor calidad posible.