Testing exploratorio

Si vamos a planificar un viaje a una ciudad que no conocemos, tenemos dos formas:

• compramos un mapa y una guía y hacemos un plan de lo que queremos visitar
• o bien compramos el mapa y la guía y los vamos leyendo en el lugar.

Cuando planificamos tenemos que dedicar tiempo a planificar, pero es más fácil luego compartir el plan con un amigo para que haga otra vez lo mismo, y sabemos decirle cuánto tiempo le llevaría.

En la segunda opción, uno va viendo y va resolviendo en el camino. Lo bueno es que no tenemos que dedicar tiempo a planificar, sino que planificamos y exploramos al mismo tiempo.

Básicamente el testing exploratorio es EJECUCIÓN y DISEÑO de las pruebas al mismo tiempo. ¡¡No se escriben casos de prueba!!

Esto es ideal para cuando vamos a probar un sistema que no conocemos, o que no tenemos mucho tiempo, o que no hay mucha documentación como para ir pensando las pruebas de antemano.

Las pruebas las hacemos en “sesiones”, que son bloques de tiempo de unos 40 minutos, una hora, hora y media, a veces más, pero es importante que sea ININTERRUMPIDO. Por esto es que no deberían ser nunca de más de 2 horas.

Vamos a ver algunas de las cosas que tenemos que registrar para una sesión:

• Misión: en lugar de tener un caso de prueba que me dice paso por paso lo que tengo que hacer, acá vamos a tener misiones, como en los juegos de computadora que tenemos que conseguir ciertos elementos, tantas monedas de oro, etc., o como un explorador que tiene que recorrer cierto lugar y encontrar el Cáliz de Oro cual Indiana Jones. Si lo asociamos con el viaje a la ciudad podríamos poner como misiones:
  • recorrer todas las plazas de la ciudad
  • ir de la playa más al norte a la playa más al sur

Si lo pensamos en el sistema del Carrito Nahual:

• • ver si un usuario nuevo puede comprar en el carrito
  • intentar comprar con variedad de productos
  • revisar las restricciones de edad para ciertos productos
• Áreas: Contiene la información sobre el cubrimiento de las áreas funcionales, las plataformas, datos, operaciones, y también, técnicas de testing a usar para el modelado de la aplicación o sistema bajo prueba.
• Tester: debemos registrar qué tester ejecuta cada sesión.
• Tiempo de inicio y fin
• Duración
  • corta, media, larga. Es importante que sea ininterrumpida, así que nunca deberían ser más de 2 hs, por más que sea la larga, ya que nos van a dar ganas de ir al baño, o ¡revisar Facebook!
  • entonces, esta duración se establece antes de comenzar, y deberíamos respetarla.
• Archivos: si se requiere algún archivo, se registra cuáles se usaron.
• Métricas de tiempo, o sea, datos numéricos, que nos dan información de cómo fue nuestra prueba. En particular se suele tomar nota de lo siguiente:
  • % de tiempo ejecutando y diseñando
  • % de tiempo reportando bugs
  • % de tiempo preparando la prueba
• Métricas de misión versus oportunidad, o sea, registrar cuánto tiempo estuvimos concentrados en la misión y cuánto tiempo nos fuimos por las ramas.
• Errores: se toman nota de los errores, sugerencias de mejora, cosas que no se entienden y luego habrá que discutirlas con alguien para ver si están bien o no, etc.
• Notas de prueba: la idea es que uno debería ir anotando todas las cosas que hizo, así luego cualquiera puede analizar qué cosas se probaron y qué cosas no.
• Inconvenientes: Inconvenientes o impedimento que haya surgido quitando tiempo a la sesión y la concreción de su objetivo.

Tal como cuando uno explora una ciudad, uno tal vez tiene una misión en la cabeza, va haciendo un recorrido que pensó hacer, pero en ciertos lugares le llama la atención algo y se desvía. En el testing exploratorio nos podemos desviar de nuestra misión si vemos algo que tal vez pueda descubrir un error, o algo nuevo, o algo que llamó la atención, pero es muy importante siempre volver a la misión principal, estar solo de a ratos yéndonos por las ramas, y siempre volver a nuestro objetivo.