La razón muy sencilla, es imposible probar al 100% un sistema software. El número de pruebas software es típicamente… infinito.
Imagina una aplicación software, una página Web, que tiene un simple campo de texto en el que se puede introducir cualquier número entero entre 1 y 1000. Para probar completamente esa entrada, habría que hacer una prueba con cada uno de los 1000 valores, 1000 pruebas.
Pero, además, habría que probar qué pasa con cada número por debajo de 1, por encima de 1000, todos los números racionales, y todos los no numéricos (p.e. “a”, *, etc.). Y las aplicaciones de verdad no tienen solo un campo de texto.
¿Y qué pasa con la siguiente secuencia de pulsaciones de teclado: 1 2 < espacio > 4 < espacio > 8?
Introducir entre números o cientos de podría desbordar un buffer (muchas aplicaciones software tienen ese error). ¿Cuántas variaciones hay que probar antes de poder estar absolutamente seguro de que hemos contemplado todos los errores y posibilidades? O supongamos que un software te permite sumar dos números, el primer número entre 1 y 100 y el segundo entre 1 y 25: el número total de pares a probar (sin contar los pares no válidos) es 100 x 25 = 2500.
Es más, supongamos que el software acepta cualquier número entre 1 y 9999999. Y escribes 123, esperas un minuto y, a continuación, escribes un 4567. ¿Qué sucederá? ¿Qué número tomará el sistema? ¿123 o 1234567? Si fuese un software de telefonía el sistema podría haber agotado el tiempo de espera y haber desechado el 4567. O no. ¿Y qué ocurre con 1-pausa-2-pausa-3-pausa?
Además, están las combinaciones, por ejemplo ¿cuántas versiones de controladores de ratón debemos probar en combinación con controladoras de vídeo y con cuántos controladores de impresora? Y las compatibilidades hardware / software. Además habría que ver si el software falla cuando demasiados procesos se están ejecutando a la vez, cuantos usuarios concurrentes soporta, etc.
Todo lo anterior sin contar pruebas como las de usabilidad, ya que si la usabilidad no es la mejor el sistema será más propenso a los errores humanos. Las de requisitos, que pueden haberse tomado mal o no haberse tomado, etc.
Y la cosa es aún más compleja si pensamos que un sistema software convive con otros que pueden no estar bajo el ámbito de las pruebas, por ejemplo cuando hay una interrupción (es decir, un error que para la ejecución del programa y pasar el control a otro software).
Concluyendo…
Por todo lo anterior, probar al 100% un sistema software es imposible. Y si queremos acercarnos a ese 100%, los costes y tiempos se disparan.
Se han llegado a hacer incluso estudios experimentales (te dejo aquí mas información) intentando determinar el número de casos de prueba que cubrirían el total de un software medio (utilizando técnicas de Myers (1979) o Kit (1995)), arrojando la cifra media de 10 elevado a 100 pruebas. Se estima que el número de moléculas en el Universo es 10 elevado a 90, o lo que es lo mismo, es imposible hacer 10 elevado a 100 pruebas.
Así que, normalmente, cuando se prueba se selecciona un pequeño número de casos de prueba que representen el total de pruebas posibles. La muestra puede o no revelar todos los errores. Para ahorrar tiempo, normalmente se prueban los valores límite, en el ejemplo del campo que acepta del 0 al 1000 serán el 0, 1, 1000 y 1001.
En cualquier caso, es obvio decir que dependiendo de la criticidad del sistema (no es lo mismo la web de un periódico que el software de un avión) los responsables de las pruebas deberán intentar acercarse más o menos a ese 100% (aumentando más o menos el presupuesto).
Como ya dijo el genio Dijkstra hace mucho tiempo… “Program testing can be used to show the presence of bugs, but never to show their absence” (las pruebas pueden usarse para mostrar errores, pero nunca para mostrar la ausencia de los mismos).
Más…
Si quieres ampliar el tema, os recomiendo “Myers (1979) The Art of Software Testing”, “Kit (1995) Software Testing in the Real World” y un documento muy bueno es el de Kaner, donde hay muchas ideas de este post.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Pingback: Bitacoras.com
Pingback: Automatizar las pruebas puede ser lo peor que hagas en tu vida. Te lo explico con una mala experiencia real - Javier Garzás, sobre calidad software y otros temas relacionados
Muy bueno Javier. Considero que lo mejor de tus posts es que provocan cambios en paradigmas erróneos que usamos diariamente.
Gracias.
😉
totalmente de akuerdo. respekto