En estos tiempos el testing exploratorio se ha venido convirtiendo en nuestro principal aliado debido al ritmo de trabajo en entornos ágiles, por lo que es de vital importancia que conozcamos, cuándo y cómo debe usarse.
Hace varios años que vengo participando en proyectos donde se ha realizado testing exploratorio, con estas experiencias he aprendido muchísimo de las ventajas que presenta y cómo podemos adaptarlo en dependencia del proyecto, cliente, equipo, etc.
En este artículo vamos a estar compartiendo como puedes comenzar a dar tus primeros pasos en el mundo del Testing Exploratorio. Basado en mi experiencia les estaré contando algunas buenas prácticas que puedes aplicar al realizar Testing Exploratorio en tus proyectos.
Técnicas basadas en la experiencia
Según el Syllabus de ISTQB_CTFL_2018 en la página 77 podemos encontrar que entre las técnicas basadas en la experiencia se mencionan: la predicción de errores, las pruebas basadas en checklist y el testing exploratorio.Cuando aplicamos las técnicas de pruebas basadas en la experiencia, los casos de pruebas son derivados del mismo tester según sus habilidades, intuición y experiencia realizando pruebas a aplicaciones con tecnologías y negocios similares.
Revisemos a continuación con más detalles en que consiste cada técnica:
Predicción de errores
La Predicción de errores es una técnica usada para anticipar la ocurrencia de errores basado en la experiencia y conocimientos del tester. Se basa en conocer cómo la aplicación ha estado funcionando en el pasado, los tipos de errores que tienden a cometer los desarrolladores y errores que han ocurrido en otras aplicaciones similares a la que se está probando.
Pruebas basadas en Checklist
Las Pruebas basadas en Checklist es una técnica donde el tester diseña, implementa y ejecuta pruebas para cubrir lo especificado en la checklist. Como parte de las pruebas que se van realizado se puede crear una nueva checklist o se le incorporan nuevos aspectos a tener en cuenta o nos mantenemos usando la misma checklist sin modificarla. Estas checklists pueden ser elaboradas según la experiencia y conocimiento del tester sobre qué es importante para el usuario final en nuestra aplicación o al tener un entendimiento del por qué y cómo el software pudiera llegar a fallar.
Testing Exploratorio
Esta técnica es la que vamos a estar analizando con mayor profundidad en este artículo, para esto comencemos a explorar el testing exploratorio!
¿Qué es Testing Exploratorio?
La definición de testing exploratorio ha sido dada por muchos referentes del área como James Bach, Cem Karner, Brian Marick, Elizabeth Hendrickson entre otros.En 1999 estos autores se reunieron y resaltaron algunas de las características del testing exploratorio en la que todos coincidían. Entre esas características tenemos que es:
- Interactivo
- El conocimiento y la ejecución ocurren al mismo tiempo.
- Creativo
- Conduce hacia resultados rápidos.
¿Cuándo realizar Testing Exploratorio?
El testing exploratorio puede ser usado en cualquier situación donde no se conozca cuál es la siguiente prueba que se deba realizar o cuando queremos ir más allá de las pruebas obvias.También puede ser usado en cualquiera de las siguientes situaciones:
- Necesitamos proveer feedback de un nuevo producto o funcionalidad.
- Necesitamos aprender rápidamente el producto.
- Tenemos pruebas automatizadas pero queremos diversificar nuestras pruebas.
- Análisis del producto y planificación de pruebas.
- Mejorar pruebas existentes.
- Pruebas de Regresión.
Beneficios del testing exploratorio en entornos ágiles
Fácil de optimizar: Nos permite proporcionar actualizaciones en tiempo real al equipo de desarrollo.Tomar decisiones en tiempo real: Uno de los mayores requisitos para ser ágil es la capacidad de reaccionar rápidamente a los cambios y adaptarse, con el fin de crear los mejores proyectos posibles. Las pruebas exploratorias pueden ayudar a los equipos a alcanzar este objetivo.
Llega donde la automatización no puede: La automatización puede encontrar fácilmente errores comunes en el código, pero no pueden determinar si la aplicación funcionará de la manera que un usuario lo espera.
Podemos decir que las pruebas exploratorias alientan al tester a ser creativo en su ambiente, en lugar de quedar atascado tratando de ejecutar ‘n’ números de pruebas al día.
Enfoque Ad-hoc
Pero ser creativo no significa llevar un enfoque Ad-hoc a nuestras pruebas exploratorias ya que al aplicar un enfoque Ad-hoc estaríamos haciendo pruebas sin tener un objetivo en mente y sin un método de prueba claro.Esto nos pudiera llevar a la situación que se nos pregunte al final del día el estado de las pruebas exploratorias que se estuvieron realizando y en ese momento no sepamos con exactitud las áreas del sistema que estuvimos explorando, o cómo detectamos los bugs que fueron reportados. Nos será realmente muy difícil recordar todos los detalles.
Nuestro trabajo luce poco profesional, cuando no llevamos un control y trazabilidad de las pruebas que realizamos, y no tenemos un seguimiento de lo probado.
Para tener un registro cuando realizamos testing exploratorio podemos basarnos en lo que nos propone Jonathan Bach, realizar el testing exploratorio basado en sesiones.
Testing Exploratorio basado en sesiones.
Con las sesiones exploratorias podemos tener evidenciado que tipo de trabajo se realizó y cómo será reportado.
Veremos a continuación qué información debemos registrar en nuestras sesiones:
Misión: Debe quedar reflejado el objetivo de nuestra sesión exploratoria, debe ser lo más sencillo y descriptivo posible.
Áreas: Estaremos registrando datos como el sistema operativo donde estemos probando, tipo y versión del navegador o dispositivo mobile, área de la aplicación donde se esté probando.
Tiempo de la sesión: Registramos la fecha y hora de comienzo de la sesión.
Tester: Nuestros datos.
División de tareas (métricas): Esta parte es en la que en ocasiones no prestamos mucha atención y la completamos sin darle mucha importancia y es acá donde podemos ir conociendo si deberíamos volver a repetir la sesión, si nos fuimos por las ramas y nos desviamos del objetivo planteado para la sesión. Aconsejaría completar esta información de último para que los datos queden correctamente registrados. En este caso la información que se completa es: Duración de la sesión que puede ser corta, mediana o larga, se puede considerar una sesión corta de 30 minutos o menos, media de 45 min y una larga de hasta 1 hora. Porcentaje invertido según cuánto nos llevó el diseño de las pruebas y la ejecución, el porcentaje de investigación y reporte de incidentes, el porcentaje del armado de la sesión y por último el porcentaje de Misión vs Oportunidad.
Archivos de datos: Sería todo aquella información que se tuvo que utilizar para llevar a cabo nuestra sesión, por ejemplo si necesitábamos adjuntar algún archivo se colocaría el nombre o referencias a este archivo, datos que se necesiten para completar determinado flujo.
Notas de prueba: Las notas de prueba se pueden ir completando a medida que avanzamos en nuestra sesión o al final, esto es a gusto de cada tester y como se sientan más cómodo realizándolo, en mi caso en particular voy completando de a poco para no olvidarme de los detalles o de los pasos que voy realizando, las notas pueden ser muy específicas detallando todo lo que se fue realizando en forma de historia o se pueden redactar de forma más escueta indicando que áreas se recorrieron y solo detallando a grandes rasgos lo que se fue realizando y recorriendo en nuestra exploración.
Riesgos y Defectos: Se registran los riesgos que se consideren pueden ser relevantes para el sistema en función del área que estemos explorando y los defectos o bugs se completan según los errores que se detecten en el sistema.
Inconvenientes y Dudas: En esta sección nos puede ser muy útil registrar todo aquello que no nos haya quedado claro si el funcionamiento es el esperado o no, si se tuvo algún inconveniente al momento de realizar la sesión para que se puedan prevenir en futuras sesiones exploratorias.
Resumiendo
Seguir esta práctica nos ayudará a tener un registro del estado de nuestro sistema y de las pruebas que se vienen realizando.En proyectos donde he realizado testing exploratorio basado en sesiones ha sido muy útil contar con la información que se genera en cada sesión exploratoria.
Pero uno de los inconvenientes que se me presentaba era que se me hacía muy engorroso conocer rápidamente el cubrimiento de las pruebas en la aplicación y la documentación que se iba generando por cada sesión exploratoria.
¿Cómo cambié mi proceso a raíz de estos problemas que se me estaban presentando?
No te pierdas la segunda parte de este artículo, donde te lo estaré contando!