UN RECORRIDO POR LA HISTORIA DE LAS PRUEBAS DE SOFTWARE

Las pruebas son el único instrumento que puede determinar la calidad de un producto software, es decir, es el único método por el que se puede asegurar que un software cumple con los requerimientos solicitados por los usuarios.  A través del tiempo han surgido diversas metodologías para probar software, las cuales han ido evolucionando de forma paralela con la Ingeniería de Software.

Las pruebas ubicadas dentro de la historia de la Ingeniería del software y siendo organizadas por un criterio de orientación, que permita hacer un balance sobre su evolución pueden subdividirse, por el momento, en cinco intervalos temporales:

● Antes de 1956. Periodo orientado a debugging.

El concepto de test o prueba en lo referente al software parte, o es precursor del mismo, A.M. Turing que en 1949 redacta: Checking a Large Routine donde ya se discute el uso de aserciones para realizar pruebas de corrección.

En este momento todas las pruebas que se realizaban estaban orientadas a la corrección directa del código fuente de los programas. Eran realizadas directamente por los programadores y no estaba clara la diferencia entre: checkout, debugging y testing.

● Entre 1957 y 1978. Periodo orientado a demostración.

En este momento las pruebas se centran en la realización de checkouts exhaustivos que se focalizan en dos aspectos clave. Por un lado asegurar que el programa funciona (Debugging) y por otro asegurar que el programa resuelve el problema (Testing), tal y como expone en 1957 C. Baker en su artículo Review of D.D. McCracken’s Digital Computer Programming.

Podría afirmarse que en esta fase se utilizan de forma masiva test para garantizar que se cumple con la especificación. Dichos test se realizan al final del desarrollo del software.

● Entre 1979 y 1982. Periodo orientado a destrucción.

En 1979 G.J. Myers, publica The Art of Software Testing, donde expone que el “Testing es el proceso de ejecutar un programa con la intención de encontrar errores.”

Esto cambia por completo el paradigma de las pruebas ya que se pasa de intentar demostrar que un programa es correcto mediante pruebas y demostraciones teóricas basadas en matemáticas a intentar hacer fallar el programa. El objetivo no cambia, intentar que el programa no tenga fallos, pero si la forma de buscarlos.

En este momento, si una prueba produce un fallo se considera que la prueba ha tenido éxito. A efectos de concepto, los tests se convierten en casos de prueba que se aplican a los productos desarrollados para encontrar errores y corregirlos.

“Las pruebas de software son el proceso de ejecutar un programa con la intención de encontrar errores” G.J. Myers.

● Entre 1983 y 1984. Periodo orientado a evaluación.

En 1983 Guideline for Lifecycle Validation, Verification and Testing of Computer Software. NBS FIPS propone y describe una metodología que integra análisis, revisión y testing en el ciclo de vida del desarrollo de software.

Las pruebas de Software empiezan a integrarse en las diferentes metodologías de desarrollo de software.

“El objetivo general de las pruebas de software es confirmar la calidad de los sistemas software ejercitando sistemáticamente el software en unas circunstancias cuidadosamente controladas” E.F. Miller.

● Entre 1985 en adelante. Periodo orientado a prevención.

En 1985 H. Hetzel, y D. Gelperin, implementan STEP (Systematic Test and Evaluation Process) sobre los estándares formales IEEE 829-1983 y 828-1998. Este hecho consigue que las pruebas del software cobren una mayor importancia en el ciclo de desarrollo de software con lo que se abre la posibilidad de integrar pruebas en las diferentes fases del mismo.

Durante esta época las pruebas se diversifican para cubrir todas las fases del desarrollo, poder comprobar todos los tipos de artefactos, prototipos, modelos, módulos, subsistemas y sistemas que componen los productos software del momento.

Poco a poco las pruebas se considerarán una parte clave de todo el ciclo de desarrollo.

 “Hacer pruebas significa comparar los resultados actuales con un estándar” Hutcheson, M.L.