Pruebas exploratorias Vs. Pruebas aleatorias

En muchos de los proyectos en los que he liderado pruebas, ejecuté un gran volumen de pruebas exploratorias y recientemente uno de esos proyectos fue testeado netamente bajo pruebas del tipo exploratorio.
El grado de éxito en este proyecto fue muy importante y básicamente me permitió demostrar que esta técnica es particularmente útil en algunos contextos.

Lo primero que hice fue transferir al equipo el concepto de pruebas exploratorias y contrastarlas con las pruebas aleatorias. Así es que cuando hablo sobre pruebas aleatorias, me refiero a todas esas pruebas ejecutadas en un contexto de muy alto riesgo, sin un soporte de un marco definido, sin expectativas más que las de detectar defectos.  Una consecuencia de este proceso aleatorio, sería la imposibilidad de repetir escenarios concretos que nos permitieron detectar un fallo en particular.

En su contraparte, a las pruebas exploratorias  suelo ejecutarlas dentro de unos límites tolerables bajo una planificación estratégica del testing, con alcances delimitados, modelando los escenarios para el contexto, formalizando los ciclos y contemplando resultados esperados. De otro modo creo que promovería el caos en el Testing y lo diseminaría por todo el proceso de desarrollo. En otras palabras gusto de contar con ciclos controlados para la exploración.

Ciclos bien controlados implican análisis de los requerimientos, del entorno de ejecución para el uso final, del entorno de ejecución para pruebas preliminares a las pruebas de sistemas, del entorno de ejecución para pruebas de sistemas, para pruebas de campo (post-despliegues), conocimiento de las dependencias, de las entradas y salidas y los procesos.

No deberíamos confundir “Testing aleatorio” con “Testing exploratorio”, puesto a que lo segundo aplica cierta formalidad en la técnica, aún cuando es libre de tomar algún camino alternativo no calculado o no premeditado.

La aliatoriedad del Testing no necesariamente ampliará la cobertura de pruebas, de hecho es demasiado factible que los criterios de aseguramiento de calidad (criterios de aceptación, modos de fallos-modos de pruebas) terminen siendo extraviados al violar límites y alcances por no calcularlos de antemano. Inclusive corremos demasiado el riesgo de modificar lo que se construye, si es que no mantenemos controlado el resultado de las pruebas.

¿Debemos responder al cambio? si lo antes posible. Pero no se puede hacer con pruebas no planificadas, con aliatoriedad mandatoria. Afrontar los cambios será posible a partir de la obtención de experiencia en los sistemas que necesitamos probar y garantizar, y junto con esta experiencia obtenida crece la posibilidad de un Testing Exploratorio más conveniente que cualquier otro tipo de Testing.

La repetitividad es un elemento absolutamente necesario en las pruebas que propongo, pero no van de la mano con la construcción de los casos de pruebas formales, sino del diseño que antes expliqué y la comprensión de la evidencias de construcción y de otros cientos de elementos que deberían, primero ser llevados a un nivel de abstracción dentro del contexto de las pruebas (no la abstracción típica de los requisitos y sus análisis de sistemas) y luego ser bajados al nivel de la ejecución.

En este nivel podremos configurar los distintos contextos, ya traducidos a ciclos ejecutables (hasrdware+software+testing), donde la adaptación de las pruebas será extremadamente simple aún cuando se generan nuevas características para el mismo sistema.

En conclusión, para mi el diseño de pruebas para diferentes contextos de ejecución es posible y es preferible. Las pruebas planteadas en Casos de Pruebas no sirven salvo que hablemos de productos enormes y sin posibilidades de cambios a traves del tiempo.

Las pruebas aleatorias son sinónimo de pruebas sin planificación y sin conocimiento del impacto de los resultados, pero las Pruebas Exploratorias son el resultado del estudio y aplicación del sistema en el contexto adecuado.

Advertisements

Visual Studio Team System 2010 y sus nuevas caractarísticas para Testing

Microsoft no deja de sorprender con sus vistosos paquetes de sistemas para toda clase de entornos. Ahora se dispone a liberar su Visual Studio Team System 10 y lo primero que me llamó la atención, fueron las nuevas características de automatización del testing  para Interfaces de Usuario Final (UI).
En esta difusión vemos un claro ejemplo, aunque demasiado sencillo, de como es posible automatizar la mayoría de los aspectos relativos a pruebas sobre las interfaces de usuario. La suite escribe todo el código necesario y solo nos resta agregarle la inteligencia suficiente y necesaria para ampliar la batería y mejorar la cobertura.

Otro aspecto importante de este potente paquete es la disponibilidad de herramientas VSTS para el Aseguramiento de Calidad del Software, más allá de los aspectos relativos a solo testing.
Microsoft provee en este conjunto, herramientas orientadas al TESTER sin pretender que el mismo sea un desarrollador en potencia, ni que el desarrollador ejecute testing funcional.
Se promete un entorno rico y colaborativo donde diseñar las pruebas desde el principio sea posible, escribir los casos de pruebas sea bajo un lenguaje unificado y cotidiano, ejecutarlos sea acorde a la capa para la que se diseñó , reportar defectos, priorizarlos, resolverlos y verificarlos, se harán en un único hilo de proceso, de una manera sencilla y única que permita derribar cualquier barrera comunicacional entre desarrolladores y testers.
La propuesta es un único entorno de trabajo orientado al objetivo del negocio.

Lo agradable, desde mi punto de vista, es la promesa de que a pesar de la potencia de la suite para promover la automatización de todo el conjunto de pruebas en todos los niveles del ciclo de desarrollo, en realidad viene a promover la “ingeniería de las pruebas manuales”, pero potenciando aspecto relacionados al diseño de las pruebas, planteos de casos documentados, mejora en el manejo de cambio de requerimientos y el impacto en las pruebas.
De este modo las pruebas son controladas y se disminuye el alto grado de aleatoriedad de las pruebas manuales controlando los diferentes escenarios diseñados.

Y para finalizar, les dejo un pequeño ejemplo de como hacer Testing Unitario para código de dispositivos móviles con Visual Studio Team.
En realidad solo quería decir…Aguante la calculadora !!!!