Relytest: Entrevista sobre testing exploratorio en Baufest

Este post fue escrito por Gabriela Sánchez y Miguel Sánchez como parte de su investigación en testing exploratorio en su proyecto de grado en ORT, donde yo participo como cliente, ayudando a definir actividades y necesidades en torno a los aspectos metodológicos, incluyendo el prototipo de una herramienta que le de soporte (llamada Relytest). En ese contexto, Gabriela y Miguel entrevistaron a Nadia Cavalleri y Cecilia Briozzo para ver cómo hacen testing exploratorio en Baufest.

---

En esta oportunidad cruzamos las fronteras, y nos fuimos al otro lado del charco, para entrevistar a Nadia Cavalleri y Cecilia Briozzo, cuyo contacto surgió gracias al evento de TestingUY llevado a cabo en abril de este año.
Realizamos una entrevista conjunta con Nadia y Cecilia, ambas trabajan en Baufest. Nos cuentan que las pruebas en su caso están muy orientadas al contexto y que en función de éste deciden qué técnicas aplicar. El testing exploratorio no es una práctica muy difundida, sin embargo, ambas han tenido distintas experiencias poniéndolo en práctica y comparten con nosotros como les ha resultado hasta ahora.

Experiencia de Nadia con el Testing Exploratorio en Baufest

¿Está suficientemente difundido el testing exploratorio?

Nadia entiende que no y que una de las razones por la que no está tan difundido tiene que ver con los clientes, y que este enfoque no les da tanta confianza como el testing planificado, basado en el viejo y querido caso de prueba. Aún, cuando existan numerosos casos de prueba sin ejecutar sigue resultando más confiable a los clientes.

La elección del enfoque de pruebas no tiene tanto que ver con la tecnología o plataforma del sistema a probar sino que está más asociada a las exigencias documentales que tiene el cliente, la cantidad y el seniority de los testers, el conocimiento que se tiene del sistema a testear y su complejidad, entre otros factores. Lo que sucede es que si el cliente se pone muy rigurosos con los entregables o los testers son muy juniors, es dificil introducir el testing exploratorio.

Hasta ahora en Baufest usaban Testlink para la gestión de los casos de prueba a menos que el cliente requiriera otra herramienta. A medida que los proyectos se volvieron más complejos y se necesitaron métricas más detalladas, comenzaron a evaluar otras herramientas. Hoy en día la decisión es utilizar Microsoft Test Manager y empezar a explotar sus facilidades para hacer pruebas exploratorias.

El testing exploratorio puesto en práctica

Comienza Nadia contándonos sobre su experiencia al utilizar esta metodología en sus procesos de prueba. Acompaña bastante el testing exploratorio con técnicas de mindmapping, primero explora la aplicación para representarla a alto nivel y con pocas palabras en un mapa. Luego avanza en el mapa con algún criterio determinado, ya sea riesgo, prioridad, conocimiento, etc. El criterio lo elige dependiendo del proyecto en el que está trabajando.

Luego para cada funcionalidad define sesiones, las cuales realiza sin interrupciones y muy concentrada en lo que va haciendo. Mientras prueba no se centra en los impedimentos, sino que toma nota de éstos y los deja para después. Para reflejar el estado en el que se encuentra el testing de cada una de las funcionalidades utiliza colores de modo tal que visualmente sea fácil de ver el avance y el estado general de las pruebas. Una vez que finaliza la sesión le quedan las notas y el mapa mental que fue construyendo durante la misma. En general, dedica unos 40-45 min a cada sesión. Si estima que le va a llevar más tiempo, divide las funcionalidades a probar en módulos más pequeños para que le quede algo que pueda probar en 45min, que es el tiempo que puede permanecer sin interrupciones.

El uso de mapas mentales le permite clonarlos y reutilizarlos con distintos navegadores por ejemplo.

Aquí un pequeño ejemplo de un mapa mental que nos aportó Nadia:

Cada color significa algo en particular que el tester quiera representar: probando, a probar, bloqueado o requiere una segunda vuelta, etc. Se puede ver en la imagen que algunas funcionalidades al lado tienen un iconito que son las notas de la sesión. El árbol lo va construyendo a medida que va explorando. Algunas cosas ya están desde antes por algún conocimiento previo que pueda tener sobre la aplicación.

Las métricas

Nos comenta Nadia que le resulta sumamente difícil obtener métricas fidedignas al momento de hacer pruebas exploratorias. Por ende, generalmente utiliza el testing exploratorio en aquellos proyectos donde los clientes tienen pocas exigencias respecto a documentación que se les debe entregar.

La información que le resulta importante conocer a partir de las sesiones ejecutadas es cuántos y cuáles fueron los escenarios recorridos para determinada funcionalidad, el resultado de esos escenarios y el tiempo insumido en probar cada uno. Además, le interesa conocer los bugs y/o las mejoras que se fueron reportado en relación a lo anterior.

