-
Ada Lovelace
La máquina analítica no tiene pretensiones de crear nada. Puede hacer cualquier
cosa que sepamos como ordenarle que realice. -
Alan Turing
Para que la persona que prueba no tenga una tarea muy dificultosa, el programador debe hacer una serie de aserciones definidas que puedan ser comprobadas
individualmente, y de las que se desprende fácilmente la corrección de todo el
programa. -
Daniel D. McCracken
En estos casos es muy conveniente que el cliente prepare el caso de comprobación, sobretodo porque los errores lógicos y los malentendidos entre el programador y el cliente pueden ser señalados por este procedimiento. Si el cliente
debe preparar la solución de la prueba, es mejor que lo haga con anticipación a
la comprobación real, ya que para cualquier problema no trivial se tardará varios
días o semanas en calcular la prueba. -
Charles L. Baker
Publicó en
la revista ”Tablas matemáticas y otros medios de cálculo” una reseña sobre el libro ”Programación de computadores digitales” de Daniel McCracken donde explica la diferencia entre
probar programas y depurarlos. -
Gerald M. Weinberg
En el marco del proyecto Mercurio de la NASA, se aplicó mini-incrementos con
ventanas de tiempo y una técnica que consistía en planificar y escribir las pruebas antes de
cada mini-incremento de desarrollo de software. El doctor en ciencias de la comunicación
estadounidense Gerald M. Weinberg trabajó en el proyecto Mercurio. -
Gerald M. Weinberg
Weinberg y el ingeniero estadounidense Herbert D. Leeds
publican el libro ”Fundamentos de la programación informática” que se convierte en
el primer libro en tener un capítulo dedicado completamente a pruebas de software, donde
plantean los siguientes principios de las pruebas:
1. Escribir el programa correctamente en primer lugar.
2. Pensar en la comprobación al codificar.
3. Conocer las herramientas de depuración disponibles.
4. Hacer que el programa demuestre que funciona. -
Bill Elmendorf
El ingeniero eléctrico estadounidense Bill Elmendorf publica el artículo ”Evaluación de las pruebas funcionales de programas de control” donde se explica por primera vez la necesidad de un enfoque disciplinado para las pruebas funcionales del software. -
Robert W. Bemer
Robert W. Bemer, matemático e ingeniero aeronáutico, asistió a una conferencia de ingeniería de software organizada por la NATO, donde se abordó la garantía de calidad del software. El informe de la conferencia incluyó el documento "Lista de chequeo para planificar la producción de sistemas de software", que planteaba preguntas sobre la utilidad del producto, la metodología de pruebas y la asignación de recursos para la garantía de calidad. -
Robert W. Bemer
el matemático e ingeniero aeronáutico estadounidense Robert W. Bemer participa de la Conferencia de Ingeniería de Software patrocinada por el Comité Científico de la
Organizacion del Tratado del Atlantico Norte (NATO) - por sus siglas en inglés, North Atlantic
Treaty Organization - donde uno de los temas tratados fue la garantía de calidad de software. -
Edsger Dijkstra
Escribió una carta al editor de la revista Communications de la Asociación de Maquinaria Computacional (ACM),
La carta se publicó con el título ”Sentencia Go To considerada perjudicial” [41] y era una crítica el uso excesivo del Go To por parte de los programadores de la época y las dificultades
que esta práctica implicaba para las pruebas. Se considera que esta publicación marcó el
inicio de la programación estructurada. -
Bill Elmendorf
Elmendorf publica el artículo ”Diseño automatizado de librerías de
pruebas de programas” donde propone la aplicación de las pruebas basadas en modelos
para probar software. -
Gerald M. Weinberg
Weinberg publica su libro
clásico ”La psicología de la programación informática” donde resalta el aspecto humano
de la programación -
Edsger Dijkstra
Dijkstra, al recibir el premio Turing, presentó su discurso titulado "El humilde programador", donde enfatizó que para tener programadores más eficaces, es crucial evitar la depuración y la introducción de errores desde el inicio. Señaló que, aunque las pruebas pueden mostrar defectos, no son suficientes para demostrar su ausencia. La única manera efectiva de aumentar la confianza en un programa es proporcionar una prueba convincente de su corrección. -
William C. Hetzel
William C.Hetzel publica el libro ”Métodos de prueba de programas” que contiene una compilación de los artículos presentados en un simposio del mismo nombre llevado a cabo en Chapel Hill, Estados Unidos, donde se expusieron problemas relativos a la validación
y pruebas de software. -
Tom Gilb
Publico el artículo ”Leyes de
la no fiabilidad”. Gilb es uno de los primeros informáticos en conceptualizar la fiabilidad
del sistema y del software, y la relación entre error humano y error de sistema. -
Frederick Brooks
Frederick Brooks publicó "El mítico hombre-mes", que incluye el famoso ensayo "No hay bala de plata". Sus ideas, aún relevantes en entornos ágiles y DevOps, destacan que: Un programa cuesta al menos tres veces más que uno depurado.
Los programadores necesitan casos de prueba adecuados, actuando como adversarios y ayudantes.
La mayor dificultad en el desarrollo de software es la especificación y el diseño, siendo los errores conceptuales más críticos que los de sintaxis. -
Michael E. Fagan
Publico el artículo
”Inspecciones de diseño y código para reducir errores en el desarrollo de programas”
donde propone un proceso sistemático de inspección tanto de diseños como de códigos con
el objetivo de reducir el costo del retrabajo. -
Tom Gilb
Su libro
”Métricas de software” [57], publicado en 1976, se considera un texto de referencia por la
cantidad de métricas que presenta. -
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 el control cuantitativo de
la complejidad de un programa. -
Glenford Myers
Glenford Myers publica el libro
”Fiabilidad del software: Principios y prácticas” en donde proclama: ”El objetivo de los probadores es hacer que el programa falle.” -
William C. Howden
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 referirse a un mecanismo para determinar si una prueba ha pasado
o fallado. -
Glenford Myers
Myers establece la terminología base de las pruebas de
software en uno de los primeros libros que tratan exclusivamente sobre pruebas de software
titulado ”El arte de las pruebas de software” donde introduce el concepto de pruebas
de caja negra. -
Barry W. Boehm
Barry Boehm publica el libro ”Economía
de la ingeniería de software” donde introduce la noción de que el costo de arreglar un
defecto en el software, llamado costo de retrabajo, aumenta conforme pasa el tiempo. -
James Martin
James Martin publica el libro ”Manifiesto de los sistemas de información” donde indica que la distribución
de la 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. -
William C. Hetzel y David Gelperin
Hetzel junto con David Gelperin organizan la Conferencia y
Exposición Internacional sobre Pruebas de Software, que es la primera conferencia enfocada exclusivamente en pruebas de software de la que se tiene registro. -
Paul E. Rook
En el artículo ”Control de proyectos de software”, el científico computacional inglés Paul E. Rook presenta el Modelo V para desarrollo de software -
Robert B. Grady y Deborah L. Caswell
Se publica el libro ”Métricas de software: Establecimiento de un programa para
toda la empresa” donde explican qué son las métricas y cuándo son útiles. Este libro
presenta un estudio detallado de un programa de métricas. -
William C. Hetzel
Hetzel publica el libro ”Guía completa de pruebas de software” que
describe metodologías, técnicas de prueba, y principios de las pruebas de software. -
Cem Kaner, Jack Falk y Hung Q. Nguyen
Se publica el libro ”Pruebas de software informático” que se convirtió en un clásico por su enfoque pragmático. En este libro se utiliza
por primera vez el término prueba exploratoria. -
William C. Hetzel y David Gelperin
Gelperin y
Hetzel publican el artículo ”El crecimiento de las pruebas de software” donde describen
cuatro modelos para pruebas de software:
• Demostración. Demostrar que el software satisface su especificación.
• Destrucción. Detectar 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 -
Watts Humphrey
publica el libro ”Gestión del proceso de software” donde propone el modelo de madurez de las capacidades (CMM) para
mejorar la calidad y productividad del proceso de desarrollo de software. -
Boris Beizer
Propone una clasificación de defectos de software en el libro.. Adicionalmente, Beizer acuña el término ”paradoja del pesticida” para describir el fenómeno de que cuanto más se prueba el software, más inmune se vuelve éste a las pruebas a
las que se le somete. -
Dorothy Graham
Publica el primer ”Reporte sobre pruebas de software asistidas por
computador (CAST)” -
William C. Hetzel y David Gelperin
Gelperin y Hetzel inauguran en Estados Unidos la conferencia ”Revisión, análisis y pruebas
de software” (STAR) - por sus siglas en inglés, ”Software Testing, Analysis, and Review”. -
Robert B. Grady
Grady publica el libro
”Métricas de software prácticas para la gestión de proyectos y la mejora de procesos”
donde presenta una taxonomía de defectos de software elaborada para la empresa HewlettPackard con el objetivo de identificar tendencias de defectos en productos ya terminados y
utilizar esa información para la prevención de defectos en proyectos futuros. -
William C. Hetzel y David Gelperin
Inauguran en Europa la conferencia paralela denominada EuroSTAR. -
Tom Gilb y Dorothy Graham
Publico el libro
”Inspecciones de software” donde se detalla este proceso de revisión formal de software. -
Brian Marick
Publica el libro ”El arte de las
pruebas de software: Pruebas de subsistemas, incluidas las pruebas basadas en objetos y
las orientadas a objetos” donde manifiesta que probar software es un oficio, como la carpintería, que se aprende mejor en persona, viendo cómo lo hace otra persona más experimentada
e intentado hacerlo bajo su supervisión. -
Paul C. Jorgensen
Publica el libro ”Pruebas de software: Un enfoque artesanal” -
R. Geoff Dromey
Propone un modelo de calidad para resolver la intangibilidad de las
características de calidad propuestas en la norma ISO/IEC 9126:1991 ”Ingeniería de Software - Calidad de Producto” -
Robert B. Grady
Grady
publica el libro ”Mejora exitosa de los procesos de software” donde explica como aplicar
el ciclo PDCA a esfuerzos de mejora en el ámbito de software. -
Cem Kaner y James Bach
En la Conferencia y Exposición Internacional sobre Pruebas de Software Informático introducen la
noción de escuelas de pensamiento de las pruebas de software. -
James Bach
Propone el Modelo de Estrategia de Pruebas Heurísticas, que
consiste en un conjunto de patrones para diseñar y elegir las pruebas que se van a realizar
en un proyecto de pruebas de software. -
Dorothy Graham y Mark Fewster
Publica el libro ”Automatización de pruebas de software”, considerado una obra clásica en el ámbito de la automatización de pruebas. -
Cem Kaner
Nace oficialmente la Escuela de Pruebas Dirigidas por el Contexto -
Eric S. Raymond
Publica el libro
”La catedral y el bazar” donde describe el método de desarrollo de software que utilizó
Linus Torvalds para crear el sistema operativo Linux. Raymond detalla 19 pautas para crear
un buen software de código abierto y presenta la llamada Ley de Linus, que afirma:
”Si hay suficientes ojos, todos los errores son superficiales.” -
Jonathan Bach
Publica el artículo ”Gestión de pruebas basada en la sesión”. Una sesión es un bloque ininterrumpido de esfuerzo de prueba con una misión puntual
donde se utiliza pruebas exploratorias y se reportan los resultados al término de la misma. -
Cem Kaner, James Bach, y Bret Pettichord
Publican el libro ”Lecciones aprendidas en pruebas de software: Un enfoque
orientado al contexto” . -
James Bach
Bach crea la
metodología Pruebas Rápidas de Software (RST) alineada a la Escuela de Pruebas Dirigidas por el Contexto. -
Brian Marick
Marick participa como uno de los autores del Manifiesto Ágil. -
Kent Beck
Publica
el libro ”Desarrollo dirigido por pruebas: Mediante el ejemplo” donde ”re-descubre” la
técnica de desarrollo de software que consiste en escribir las pruebas antes escribir el código,
y la denomina Desarrollo Guiado por las Pruebas (TDD) -
Brian Marick
Marick publica una serie de artículos sobre pruebas ágiles, entre ellos el artículo ”Cuadrantes de pruebas ágiles” donde define dos dimensiones para categorizar los tipos
de pruebas: pruebas de cara al negocio versus pruebas de cara a la tecnología; y pruebas
que dan soporte a la programación versus pruebas que critican el producto. -
Bret Pettichord
Participa en
un taller de capacitación en pruebas de software donde expone la conferencia titulada ”Cuatro
escuelas de pruebas de software” y propone la existencia de escuelas de pensamiento en
las pruebas de software, a las que denomina: analítica, dirigida por normas, orientada hacia
la calidad, y dirigida por el contexto. Posteriormente, se incorpora a la lista a la escuela ágil. -
Michael Bolton
Se suma como
co-autor de la metodología RST creada por James Bach. -
Watts Humphrey
Humphrey publica el libro ”PSP, un proceso de auto-superación para ingenieros de software”
donde describe un proceso personal de software (PSP) donde reduce las prácticas de software industrial para adaptarlas a las
necesidades del desarrollo de programas de tamaño modular. -
Erik Van Veenendaal
Crea la Fundación TMMI con el objetivo de desarrollar el Modelo
de Madurez de Pruebas Integrado TMMI -
Watts Humphrey
Humphrey publica el
libro ”TSP, Dirigiendo un equipo de desarrollo” donde explica cómo liderar a equipos de
ingenieros de software formados en PSP utilizando un proceso de software en equipo (TSP). -
Dorothy Graham, Erik Van Veenendaal, Isabel Evans, y Rex Black
Publican el libro ”Fundamentos de las pruebas de software: Certificación ISTQB” donde se describe el programa de estudios para la certificación de nivel básico de pruebas del Comité
Internacional de Cualificaciones de Pruebas de Software (ISTQB) -
Doron Reuveni y Roy Solomon
Publica el libro ”Guía esencial de crowdtesting”. El término crowdtesting surgió del término crowdsourcing que fue acuñado en 2006, por
Jeff Howe y Mark Robinson, para describir la externalización de parte de las actividades de
las organizaciones a grupos de voluntarios. Crowtesting se basa en el enfoque de pruebas
en el medio natural en lugar del laboratorio de calidad o la organización desarrolladora, buscando incluir la mayor cantidad de contextos de usos y dispositivos. -
Jonathan Bach
Propone la escala de libertad del probador. Esta escala modela la variación en el
grado de libertad que tiene un probador cuando realiza pruebas, y va desde ”Completamente
guiado” hasta ”Estilo libre exploratorio”. En palabras de Bach, la escala modela el grado en
que se nos permite pensar. -
Lisa Crispin y Janeth Gregory
Publican el libro ”Pruebas ágiles: Una guía práctica para probadores y equipos
ágiles” que incluye un capítulo sobre pruebas exploratorias escrito con el apoyo de Michael Bolton. -
Michael Bolton
Su artículo ”Probando
vs. comprobando”, Bolton distingue entre estos dos conceptos. Para Bolton, comprobar
es confirmar, verificar, y validar utilizando herramientas automáticas, mientras que probar es el proceso de exploración, descubrimiento, investigación, y aprendizaje realizado por los
probadores. -
Mike Cohn
Publica el libro ”Triunfando con la agilidad” donde propone la
pirámide de automatización de pruebas. En este modelo, Cohn argumenta que una estrategia
de automatización de pruebas eficaz requiere la automatización de pruebas en tres niveles:
unidad, servicio, e interfaz de usuario. -
Gerald M. Weinberg
Weinberg publica el libro ”Software perfecto y otras ilusiones sobre las pruebas” donde sostiene que las pruebas son necesarias porque las personas no somos
perfectas, pero el hecho de probar más, no garantiza una mayor calidad -
Jonathan Kohl
Contribuye con
el capítulo ”La automatización es mucho más que pruebas de regresión: Pensando fuera
de la caja” que forma parte del libro ”Experiencias de automatización de pruebas: Casos
prácticos de automatización de pruebas de software” escrito por Dorothy Graham y Mark
Fewster. -
Lisa Crispin y Janeth Gregory
Publicaron otro texto importante en el mismo ámbito,
titulado ”Más pruebas ágiles: Viajes de aprendizaje para todo el equipo”. Este libro abarca la adaptación de las pruebas ágiles a entornos y equipos, el aprendizaje a partir de la
experiencia, y la mejora continua de los procesos de prueba. -
Paul C. Jorgensen y Byron DeVries
Jorgensen publica la quinta edición
en conjunto con Byron DeVries. Las ediciones de este libro se han convertido en referencia
de las tecnologías en evolución en el ámbito de las pruebas de software