Pruebas exploratorias Vs. Pruebas aleatorias

Posted on 26 febrero 2009. Filed under: Uncategorized |

Cuando hablo sobre la aliatoriedad de las pruebas, me estoy refiriendo la imposibilidad de repetir caminos concretos que nos permitieron detectar un fallo en particular.

Una prueba ejecutada con una variante, por más ínfima que parezca la variante, ya no es la misma prueba sino una totalmente distinta y factible de obtener otros resultados muy diferentes.

Me gusta ser aleatorio a la hora de probar, pues esto me lleva al descubrimiento de “lo inpensado”, pero suelo modelar las pruebas para mantenerlas dentro de unos límites tolerables por el sistema construido y en los márgenes de un alcance planeado.

No gusto de ser aleatorio a la hora modelar las pruebas para el contexto, de formalizar los ciclos y sus 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.

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 de las pruebas que propongo, 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. Las Pruebas Exploratorias son el resultado del estudio y aplicación del sistema en el contexto adecuado.

Liked it here?
Why not try sites on the blogroll...

A %d blogueros les gusta esto: