Cuándo realizar menos pruebas
Comentario de un artículo de IEEE Software del número de Septiembre/Octubre de 2000.
When to test less, de Tim Menzies y Bojan Cukic
El artículo defiende que en pequeños proyectos, un gran conjunto de pruebas no verifican mejor el sistema que un pequeño número.
Si una entrada al azar en una prueba de caja negra tiene una probabilidad x de provocar un fallo, entonces 1-x es la probabilidad de que esa entrada no falle.
Si se realizan N pruebas de caja negra => (1-x)^N es la probabilidad y de encontrar un fallo en N pruebas aleatorias.
(si x=0.0001, se requiere 46000 pruebas para estar seguro al 99% de encontrar ese fallo).
Sin embargo, las empresas medianas-pequeñas no realizan más de centenares de pruebas -a veces decenas nada más-.
Los autores describen la "forma" -shape- de un programa como los diferentes caminos dentro de él. Entonces, la pregunta es cuál debe ser la "forma" de una aplicación para que se pueda probar adecuadamente utilizando recursos limitados.
De hecho, lo que afirman es que una forma correcta es aquella que nos permite tomar una de las siguientes dos decisiones:
En definitiva, proponen lo siguiente: ejecución rutinaria de pruebas nocturnas con miles de test cases generados de una manera totalmente aleatoria (sin ningún tipo de desviación, según su modelo NAYO).
When to test less, de Tim Menzies y Bojan Cukic
El artículo defiende que en pequeños proyectos, un gran conjunto de pruebas no verifican mejor el sistema que un pequeño número.
Si una entrada al azar en una prueba de caja negra tiene una probabilidad x de provocar un fallo, entonces 1-x es la probabilidad de que esa entrada no falle.
Si se realizan N pruebas de caja negra => (1-x)^N es la probabilidad y de encontrar un fallo en N pruebas aleatorias.
(si x=0.0001, se requiere 46000 pruebas para estar seguro al 99% de encontrar ese fallo).
Sin embargo, las empresas medianas-pequeñas no realizan más de centenares de pruebas -a veces decenas nada más-.
Los autores describen la "forma" -shape- de un programa como los diferentes caminos dentro de él. Entonces, la pregunta es cuál debe ser la "forma" de una aplicación para que se pueda probar adecuadamente utilizando recursos limitados.
De hecho, lo que afirman es que una forma correcta es aquella que nos permite tomar una de las siguientes dos decisiones:
- la forma del programa es tan compleja que no merece la pena realizar muchas pruebas, pues no podrán encontrar fallos residentes en regiones remotas del código.
- la forma del programa es tan simple que un conjunto limitado de pruebas será suficiente.
En definitiva, proponen lo siguiente: ejecución rutinaria de pruebas nocturnas con miles de test cases generados de una manera totalmente aleatoria (sin ningún tipo de desviación, según su modelo NAYO).
Comments