Estima que actualmente realiza un 30% de las pruebas con enfoque de pruebas exploratorias y el resto lo hace con un enfoque planificado. Si bien venía leyendo sobre este tema, la terminó de convencer la el taller que Federico dio sobre testing exploratorio en TestingUY (Taller de testing exploratorio).

¿Qué dificultades has encontrado en el testing exploratorio?

Una de las principales dificultades que encontró es que el aprendizaje que se produce sobre la aplicación es personal. Entonces se plantea el interrogante de cómo hacer para compartirlo con otra persona, cómo transferirlo a alguien nuevo que se incorpora en el proyecto por ejemplo.

Como se mencionó previamente, otro obstáculo con el que se encontró fue la dificultad para obtener métricas En relación a este punto comentó que la mayoría de las herramientas no vienen preparadas para este enfoque. Hay algunos plugins de Jira o funcionalidades de Microsoft Test Manager que se aproximan pero aún así dejan sabor a poco.

Finalmente, le resulta dificil pensar en un equipo grande de testing que trabaje con este enfoque ya que deberían estar todos muy coordinados, con mucha confianza en los miembros y un gran apoyo a los juniors.

Experiencia de Cecilia con el Testing Exploratorio en Baufest

En contraposición con Nadia, Cecilia realiza un testing exploratorio más informal. Ella trabaja generalmente en proyectos de mantenimiento, donde el desarrollo ya finalizó y se incorpora cuando ya existe un plan de mantenimiento. Muchas veces estos proyectos tienen documentación funcional incompleta o inexistente.

Por ejemplo, nos cuenta que ahora está trabajando en un proyecto en aplicaciones móviles, en el que está aplicando testing exploratorio para conocer la aplicación y hacer una regresión de la misma. Nos cuenta que el cliente es un proveedor de energía eléctrica, y el objetivo de la aplicación es que el usuario pueda realizar distintas gestiones desde su teléfono celular, por ejemplo: consultar sus facturas, realizar reclamos, solicitar servicios adicionales, etc. En el mismo existen algunos problemas relacionados a la conectividad del dispositivo (cuando el equipo tiene conectividad baja o nula).

Utiliza el testing exploratorio como primera aproximación a la aplicación, obtiene una primera impresión y puede dar feedback sobre la misma.

Cecilia es partidaria de que el tester informe lo que probó, ya sea que haya dado bien o mal. También le parece vital registrar, para no volver a probar lo mismo.

Su primer registro lo realizó en planilla de cálculo. A pesar de eso, la idea de construir un mapa está presente de algún modo al ir registrando lo que ha explorado en la aplicación.

Todos los problemas que identifica los categoriza en una de estas tres categorías: mejora, duda e incidente. Duda hace referencia a aquello que le parece que está mal pero le surge la duda si está definido así a propósito. Todo lo que clasifica como duda le queda pendiente para revisar con el equipo de desarrollo cómo debería comportarse la aplicación en ese caso.

El testing exploratorio puesto en práctica

El primer día que puso en práctica el testing exploratorio comenzó registrando en una planilla de cálculo, anotando lo que iba haciendo e identificando en las filas temporalmente lo que va haciendo. Luego agrega las capturas de pantalla en medio de las notas para que quede ordenado cronológicamente.

Luego, al compartirlo con el equipo tuvo muy buen feedback, ¡al equipo le encantó! Tenían la historia completa de lo que fue probando y recorriendo durante su ejecución. A medida que se le ocurrían ideas lo iba anotando en un documento aparte, para tener en cuenta en las próximas ejecuciones y realizar esas pruebas o recorrer esas áreas que iba dejando anotadas.

Dificultades encontradas

A medida que pasaban los días le fueron surgiendo diversas dificultades con esta forma de registro. Nos comenta: “Es muy difícil ir registrando por donde voy explorando la aplicación en la planilla de cálculo. Con varias sesiones es medio lío.” Al tercer día, quería saber por dónde había navegado durante las sesiones anteriores y no tenía esa información de manera sencilla y clara. Encontró entonces un workaround a esta situación, lo resolvió agregando en la planilla de cálculo los nodos de un mapa (los iconos del menú de la aplicación) así de este modo podía tener información de la cobertura. Si bien, no tiene la visión del producto entero, puede decir cuánto recorrió.

Sin embargo, no fue la única dificultad que debió enfrentar registrando en una planilla de cálculo, sino que surgieron algunos otros desafíos como saber si había testeado con conectividad o sin conectividad o identificar sobre qué versión del producto había probado. En particular en el proyecto que estaba trabajando, era frecuente probar un día en una versión, al día siguiente en otra y así sucesivamente. La velocidad de desarrollo de las aplicaciones mobile es muy rápida.

