El pasado lunes tuve la ocasión de asistir a una charla sobre tests exploratorios, una manera diferente de probar el funcionamiento de nuestras aplicaciones. La charla fue impartida por Luis Rodriguez nuestro Release Manager en Plastic SCM.
Cuando desarrollamos software estamos acostumbrados a hacer pruebas unitarias de clases, de integración entre componentes, y de aceptación con el cliente. Los test exploratorios, pese a ser menos conocidos, resultan tremendamente útiles ya que permiten, usando la intuición y la experiencia acumulada de la persona que realiza la función de tester, encontrar nuevos errores y escenarios que no saldrían a la luz en test automatizados.
Cuenta de 3 componentes específicos:
- Charter: Contiene la definición del test. Qué es lo que se pretende probar durante el tiempo de pruebas.
- Session test: El tiempo dedicado a la prueba. No se recomienda que sea de más de 3 horas.
- Informe: Qué se ha probado, qué se ha encontrado, y cómo reproducir fallos.
Charter
La clave es «debe caber en un post-it«. Debe ser lo suficientemente específico como para poder ser probado (Mal ejemplo: Probar todo el sistema) así como suficientemente amplio como para que vaya más allá de un test automático (Mal ejemplo: Probar a introducir letras en un campo «Código postal»).
Session test
Como se ha comentado anteriormente, se recomienda reservar un espacio de tiempo no mayor que 3 horas. Se pueden emplear varias estrategias para planificar los test:
- Exploración analítica: Partiendo de diferentes estados y eventos del sistema, se obtienen las posibles variaciones, y será aquello que pruebe.
- Atención al detalle: Usar los logs para comprobar el rendimiento del sistema, así como comprobar las métricas (CPU, disco duro, RAM…) permitirá saber no solo si el programa funciona, sino cómo afecta al equipo
- Asumir roles de usuario: Ya que existen diferentes roles, el novato, el experimentado, el impaciente o el hacker, entre otros. Cada rol verá nuestro programa de diferente manera.
Es importante destacar que este test está planificado, es decir, no es dedicarse durante 3 horas a recorrer aleatoriamente el sistema, sino que, basándonos en el charter, debemos pensar (y planificar) qué queremos probar, para que luego sea más fácil dejarlo por escrito en el informe.
Informe
Finalmente se redacta un informe con la información del sistema y el tiempo dedicado a cada una de las pruebas, los resultados de las mismas, y recomendaciones adicionales. Permite además encontrar escenarios que se puedan automatizar.
Conclusiones
Los beneficios de los test exploratorios se pueden resumir en más bugs encontrados, un mayor análisis en profundidad y más áreas cubiertas, aunque para poder aprovecharlo al máximo se requiere un perfil lo más creativo posible, ya que la persona debe pensar en escenarios probables y difíciles.
rlbisbe @ dev 