-
La máquina analítica no tiene pretensiones de crear nada. Puede hacer cualquier cosa que sepamos como ordenarle que realice. -
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. -
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. -
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. -
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. -
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. -
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, 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. -
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. -
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.
-
Weinberg publica su libro clásico ”La psicología de la programación informática” donde resalta el aspecto humano de la programación
-
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 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. -
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 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. -
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. -
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 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 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 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. -
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 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 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. -
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.
-
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 -
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. -
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. -
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.
-
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. -
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. -
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. -
Publica el primer ”Reporte sobre pruebas de software asistidas por computador (CAST)” -
Gelperin y Hetzel inauguran en Estados Unidos la conferencia ”Revisión, análisis y pruebas de software” (STAR)
-
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.
-
Inauguran en Europa la conferencia paralela denominada EuroSTAR.
-
Publico el libro ”Inspecciones de software” donde se detalla este proceso de revisión formal de software.
-
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. -
Publica el libro ”Pruebas de software: Un enfoque artesanal” -
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” -
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.
-
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.
-
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. -
Publica el libro ”Automatización de pruebas de software”, considerado una obra clásica en el ámbito de la automatización de pruebas.
-
Nace oficialmente la Escuela de Pruebas Dirigidas por el Contexto
-
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.” -
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. -
Publican el libro ”Lecciones aprendidas en pruebas de software: Un enfoque
orientado al contexto”. -
Bach crea la metodología Pruebas Rápidas de Software (RST) alineada a la Escuela de Pruebas Dirigidas por el Contexto.
-
Marick participa como uno de los autores del Manifiesto Ágil.
-
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) -
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.
-
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. -
Se suma como co-autor de la metodología RST creada por James Bach. -
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.
-
Crea la Fundación TMMI con el objetivo de desarrollar el Modelo de Madurez de Pruebas Integrado TMMI -
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).
-
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)
-
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. -
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. -
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.
-
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. -
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. -
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 -
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. -
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.
-
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