Por otro lado, Cecilia optó por que la sesión dure lo que sea necesario para completar el objetivo. A diferencia de Nadia, el contexto de trabajo de Cecilia hace que sea muy difícil disponer de un período de tiempo sin interrupciones (trabaja desde su casa, madre de dos niñas pequeñas, está compartida en varios proyectos, tiene otros roles dentro de Baufest como ser Administradora de TestLink). Ello hizo que fuera necesario para Cecilia poder interrumpir la prueba en cualquier momento y poder retomarla desde donde había dejado. Sin embargo, coincide con Nadia en que los objetivos deben ser lo más puntuales identificando claramente el alcance del mismo. Y agrega que se puedan probar en el día. En el contexto de esta aplicación mobile, algunos objetivos de las sesiones de testing exploratorio fueron: “registrarme como nuevo usuario con buena conectividad y con mala conectividad”, “visualizar mi factura”, “generar un trámite de tipo cambio de titularidad”, por ejemplo.

¿Qué impresión te dejó realizar pruebas exploratorias más allá de las dificultades que tuviste que enfrentar?

Cecilia nos cuenta que este enfoque sirve para familiarizarse con el producto y tener una primer percepción de calidad. Al ser usuario-tester resulta muy apropiado el enfoque. La considera una técnica con mucho potencial y que se podría utilizar más en testing de regresión.

Destaca que es sumamente importante que el líder de proyecto esté entusiasmado con la idea de usar testing exploratorio. Y en ese marco lo ve muy prometedor para realizar en proyectos avanzados, donde el tester se incorpora tarde y no hay generalmente documentación disponible. Considera además que es un enfoque muy adecuado para realizar pruebas de regresión.

Finalmente, con respecto a las métricas, nos comenta Cecilia, que en su caso lo más importante es poder decir al otro día qué ya se probó para poder seleccionar un escenario nuevo para probar.

¿Qué le gustaría de una herramienta que asista el testing exploratorio?

Le gustaría que sea parecido a las herramientas de record and play, pero no que haga un video, sino que sea una herramienta inteligente que construya el mapa con el recorrido que realizó en la aplicación.

Una herramienta que asista inteligentemente en la registración de la prueba. Entiende que interrumpir para escribir lo que está haciendo corta la concentración. Encontrar algo sospechoso, atenta a no dejar de registrar nada y entender qué le pasa al producto. Doble preocupacion. “Ah lo encontré, pero ¿¿cómo fue que llegue hasta acá??.” Le gustaría un registro inteligente de por dónde uno pasó, podría armar un árbol a partir de los puntos (menues y botones) que el tester fue ejecutando de la aplicación, que se pueda agregar menciones, notas, que pueda tomar print screens y dejarlos asociados a cada paso o al path que se está recorriendo y que uno pueda registrar el issue on the fly en el momento que lo encuentra. Detalles de contexto, como por ejemplo si está o no con conexión, que resulta muy relevante en pruebas en aplicaciones móviles (condiciones del ambiente), características del tipo de cliente al que entró a ver las facturas (condiciones de los datos de las pruebas). Llevar un registro de los distintos escenarios. Esos escenarios no los tiene pensados de antemano sino que van surgiendo en el momento en que uno recorre la app.

¿Qué es lo más importante del testing exploratorio?

Lo más importante es tener un objetivo claro, sino puede resultar contraproducente, al querer ir por todos lados a la vez. Para ello es necesario tener autocontrol para terminar la sesión que se propuso: “Si voy por acá, no voy a terminar lo que me propuse hacer. Mejor me lo anoto como idea para otra sesión.” En resumen, nos comenta Cecilia, el core de la metodología es tener un objetivo concreto para cada sesión.

 

En este post les compartimos dos experiencias distintas de aplicación de testing exploratorio, ambos enfoques muy interesantes, poniendo en evidencia tanto las virtudes del testing exploratorio como las dificultades que involucra la puesta en práctica del mismo. La necesidad de contar con una metodología y una herramienta que facilite esta técnica.

 

Nadia Cavalleri

Nadia Cavalleri es ingeniera en sistemas de información (UTN) y psicóloga (UADE). Está certificada en Rational Functional Tester. Actualmente lidera proyectos de operaciones y calidad en Baufest donde trabaja desde hace más de 10 años. También trabaja en salud mental y hace colaboraciones docentes en UTN-FRBA y otras instituciones educativas. En 2014 y 2016, fue jueza sudamericana del mundial de testing. En 2015 fue oradora en QA&Test (España) y en 2016 en TestingUY (Uruguay).

Cecilia Briozzo

Cecilia Briozzo tiene más de 15 años trabajando en Sistemas. Pasó por casi todos los roles, desde analista funcional, programadora, tester y líder de equipo. Actualmente está realizando actividades de Testing y QA funcional en la consultora internacional Baufest. Ella se encuentra en Vaqueros, provincia de Salta donde formó su familia y se conecta de forma remota a los recursos necesarios a través de internet utilizando un canal seguro (VPN) cuando es necesario. Adora hacer testing y siempre está buscando la forma de mejorar los procesos y actividades que realiza y la calidad de los productos entregados. Considera que la calidad se logra entre todos y le gusta trabajar en equipo. Está siempre atenta a desarrollar sus habilidades de liderazgo u otros aspectos relacionados a la disciplina de Testing que es la que más le apasiona.

 

Links a otras entrevistas y a más información del proyecto:

• http://blog.abstracta.com.uy/search/label/RelyTest