Pruebas de software

1. Introducción
Una de las últimas fases del ciclo de vida antes de entregar un programa para su explotación, es la fase de pruebas.
Una de las sorpresas con las que suelen encontrar los nuevos programadores es la enorme cantidad de tiempo y esfuerzo que requiere esta fase. Se estima que la mitad del esfuerzo de desarrollo de un programa (tanto en tiempo como en gastos) se va en esta fase. Sihablamos de programas que involucran vidas humanas (medicina, equipos nucleares, etc) el costo de la fase de pruebas puede fácilmente superar el 80%.
Pese a su enorme impacto en el coste de desarrollo, es una fase que muchos programadores aún consideran clasificable como un arte y, por tanto, como difícilmente conceptualizable. Es muy difícil entrenar a los nuevos programadores, que aprenderánmucho más de su experiencia que de lo que les cuenten en los cursos de programación.
Aún siendo una tarea abocada al fracaso, voy a intentarlo.
1.1. ¿Qué es probar?
Como parte que es de un proceso industrial, la fase de pruebas añade valor al producto que se maneja: todos los programas tienen errores y la fase de pruebas los descubre; ese es el valor que añade. El objetivo específico de la fase depruebas es encontrar cuantos más errores, mejor.
Es frecuente encontrarse con el error de afirmar que el objetivo de esta fase es convencerse de que el programa funciona bien. En realidad ese es el objetivo propio de las fases anteriores (¿quién va a pasar a la sección de pruebas un producto que sospecha que está mal?). Cumplido ese objetivo, lo mejor posible, se pasa a pruebas. Esto no obstapara reconocer que el objetivo último de todo el proceso de fabricación de programas sea hacer programas que funcionen bien; pero cada fase tiene su objetivo específico, y el de las pruebas es destapar errores.
Probar un programa es ejercitarlo con la peor intención a fin de encontrarle fallos.
Por poner un ejemplo duro, probar un programa es equivalente a la actividad de ciertos profesores paralos que examinar a un alumno consiste en poner en evidencia todo lo que no sabe. Esto es penoso cuando se aplica a personas; pero es exactamente lo que hay que hacerle a los programas.
1.2. La Prueba Exhaustiva es Imposible
La prueba ideal de un sistema sería exponerlo en todas las situaciones posibles, así encontraríamos hasta el último fallo. Indirectamente, garantizamos su respuesta antecualquier caso que se le presente en la ejecución real.
Esto es imposible desde todos los puntos de vista: humano, económico e incluso matemático.
Dado que todo es finito en programación (el número de líneas de código, el número de variables, el número de valores en un tipo, etc etc) cabe pensar que el número de pruebas posibles es finito. Esto deja de ser cierto en cuanto entran en juego bucles, enlos que es fácil introducir condiciones para un funcionamiento sin fin. Aún en el irrealista caso de que el número de posibilidades fuera finito, el número de combinaciones posibles es tan enorme que se hace imposible su identificación y ejecución a todos los efectos prácticos.
Probar un programa es someterle a todas las posible variaciones de los datos de entrada, tanto si son válidos como si nolo son. Imagínese hacer esto con un compilador de cualquier lenguaje: ¡habría que escribir, compilar y ejecutar todos y cada uno de los programas que se pudieran escribir con dicho lenguaje!
Sobre esta premisa de imposibilidad de alcanzar la perfección, hay que buscar formas humanamente abordables y ecónomicamente aceptables de encontrar errores. Nótese que todo es muy relativo y resbaladizo eneste área.
1.3. Organización
Hay multitud de conceptos (y palabras clave) asociadas a las tareas de prueba. Clasificarlas es difícil, pues no son mutuamente disjuntas, sino muy entrelazadas. En lo que sigue intentaremos la siguiente estructura para la presentación:
Fases de prueba:
UNIDADES
Planteamientos:
CAJA BLANCA
Cobertura:
de segmentos
de ramas
de condición/decisión
de bucles...