¿Cómo hace testing exploratorio la comunidad de testers de Uruguay? Entrevista #1

Resulta muy enriquecedor ver cómo otras personas realizan las pruebas exploratorias y las diferencias que hay entre uno y otro a la hora de llevar a la práctica este enfoque. ¿Qué elementos le resultan más importantes? ¿Qué registrar y qué no? Podemos encontrar algunas respuestas a éstas y otras preguntas que generalmente nos hacemos al enfrentarnos a las pruebas exploratorias. Por esto comenzaremos con una serie de posts en los que entrevistamos a distintos testers con experiencia en testing exploratorio, para de esa forma entender mejor las dificultades y necesidades de aplicar este enfoque. Queremos así poder compartir contigo los principales desafíos y aprendizajes de cada uno, así como también aprovechar a obtener más y mejor guía a la hora de diseñar Relytest (te dejamos este link donde hablamos del proyecto de construir esta herramienta opensource).

En esta primera oportunidad, te compartimos la experiencia de Iván Serrano, quien ha pasado por distintas empresas y proyectos, probando aplicaciones para start-ups hasta para grandes corporaciones. Iván ahora está más enfocado en el testing automatizado, pero cuenta con varios años de experiencia en testing exploratorio.

¿En qué oportunidades es recomendable utilizar el testing exploratorio?

Una de las dos situaciones en las que resulta sumamente útil el testing exploratorio, es cuando desconocemos un producto y queremos ver de qué se trata por primera vez. ¿Qué hace? ¿Qué es todo lo que puedo hacer? ¿De qué modo lo hace? Esta es una de las dos situaciones que destaca Iván, en general, cuando vamos a probar un producto por primera vez, ya sea una aplicación de escritorio, página Web o aplicación móvil, realizamos un primer acercamiento a sus funcionalidades mediante testing exploratorio. Este acercamiento puede resultar algo diferente de otras exploraciones en las cuales ya conocemos bien el producto. Es así que nos surgen muchas dudas que luego se traducen en preguntas al cliente para tratar de comprender qué es lo que debería hacer el producto y de qué modo.

Comencemos por el principio

Iván realiza testing exploratorio basado en sesiones. Lo primero que él hace es definir las misiones, si estas no vienen definidas por le líder de Testing. Lo hace con un enfoque basado en riesgos y decide el largo de cada sesión en función del conocimiento que tiene de la aplicación. Si tiene conocimiento dedica, en general, unos 15 minutos, ya que las sesiones son bien específicas. Cuando no tiene conocimiento estima unos 60 minutos.

A la hora de ejecutar

Al momento de la ejecución, cierra la casilla de correo, apaga todas las notificaciones y comienza a correr el cronómetro. Ivan destaca que ¡es muy importante que el cronómetro esté visible siempre! Además, comenta que mejor que no tenga sonido, ya que el sonido distrae, y que avance hacia adelante, no hacia atrás. También destaca la importancia de poder poner pausa en el cronómetro, si bien entendemos que la sesión constituye la ejecución de un objetivo en una unidad de tiempo ininterrumpida, debemos tener la flexibilidad suficiente para considerar eventos que impliquen una breve interrupción, como por ejemplo, ir al baño :P

Lo primero es completar las áreas, las cuales incluyen la siguiente información: el ambiente, la plataforma y las estrategia. En su caso utiliza un enfoque basado en riesgos, además incluye la investigación y reporte de incidentes realizando exploración y observación.

Las observaciones en las notas le sirven luego, entre otros, para derivar nuevas misiones.

¿Qué hacemos cuando no sabemos cómo seguir?

A veces sucede que comienza a ejecutar una misión y descubre que hay pasos intermedios de los que no tiene conocimiento cómo funciona la aplicación, o que debe realizar ciertas acciones con anterioridad para poder ejecutar esa misión. En ese caso, interrumpe la misión detallando las razones de dicha interrupción y dando por terminada esa instancia. Luego de investigar lo que desconoce o realizar los pasos previos retoma esa misión de cero.

Métricas de las sesiones

Al final completa las métricas propuestas por los hermanos Bach. Trata de balancear misión y oportunidad. Una sesión donde la oportunidad sea mayor al 60% carece de sentido. Es necesario renombrar esa misión con lo que realmente se ejecutó.

Completa también la sección archivos, donde incluye toda la información analizada previamente como ser documentación existente, especificaciones, manuales, etc. Toda esta información constituye además un input para la redacción de las misiones. Incluso define datos de prueba, los cuales incluye luego en esta sección.

¿Y las notas?

La pregunta del millón: ¿Qué poner en las notas? Esta es una dificultad frecuente, más aún, en los que recién comienzan a realizar testing exploratorio. Bueno, Iván nos cuenta que él va registrando los pasos que va realizando y los pensamientos que le van surgiendo. Entiende que las notas se deben escribir siempre en primera persona. Y de éstas derivan luego manuales de uso de la aplicación, información para otros testers, y especificación de casos de uso entre otros. Además, nos muestra su forma de registro, no lo va haciendo continuamente, sino que cada aproximadamente 3 minutos, que es lo que puede recordar sin mayores dificultades, pasa al formulario de registro a completar todo lo que hizo en ese tiempo, sus pensamientos, etc.

