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 Giulliana Scuoteguazza, quien trabaja como tester en Abstracta.
En la entrevista, Giulliana Scuoteguazza nos cuenta que ha trabajado con testing exploratorio basado en sesiones. Giulliana nos ofrece una mirada sumamente crítica con el testing exploratorio y sus formas de implementación. A lo largo de su experiencia ha observado diversas oportunidades de mejora tanto en la realización de esta práctica como en lo referente a la gestión de la misma. Ha tenido oportunidad de capacitar a diversos testers desde su arranque, por lo que nos cuenta las principales dificultades que ellos suelen encontrar al enfrentarse por primera vez al testing exploratorio basado en sesiones y sobre todo al registrar las sesiones.
Durante la entrevista, nos va detallando los puntos flojos que ha encontrado así como algunas buenas prácticas o modificaciones a la técnica original que ha ido incorporando. Como primeros puntos que implican problemas al incorporar esta técnica destaca el poco tiempo que se le dedica a planificar las actividades de testing exploratorio, el no definir objetivos, sino simplemente ir y probar, o el dejar que testers juniors realicen pruebas sin una guía adecuada para hacerlo.
Misiones y objetivos exploratorios
Giulliana prefiere planificar el testing exploratorio por objetivos exploratorios en lugar de misiones, ya que entiende que de este modo puede basarse en cosas más concretas y se pueden obtener mejores reportes y hacer un mejor seguimiento. El problema de usar misiones, afirma, es que al mirar planillas de avance los nombres de las misiones son larguísimos y quedan cortados en los reportes. Suele armar una planilla donde lista los objetivos exploratorios, indicando a su lado la prioridad de la funcionalidad y la duración prevista. Es una manera de estimar el esfuerzo y de saber qué tester está trabajando en qué. Los reportes que se pueden tener son de cobertura por prioridad y de tiempo que invertimos en cada funcionalidad. Lo que comenta que le ha pasado cuando hay misiones amplias es que son muy abarcativas, y si llegara a pasar que una misión lleva más de una hora para ejecutarla, puede quedar por la mitad, o a veces no está claro el alcance de esa misión por ser amplia y es más complicado evitar que se solapen las tareas de varios testers.
Luego nos comenta aquella información que le resulta relevante completar al realizar el testing exploratorio basado en sesiones, o sea en la ejecución propiamente dicha. Entonces, en lo que está estipulado según la metodología bajo el nombre de “Áreas” solo registra el sistema operativo, navegador, dispositivo, etc. No completa otro tipo de información como ser estrategias por ejemplo. Sí incluye la versión de la aplicación, algo que considera fundamental. Luego completa la información acerca de la hora de comienzo, y quién realiza la exploración.
Duración de las sesiones y métricas
En lo que se refiere a la duración de las tareas, comenta que existen tres duraciones ya tabuladas. Éstas son: Corta (30-45), Media (45-60), Larga (60-90 o 120). Entiende que estas duraciones no han sido establecidas al azar sino que tienen su fundamento, y es importante considerar alguna de esas duraciones a la hora de planificar las sesiones a realizar, manteniendo siempre cierta flexibilidad como para adaptar a lo que convenga.
En lo que refiere a la división de las tareas en configuración de la sesión, investigación y reporte y diseño y ejecución destaca poner énfasis en el uso de porcentajes y no simplemente números, ya que éstos no se sabe bien a qué hacen referencia.
Archivos, notas, riesgos e inconvenientes
En la sección de archivos de datos es necesario poner énfasis en todo lo que abarca esta sección, incluye por ejemplo los datos de prueba brindados por el cliente, es importante no dejar en blanco esta sección.
Luego, en las notas de prueba, ha observado que muchas veces no se agregan los resultados esperado y obtenido, lo cual entiende es sumamente importante.
Nos muestra un ejemplo de cómo ella redacta la sección de notas:
PRUEBA 1: aaaaaaaa RESULTADO PRUEBA 1: PASÓ PRUEBA 2: bbbbbbb Esperaba que no ingresara sin embargo se logueó... RESULTADO PRUEBA 2: FALLÓ
Como vemos en el ejemplo, organiza las notas en pruebas, e incluye siempre el resultado que esperaba, el obtenido y el estado de la prueba, si pasó o falló.
Respecto a la sección de riesgos, si los hay entonces los coloca en la sección inconvenientes.
Continuando con el formulario de las sesiones, completa los incidentes o bugs. En esta sección incluye el ID del bug reportado en la herramienta de gestión de incidentes que se utilice, la severidad del incidente y el título con el que fue reportado.
En la sección de inconvenientes anota bugs que podrían ser errores para luego corroborar si son o no errores.
Una sección que no está explícita, y que muchas veces agrega es la sección de “Dudas”. En general lo que hace es taguear a la persona que debe responder, y si no, envía las dudas por mail, de forma de evitar que queden perdidas en el registro.
Planificación de las pruebas exploratorias
Giulliana nos cuenta cómo planifica el trabajo. En general los proyectos de testing exploratorio en los que ha participado duran en el entorno de una semana o dos. Hace un plan de pruebas en el cual lista todos los objetivos exploratorios y asigna los tiempos, eligiendo siempre alguno de los tiempos tabulados que nos comentó anteriormente. Luego le agrega la prioridad: ALTA, MEDIA, BAJA.
¿Cómo reporta el avance?
La forma de registro de las sesiones le permite obtener fácilmente información sobre el avance. Por ejemplo, lleva un registro de los resultados de ejecución de los objetivos exploratorios (indicando si pasaron o fallaron). De este modo puede obtener información sobre la cobertura. Además, al considerar objetivos de prueba puede llevar un mapeo entre los objetivos y los incidentes con su severidad. Finalmente, tiene una idea de la velocidad de ejecución comparando las sesiones realizadas con el total de las sesiones planificadas.
¿Quién es Giulliana Scuoteguazza?
El testing es su pasión. Realizó diversos estudios de programación y se formó luego en testing en TCS. Cuenta con 6 años de experiencia en consultoría, participando desde el año 2012 en proyectos de pruebas funcionales como tester, analista y líder de proyectos en la empresa Abstracta. Cuenta con amplia experiencia en el uso de herramientas de gestión de testing. Autora del capítulo “Habilidades del tester” del libro “Introducción a las Pruebas de Sistemas de Información” de Federico Toledo, publicado en 2014. Colaboradora del Proyecto Nahual.
Links a otras entrevistas y a más información del proyecto:
One thought on “Relytest: Entrevista sobre testing exploratorio a Giulliana Scuoteguazza de Abstracta”