Relytest: Entrevista sobre testing exploratorio a Diego Gawenda

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 participé 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 Diego Gawenda.

Contacto de Diego con el testing exploratorio

En sus estudios de testing ha trabajado con sesiones y utilizado la herramienta de James Bach para gestión de las mismas. Sin embargo, a nivel laboral aplica el testing exploratorio de manera ad-hoc. Considera el testing exploratorio una herramienta útil, que permite descubrir en el software problemas diferentes a los que se encuentran con el testing planificado.

Contexto, ciclos de desarrollo

Los ciclos de desarrollo en los que ha trabajado aplicando testing exploratorio son iterativo incremental, con iteraciones lo más cortas posibles, y ahora con un enfoque de gestión más bien ágil, donde incluyen automatización.

¿Cómo realiza el testing exploratorio de manera ad-hoc?

Se basa en un objetivo particular que le interesa explorar y va registrando los problemas que surgen. Establece para ese objetivo el tiempo que le dedicará. No los reporta durante el tiempo dedicado a esa actividad sino que eso lo hace luego. Respecto a las sesiones planteadas según Bach no lleva las métricas allí propuestas.

En su trabajo, tienen como premisa solo reportar los bugs que son replicables. Si no lo puede replicar directamente no lo reporta.

¿Cómo planifica el trabajo a realizar con enfoque de testing exploratorio?

Primero que nada analiza todo lo que se necesita probar. Luego asigna un tester, un tiempo y un objetivo.

Si lo que va a realizar es una verificación de un ticket mediante testing exploratorio, le dedican en general unos 20min. El resto del tiempo explora los alrededores de lo que se arregló para ver que no se haya roto nada.

Otra ventaja del testing exploratorio, que destaca Diego, es que les permite proponer oportunidades de mejoras (features).

Nos comenta que al pensar en un equipo de testers o en delegar trabajo entonces se hace necesario contar con sesiones, que es un método más estructurado de realizar el testing exploratorio, para poder gestionar adecuadamente las pruebas.

Como parte de su metodología de trabajo catalogan los bugs de acuerdo al enfoque con el que lo descubren ya sea testing exploratorio o scripts. Les resulta muy fructífero el testing exploratorio, ya sea comparando con testing mediante scripts o pruebas automáticas, la relación de problemas encontrados respecto del tiempo dedicado es mayor en el caso de testing exploratorio. En promedio la relación en base al tiempo dedicado suele ser de 4 a 1. Es decir, en 1 hora de testing exploratorio se encuentran 4 bugs o mejoras mientras que en el mismo tiempo 1 solo bug o mejora para el testing estructurado.

La estrategia que aplican en general es primero cubrir todas las otras pruebas, y luego el tiempo que “sobra” es el que se dedica a realizar testing exploratorio.

¿De qué modo realiza el testing exploratorio?

Realiza las capturas en el momento que detecta un incidente, va anotando en un block de notas (lápiz y papel). El tiempo de reporte cae fuera del tiempo asignado para el objetivo planteado. De este modo se asegura que no se desvía demasiado del objetivo que se desea probar.

¿Cómo definen las misiones?

En general, las misiones se hacen por funcionalidad. Es decir una misión consiste en probar una determinada funcionalidad. Salvo que sean funcionalidades demasiado pequeñas, en ese caso consideran varias funcionalidades en una misma misión.

¿Qué tiempo le dedica normalmente a una sesión de testing exploratorio?

En general, le dedica a cada prueba exploratoria unas 2hs, incluyendo las interrupciones. Por las características de su trabajo le resulta imposible realizar las pruebas sin atender las interrupciones, por lo cual considera éstas a la hora de planificar el trabajo que va a realizar. Las interrupciones típicas que debe atender durante las pruebas son llamadas telefónicas y el correo electrónico.

Algunas sugerencias para incluir en Relytest

Preguntas al final: ¿Necesitarías más sesiones para cubrir el objetivo? ¿Cuántas? 1, 2, 3…
Incluir ayuda en la navegación, por ejemplo, mediante tooltips, de forma que el usuario no se sienta tan perdido al enfrentarse a la aplicación por primera vez.

También propone que se brinden un par de tips sobre el uso de la herramienta al abrir la misma. Diego participó en la meet up de testing donde tuvo oportunidad de probar una de las primeras versiones de Relytest, y en dicha oportunidad no le resultó muy intuitiva la herramienta.

¿Tuviste que “vender ” el testing exploratorio para poder realizarlo?

No, no es necesario, el tiempo dedicado a testing exploratorio se justifica solo con la cantidad de bugs encontrados.

¿Qué ventajas y desventajas encontrás a la hora de implementar sesiones de testing exploratorio?

Entre las ventajas destaca Diego que es una forma estructurada de probar. Luego, entre las desventajas, a la hora de implementar, nos enfrentamos a la dificultad de que los testers no están acostumbrados a escribir sesiones.

Sería bueno incorporar esta forma estructurada de probar como parte del proceso de pruebas. Y de este modo analizando las sesiones y con los reportes de métricas se evidenciarían las frutos del testing exploratorio. Para todo esto, es vital que se prioricen las pruebas exploratorias adecuadamente desde la gerencia y baje la línea.

Es más difícil de documentar el testing exploratorio cuando se solicita a alguien de fuera del área de calidad que lo realice. En general, suele ser más ad-hoc aún.

¿Quién es Diego Gawenda?

Soy muy afortunado de hacer lo que realmente me apasiona hacer, aseguramiento de calidad. Esta es un área increíble dentro de toda organización. Todos los procesos, su definición y revisión pasan a través de QA y estoy interesado en expandir esta cultura a todo el equipo. Por otra parte, soy un emprendedor entusiasta que busca todo el tiempo nuevos desafíos. Como ingeniero en computación de la UdelaR estoy continuamente poniendo en práctica mis habilidades técnicas, explorando problemas en distintos ambientes para encontrar nuevas soluciones aprovechando mis conocimientos tecnológicos. En la interacción con clientes tengo una perspectiva de negocios diferente la cual constituye la principal clave para lograr el éxito de los proyectos. Durante mi experiencia laboral en distintos ámbitos he pasado por diversos roles que me han enriquecido en múltiples aspectos. Extrapolando esta experiencia a la distintas estrategias de testing, es donde encuentro el valor de complementarlas, porque el testing exploratorio es igual de importante que el testing estructurado. Asimismo la exploración de una aplicación potencia la creatividad de la persona que está desarrollando la actividad. Este es un valor agregado que se puede transformar en motivación para muchos equipos de trabajo.