22 Agosto, 2019

Un camino para repensar la práctica del testing

De experto a experto

Cuando proponemos las actividades de testing, muchas veces nos encontramos con respuestas como “Es muy caro”, “Esto alarga el plazo del proyecto, no tenemos tanto tiempo”, o incluso sucede que a pesar de haber realizado las actividades previstas, encuentran más errores los usuarios (ya sea durante el UAT o directamente en producción) que los propios testers (que incluso a veces no hallan ninguno). Y mirando hacia adentro, cuando trabajamos con los equipos de testing, muchas veces preguntamos por el plan de pruebas y nos entregan los casos de prueba, otras veces los casos de prueba diseñados consideran solamente el requerimiento en forma literal y no incluyen pruebas en base el contexto en el cual existe ese requerimiento (ya sea casos E2E, de regresión, bordes, variantes del escenario, etc.); o incluso pasa que para una prueba simple se diseñan muchos casos de prueba (con más variantes o combinaciones que las que las buenas prácticas sugieren) y para situaciones complejas y críticas se diseñan pocos casos (olvidando combinar técnicas para abordar con mayor profundidad la prueba en virtud de la criticidad de la misma).

Todo esto nos lleva a que necesitamos hacer un alto en los hábitos mecánicos que se fueron generando a lo largo de los años de practicar el testing, en base a los que casi de forma automática recibimos el pedido, diseñamos los casos y ejecutamos para poder pensar, entender y planificar y así lograr un cambio en los resultados. Para lograr este cambio, este “pensar”, vamos a utilizar dos herramientas, el Pensamiento Visual y Design Thinking.

Desaprender lo aprendido

Dado que el 80% de nuestro cerebro está diseñado para asimilar y procesar imágenes, ver dibujos supone menos esfuerzo que leer un texto. Además, por lo mismo, recordamos las imágenes por más tiempo.
Por otro lado, tenemos el Design Thinking, o Pensamiento de Diseño, como un modo de resolver problemas que se aplica tanto a productos como servicios,que permite aproximarnos a las ideas de una forma distinta a las exploradas desde el pensamiento lógico tradicional, mediante un proceso no lineal. Coloca herramientas que eran propias de los diseñadores, en manos de gente que nunca se vio a sí misma como diseñador y las aplica a un rango de problemas mucho más amplio.

El proceso de Design Thinking tiene distintas actividades (Investigar, Empatizar, Definir, Idear, Prototipar y Testear), algunas de las cuales son divergentes (generamos muchas ideas) y otras convergentes (donde reducimos a una). Se basa en principios como el trabajo colaborativo, centrarse en los seres humanos, convertir el prototipado en una disciplina (donde se repite el ciclo de Crear – Compartir para recibir feedback – Reflejar los cambios), y la tolerancia al fracaso (ya que el armar prototipos para tener feedback rápido del cliente, conlleva también que recibamos muchos “no” y tengamos que volver hacia atrás en el proceso para recolectar más información, o explorar nuevas ideas).

Entonces, vamos a usar el proceso de Design Thinking aplicándolo al testing, utilizando técnicas visuales siempre que sea posible, para lograr una mayor comprensión de lo que necesitamos probar en un tiempo reducido, involucrando a los distintos participantes, logrando una visión compartida y validada al mismo tiempo.

Un ejemplo es utilizar el Design Thinking para el testing para construir estrategiasde prueba:

Empatizar: Utilizando Personas, Mapa de actores, Perfil de cliente.
Definir: Priorización del mapa de valor y Matriz de Riesgos.
Idear: Matriz de puntos de contacto, Customer Journey, Matriz de Riesgos asociada a los elementos de las matrices anteriores.
Prototipar: Consiste en construir un documento simple que vuelque la estrategia definida en base a la información recolectada en las etapas previas.
Validar: Revisando los elementos visuales construidos con los distintos stakeholders.

La matriz de riesgos, una vez definida, pasa a formar parte de la estrategia, sin embargo, es importante construirla con referentes del negocio que puedan aportar la visión de impacto al negocio por cada uno de los elementos a evaluar (puntos de contacto, plataformas, etc) y referentes técnicos que puedan aportar la probabilidad o riesgo técnico (cuán probable es que haya un error en función de características que afectan al software, como un equipo desarrollador nuevo, inexperto, tecnologías nuevas, cambios frecuentes, etc).

A modo de resumen, podemos aplicar Design Thinking en las siguientes actividades del testing:

– Estrategias de pruebas.
– Diseñar Pruebas de Sistema.
– Preparar Pruebas UAT.
– Entender escenarios para pruebas técnicas.

Durante el testing ágil, acompañando las distintas actividades propias del equipo, así como para armar la estrategia, plan y diseño de casos de prueba.
Las técnicas las podemos aplicar organizando talleres de 2 a 3 horas para lo que debemos:

– Definir el objetivo.
– Identificar a los participantes (que puedan aportar/construir la información que necesitamos).
– Elegir las técnicas a aplicar (en cada sesión se aplican entre 1 y 3 técnicas) .
– Realizar el taller .
– Extraer conclusiones (que podamos aplicar al testing, y/lo identificar puntos que requieren mayor detalle) En nuestra experiencia, trabajar con un moderador que conozca en profundidad.

Design Thinking y métodos visuales funcionan muy bien, ya que aportan conocimientos y experiencias complementarias al equipo, ayudan a generar y plasmar las ideas y pueden intercambiar o adaptar técnicas en función de la dinámica con el equipo.