-
Ada Lovelace
En la década de 1840, Augusta Ada Byron, condesa de Lovelace, tradujo al inglés un artículo sobre el "motor analítico" de Charles Babbage, escrito originalmente por Luigi Menabrea. Durante esta traducción, incluyó notas que superaban en extensión al texto original, y añadió un algoritmo destinado al cálculo de los números de Bernoulli utilizando el motor analítico, lo cual es considerado el primer programa de computación. -
Alan Turing
Alan Turing, uno de los padres de la computación, escribió el artículo "Sobre la comprobación de una rutina grande", donde se preguntó cómo asegurar la corrección de un programa. Propuso un método general de verificación que aún se utiliza hoy, y subrayó que quien prueba el programa debe ser diferente de quien lo programa. Además, sugirió que el programador debe hacer aserciones claras que faciliten la verificación del programa completo. -
Charles L. Baker
Charles L. Baker publicó una reseña sobre el libro "Programación de computadores digitales" de Daniel McCracken, donde destacó la diferencia entre probar programas y depurarlos. A principios de los años 50, no se distinguía entre estas dos actividades, y los desarrolladores se centraban en corregir defectos, depurando el código cuando encontraban problemas. En ese momento, el concepto de pruebas de software y probadores aún no existía. -
Daniel D. McCracken
Daniel D. McCracken publicó "Programación de computadores digitales", el primer libro sobre programación, donde recomendaba que el cliente preparara los casos de prueba. Este enfoque permitía identificar errores lógicos y malentendidos entre el programador y el cliente. Además, McCracken sugirió que el cliente preparara la solución de la prueba con anticipación, ya que su cálculo podría llevar varios días o semanas para problemas complejos. -
Gerald M. Weinberg
Durante el proyecto Mercurio de la NASA, se introdujo una técnica de mini-incrementos en el desarrollo de software, planificando y escribiendo pruebas antes de cada incremento. Basado en esta experiencia, Gerald M. Weinberg y Herbert D. Leeds publicaron en 1961 "Fundamentos de la programación informática". Ahí expusieron principios clave: escribir el programa correctamente, considerar las pruebas al codificar, conocer las herramientas de depuración y hacer que el programa demuestre que funciona. -
Bill Elmendorf
Bill Elmendorf publicó el artículo "Evaluación de las pruebas funcionales de programas de control", donde introdujo por primera vez la necesidad de un enfoque disciplinado para las pruebas funcionales de software. Más tarde, en 1970, publicó "Diseño automatizado de librerías de pruebas de programas", proponiendo la aplicación de pruebas basadas en modelos para evaluar software. -
Robert W. Bemer
Bemer participó en la Conferencia de Ingeniería de Software, donde se abordó la garantía de calidad del software. El informe incluyó el documento "Lista de chequeo para planificar la producción de sistemas de software", con preguntas clave sobre si el producto ha sido probado para garantizar su utilidad, si las pruebas siguen el mismo ciclo que el software evaluado, y si se asigna una persona a la garantía de calidad por cada diez en producción. -
Edsger Dijkstra
Dijkstra recibió el Premio Turing por sus contribuciones a la informática. En su discurso, destacó que para mejorar la eficacia de los programadores, es esencial evitar la introducción de errores en lugar de perder tiempo depurando. Aunque las pruebas son útiles para detectar defectos, no garantizan la ausencia de errores. Por ello, subrayó la necesidad de pruebas convincentes que validen la corrección del programa y aumenten la confianza en su funcionamiento. -
Tom Gilb
Tom Gilb publica el artículo "Leyes de la no fiabilidad", siendo uno de los primeros en abordar la fiabilidad del sistema y la relación entre el error humano y el error de sistema. Su libro Métricas de software, publicado en 1976, se considera un texto de referencia por sus diversas métricas. En 1993, junto con Dorothy Graham, publica Inspecciones de software, que detalla el proceso de revisión formal de software. -
Frederick Brooks
Frederick Brooks publica El mítico hombre-mes, que incluye ensayos sobre ingeniería de software, destacando el famoso "No hay bala de plata". Entre sus afirmaciones sobre pruebas de software, destaca que:
Un programa cuesta al menos tres veces más que uno depurado.
El programador requiere un banco de casos de prueba, y el probador actúa como adversario y colaborador en su creación.
La dificultad principal en el desarrollo de software radica en la especificación, diseño y pruebas de conceptos. -
Glenford Myers
Glenford Myers publica Fiabilidad del software: Principios y prácticas, afirmando que "el objetivo de los probadores es hacer que el programa falle". En 1979, presenta El arte de las pruebas de software, uno de los primeros libros dedicados exclusivamente a este tema, donde establece la terminología básica de las pruebas de software e introduce el concepto de pruebas de caja negra. -
Thomas J. McCabe
Thomas McCabe publica el artículo "Una medida de la complejidad", donde introduce la complejidad ciclomática como métrica de software para cuantificar la complejidad de un programa. Esta métrica, basada en la teoría de grafos, considera la estructura del programa sin depender de su tamaño o del lenguaje de programación. McCabe también propone la prueba de ruta básica como técnica de prueba de caja blanca. -
Michael E. Fagan
Michael E. Fagan publica el artículo "Inspecciones de diseño y código para reducir errores en el desarrollo de programas", proponiendo un proceso sistemático de inspección para diseños y códigos con el fin de disminuir el costo del retrabajo. IBM implementó estas inspecciones, logrando importantes mejoras en la calidad, casi duplicando la producción de líneas de código y reduciendo en dos tercios el número de defectos por cada mil líneas. -
William C. Howden
En 1978, el matemático y doctor en ciencias de la computación William C. Howden publica
el artículo ”Estudios teóricos y empíricos sobre la comprobación de programas” donde acuña
el término oráculo para refererirse a un mecanismo para determinar si una prueba ha pasado
o fallado. -
Barry W. Boehm
Barry Boehm publica Economía de la ingeniería de software, donde introduce la idea de que el costo de arreglar un defecto en el software, conocido como costo de retrabajo, aumenta con el tiempo. Boehm presenta un gráfico que muestra las fases del ciclo de vida del software en el eje horizontal y el costo relativo de corregir un defecto en diferentes fases en el eje vertical. -
James Martin
James Martin publica Manifiesto de los sistemas de información, donde señala que la distribución de inserción de defectos en un proyecto de software es la siguiente: 56% de los defectos se introducen durante la fase de requisitos, 27% durante el diseño y 7% durante la codificación. -
Paul E. Rook
Paul E. Rook presenta en su artículo "Control de proyectos de software" el Modelo V para el desarrollo de software, que propone un enfoque estructurado para las pruebas. Este modelo se convierte en una alternativa al Modelo Cascada, asociando cada fase del ciclo de vida del desarrollo con su correspondiente fase de pruebas: requerimientos con pruebas de aceptación, diseño de sistema con pruebas de sistemas, diseño de software con pruebas de integración, y pruebas de unidad. -
Robert B. Grady
Robert B. Grady y Deborah L. Caswell publican Métricas de software: Establecimiento de un programa para toda la empresa, donde explican las métricas y su utilidad, además de detallar un programa de métricas. En 1992, Grady publica Métricas de software prácticas para la gestión de proyectos y la mejora de procesos, que incluye una taxonomía de defectos de software para Hewlett-Packard, destinada a identificar tendencias de defectos y prevenirlos en proyectos futuros. -
William C. Hetzel y David Gelperin
Gelperin y
Hetzel publican el artículo ”El crecimiento de las pruebas de software”, donde presentan cuatro modelos de pruebas: Demostración: Verificar que el software cumple con su especificación.
Destrucción: Identificar fallos de implementación.
Evaluación: Detectar defectos en requisitos, diseño e implementación.
Prevención: Evitar defectos en requisitos, diseño e implementación.