Desarrollo de software. ¿Dónde enfocar el testing exploratorio?
Como en todo, lo importante es dedicar al testing el tiempo que necesite la aplicación en función de su criticidad, complejidad, etc… y en función de cómo se ha desarrollado el proyecto. Lo difícil es precisar con exactitud cuánto es suficiente (y que exista disponibilidad real de tiempo y recursos para poder realizar esta actividad).
El problema es el de siempre, todo se deja para el final y el equipo de desarrollo no dedica tiempo suficiente al testing y además es más que posible que la calidad del código y de la arquitectura sea tal que la probabilidad de que existan errores de integración o por efectos colaterales es importante.
¿Qué quiero decir con todo esto? Pues que el tiempo es limitado y las condiciones para realizar el testing no serán en muchos casos las mejores (lo cual no quite que intentemos aproximarnos lo máximo posible a ese «tiempo que necesite» que comenté en el primer párrafo).
Esto nos lleva a que hay que priorizar. Si existen casos de prueba diseñados a medida o diseñables a partir de la documentación existente en el proyecto o de la combinación de la misma y conversaciones con los analistas, programadores, usuarios, etc… es necesario ejecutarlos, recordemos que donde más puede flaquear el equipo de testing si no ha participado en el proceso de definición y desarrollo del sistema es en la comprensión de la lógica del negocio.
Y después nos queda el testing exploratorio para intentar cubrir los huecos (muchas veces numerosos) que dejarán tras de sí los casos de prueba. ¿Hacia dónde lo enfocamos?, ¿donde invertir el esfuerzo? Yo lo respondo con otras preguntas: ¿qué partes del sistema son las críticas?, ¿qué aspectos no están cubiertos con casos de prueba?, ¿qué partes del sistema están integradas con otros (ya sea para recibir y/o enviar información)?, ¿qué aspectos no están cubiertos con casos de prueba?, ¿existe una matriz de compatibilidad con navegadores de la aplicación?, ¿se han dedicado pruebas a ello?.
Hacer un buen testing exploratorio no es sencillo, se requieren testers con experiencia y conocimientos para que a través de ello y de la información que dispongan y consigan saber dónde enfocar los esfuerzos. Ahora bien, no esperes un trabajo excelente si no se les proporciona ayuda y/o información y además el tiempo es muy limitado.
Si un sistema tiene una deuda técnica alta y en particular presenta un alto acoplamiento entre clases, la realización de testing exploratorio resulta crucial ya que en este caso, los efectos colaterales pueden aparecer hasta en el sitio más insospechado de la aplicación, en este caso hay que sacar el tiempo que sea necesario a realizar las pruebas oportunas ya que no podemos dejar que el comportamiento de la nueva versión del sistema en el entorno de producción sea como jugar a la ruleta rusa. En producción que, por favor, las sorpresas sean las mínimas posibles.
Jummp 