-
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. -
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. -
Daniel D. McCracken
En estos casos es muy conveniente que el cliente prepare el caso de comprobación, sobre todo 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. -
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. -
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” 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. -
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
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. -
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) -
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) -
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. -
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. -
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. -
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. -
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