La historia de las pruebas de software.
Las pruebas de software, también conocidas como software testing, están en su apogeo actualmente. Pero, ¿Cómo comenzó todo? Y ¿Qué nos ha traído hasta acá? Acompáñame en este viaje en el tiempo para conocer la historia de las pruebas de software y comprender su importancia en la actualidad.
Antes de comenzar cualquier viaje primero hay que amarrarse el cinturón de seguridad, y para que todos estemos en la misma sintonía, lo primero que quiero hacer es explicarte en términos muy generales, la diferencia entre software y hardware.
Se que puede sonar tonto para quienes conocen del tema, pero es importante que todos los pasajeros a bordo de este viaje conozcan que hardware hace referencia a la parte física de las máquinas de cómputo, y software a los programas, aplicaciones o sistemas operativos que los controlan.
Y es especialmente importante conocer esta diferencia porque nuestra historia de pruebas de software comienza, curiosamente, corrigiendo errores del hardware.
Remontémonos a la historia de los computadores mismos, donde antes de los años 50 el mundo había conocido las primeras maquinas que respondían a impulsos electromagnéticos para realizar cálculos matemáticos.
Para esos tiempos en los que el hardware no era tan sofisticado, resultaba fundamental poner el foco en los procesos físicos de las máquinas para que todo funcionara. Tal como se hacía en otras industrias.
Porque es importante que dimensiones que así el término “pruebas de software” sea relativamente moderno, las pruebas en realidad, se venían aplicando en diferentes industrias.
Piensa en la comida que comemos, los automóviles que conducimos e incluso los cosméticos que usamos. Todo esto debe de pasar por rigurosas pruebas antes de llegar a las manos de los consumidores.
Y así fue en su momento para las computadoras, solo que como te venía diciendo al principio, se concentraban en probar que el hardware funcionara bien.
Periodo del debugging (1947 – 1956)
Fue por eso que, en 1949, los términos “bug” (bicho) y “debugging” (depurar) fueron acuñados por Grace Murray, una científica de la universidad de Hardvard que para ese momento trabajaba con la Mark II, que era básicamente la segunda computadora para uso académico que conocía el mundo.
Ella, detectó que una polilla se había atascado en un relé provocando que no hiciera contacto y documentó el incidente en su registro de trabajo, pegando la polilla con cinta como evidencia y refiriéndose a la polilla como el “bicho” que causaba el error, y a la acción de eliminar el error la precisó como “depurar”.
Aunque muchos dicen que el término “debugging” ya se usaba con anterioridad a este incidente, lo cierto es que en adelante la palabra se asoció con el hecho de poner un parche a algo en particular que no funcionaba dentro de la etapa de desarrollo de software.
Y es por eso que las pruebas que se realizaban eran solo de carácter correctivo, al tomar ciertas medidas con el fin de hacer que el programa trabajara.
Otro hecho importante para nuestra historia, que sucedió también en 1949, fue que Alan Turing (padre de la computación) escribió su primer artículo acerca de tener cuidado con los chequeos de los programas de las computadoras,
Y más adelante en 1950, en el artículo “Turing test” él explicó la situación de como un software debe adaptarse a los requerimientos de un proyecto.
A toda esta época, desde 1947 hasta 1956 se le conoce como el periodo del debugging, y es la primera de 5 etapas en las que la historia de las pruebas de software se divide, teniendo en cuenta los modelos de pruebas que se llevaban a cabo en cada una de dichas etapas.
Periodo de demostración (1957-1978)
En 1957 Charles Baker situó necesidad de desarrollar pruebas para garantizar que el software cumpliera con los requerimientos pre diseñados (testing) en una jerarquía de importancia comparable con la necesidad de chequear que las funcionalidades del programa estuvieran en orden (debugging).
Esta fue la primera vez que testing y debugging se concebían como actividades distintas y las pruebas de software comenzaron a ser llevadas a cabo como una actividad independiente.
Las pruebas de software se volvieron más importantes, más complejas y costosas; y se puso el foco en incrementar el número y la calidad de las pruebas.
Pero esta estrategia no funcionó, debido a que aumentó la probabilidad de que una funcionalidad del software fallará a medida que se hacían más pruebas. Es decir, entre más pruebas, más probable era que encontraras un bug.
Periodo orientado a la destrucción (1979 – 1982)
¿Podría cambiar toda la historia con una frase? La respuesta es si, ha pasado en la historia de la humanidad y pasó en la historia de las pruebas de software, cuando en 1979 Glenford J Myres escribió esta frase: “Las pruebas de software es el proceso de correr un programa con la intención de encontrar errores”
La tesis de Mryes se basaba en que al tratar de demostrar que un programa funcionaba, uno podría inconscientemente seleccionar los datos de prueba con la menor probabilidad de causar fallas en el programa.
Mientras que, si el objetivo es demostrar que el programa es defectuoso, ibas a elegir datos de prueba con una mayor probabilidad de lograr que el programa falle, y por tanto tendríamos más éxito en las pruebas de software y en consecuencia en la calidad del software.
Es decir, por ejemplo, ingresando letras en un campo que solo debe admitir numeros.
Sin embargo, el enfoque orientado a la destrucción también falló porque el software nunca se lograría lanzar si estamos encontrando un error tras otro. Sin contar con, que corregir un error también podría conducir a otro error.
Periodo de evaluación (1983 – 1987)
Esta vez el foco se centró en evaluar y medir la calidad durante todo el ciclo de vida del software. Las pruebas de software mejoraron el índice de confianza en el que el software funcionaba. Y los testers probaban hasta que alcanzaban un punto aceptable, en donde el número de bugs detectados fuera reducido.
Durante este periodo las pruebas de software fueron reconocidas como una fase integral dentro del desarrollo de un producto de software. Y también porque en esta epoca comenzaron a aparecer herramientas para automatizar las pruebas de software, lo cual ayudó a que el proceso fuera más eficiente.
Periodo de la prevención (1988 – actualidad)
En esta época se pusieron en marcha nuevas metodologías en búsqueda de que las pruebas de software se encarguen de demostrar que el software cumpla con las especificaciones para las que fue creado.
Durante esta época, en 1988, William Hetzel publicó un libro llamado “El crecimiento de las pruebas de software” en el que redefinió el software testing como: la planeación, diseño, construcción, mantenimiento y ejecución de pruebas de software con sus respectivos entornos de prueba.
La revolución más evidente de este concepto se dio en la inclusión de las pruebas de software desde la etapa más temprana de la elaboración de un producto de software, es decir, desde su planeación.
Finalizando nuestro viaje por el tiempo, en el principio de los 2000, se volvieron populares terminos como: test driven development (TDD), o behavioural driven development (BDD) que son metodologías de desarrollo de software en donde las pruebas de software, aparte de aparecer desde las primeras etapas, adquieren un protagonismo especial durante todo el ciclo de vida del producto de software.
Pero, ¿Dónde termina este viaje? Bueno, en los últimos años las pruebas de software han sido potenciadas con increíbles herramientas de automatización que han ganado aceptación, e incluso comienzan a conocerse prácticas en las que se hace uso de herramientas inteligencia artificial para aumentar su eficiencia.
Lo cierto es que el viaje aún no termina, pero como viste, las pruebas de software, pasaron de ser un procedimiento que se hacía al finalizar un producto, luego hicieron parte de una etapa antes de lanzar el software, y en este momento hacen parte esencial de todo el ciclo de vida del software.
En ilana admiramos el sorprendente viaje historico que las pruebas de software han recorrido y nos encanta ser parte de ese viaje en la actualidad, ayudando a nuestros clientes con nuestras pruebas de software, para que sus productos deleiten a sus consumidores finales.
La pregunta correcta no es entonces dónde termina el viaje, sino, ¿Cuánto tiempo más vas a esperar para viajar con nosotros? Agenda una cita ya.