En la sección de defectos registra el ID del incidente reportado en la herramienta de gestión que corresponda. Luego, en la sección de inconvenientes, nos da algunos ejemplos de qué registrar: “se cortó internet”, “me llaman a una reunión”, etc.

Nos comenta, además, lo interesante que sería que la herramienta permitiera taggear las notas para poder identificar fácilmente de qué estamos hablando.

Respecto a la captura de imágenes durante la sesión, la realiza únicamente al detectar incidentes. La edición de las imágenes, si bien lleva tiempo, es parte de la sesión, por lo que debe realizarse durante la misma. Respecto a la utilidad de incluir videos, nos comenta que le puede resultar interesante sólo cuando los pasos para reproducir y las capturas de pantalla no resultan suficientes. También indagamos sobre la utilidad de realizar el registro mediante audio, pero él nos desaconseja esta opción debido a la dificultad y el tiempo que lleva su análisis posterior.

¿Cómo se sigue después que terminamos la sesión?

Luego, sobre el final nos comenta dos aspectos que nos resultan sumamente interesantes. El primero va de la mano con la propuesta de debriefing de James Bach, o sea, el análisis posterior de las notas. Este análisis debería ser realizado por la misma persona que tomó las notas. En su operativa, él realiza el análisis y como resultado elabora un resumen de las notas. El objetivo del resumen es facilitar la información recolectada para su posterior utilización ya sea en la redacción de manuales, trasmisión de conocimientos adquiridos a otros testers, etc. El segundo es la inclusión de dos o tres preguntas que permitan recoger la experiencia del tester en lo referente a usabilidad y experiencia de usuario. Por ejemplo,¿qué te pareció la navegabilidad?

RelyTest, consideraciones para la herramienta

Gracias al apoyo de Iván hemos considerado muchos de estos aspectos en nuestros primeros prototipos. Hoy en día, RelyTest ya incluye las siguientes funcionalidades:

• Cronómetro:
• Hacia adelante.
• Sin sonido.
• Con posibilidad de pausarlo.
• Notas taggeadas.
• Capturas de pantalla, se salvan automáticamente las imágenes dando la opción configurable de abrir el editor por defecto cada vez que se toma una imagen. De este modo se puede editar rápidamente la imagen en el momento.

Otro de los objetivos del proyecto: la metodología

En lo que se refiere a la metodología, aún en investigación, se considera fundamental el registro del análisis realizado por la persona que ejecuta la sesión, o sea, el resumen de la misma. Siendo el resultado de éste lo que enriquece el conocimiento adquirido del producto ya sea para uno mismo en próximas ejecuciones, trasmisión de conocimientos entre miembros del equipo o para una integración más eficiente de nuevos integrantes al equipo.

El Testing y la Calidad

Ya para cerrar Iván nos comparte su concepto y reflexión sobre la calidad y testing: “Cada persona en su naturaleza tiene una capacidad crítica, única, su propia espontaneidad, una forma de ver las cosas, más allá de las convenciones necesarias para coexistir con el entorno. Creo que el testing como actividad, debe siempre intentar que esa naturaleza no se reprima. El testing exploratorio, dentro de las actividades de testing, es el enfoque que más conserva dicha naturaleza, por lo que todo lo que derive de él, siendo sistematizado y ordenado de manera correcta, no es más que un conjunto de riquísimos aportes a la hora de garantizar la calidad de algo, ya sea un producto derivado de la tecnología de la información, o yendo más allá aún, como las cosas más comunes y cotidianas de la vida. La búsqueda de la calidad la entiendo como aquella búsqueda que enriquezca de la mejor manera y más equitativamente posible al conjunto de personas que la van a ser beneficiados por la misma.”

¿Quién es Iván Serrano?

Entré al mundo de la informática por el lado del diseño gráfico. Conocí la actividad invitado por Cesar Ganduglia en Celta Consulting, quien me invitó a capacitarme y realizar mis primeras incursiones en el Testing, trabajando para Volt Uruguay (Páginas Amarillas). Luego realicé un impasse en el área tecnológica para dedicarme al área social como Educador Social, estudiando para ello y realizando varios cursos especializados en violencia doméstica y primera infancia. Retorné al mundo de la informática trabajando para Globant, recomendado por un amigo, Germán Bernardez. Allí trabajé para diversos proyectos como K12, Tenaris, Southwest Airlines, BBVA API Marketplace entre otros. En estos proyectos apliqué siempre que pude el testing exploratorio como enfoque y enriquecimiento de pruebas. Trabajando en Globant conocí a Andrés Curcio, de quien aprendí mucho sobre testing y fundamentalmente de testing exploratorio. Actualmente me desempeño en Abstracta como QA, trabajando para proyectos como Stampr, Worscom y Verifone, donde también he podido utilizar el testing exploratorio como parte fundamental del enriquecimiento de las diversas actividades que atañan al Testing.


¡¡Muchas gracias por tus invaluables aportes Iván!!