-
- Tradujo el artículo "Boceto del motor analítico inventado por Charles Babbage", en notas anexó un algoritmo para utilizar la máquina analítica para el cálculo de números de Bernoulli.
- Dicho algoritmo es considerado el primer programa de computación.
- Lovelace es fue la primera en envisionar el potencial futuro de las computadoras y el software.
- Se dio cuenta de que un funcionamiento equivocado puede deberse no necesariamente al hardware sino también a defectos de programación.
-
-
¿Cómo se puede comprobar una rutina en el sentido de asegurarse que es correcta?
Para responde a esto, Turing propone un método general de prueba que todavía es la base de la verificación de programas.
También señala que la persona que prueba debe ser distinta a la persona que programa.
Un poco más sobre Alan Turing. -
-
- Publica el libro “Programación de computadores digitales” considerado el primer texto sobre programación.
- En el libro hace referencia a las pruebas señalando que el cliente debe preparar el caso de comprobación y así poder señalar errores lógicos y malentendidos entre el cliente y el programador.
-
- Publicó en la revista “Tablas matemáticas y otros medios de cálculo” una reseña sobre el libro de Daniel McCracken donde explica la diferencia entre probar programas y depurarlos.
- Los desarrolladores solían escribir el código y, cuando se encontraban con un defecto, analizaban y depuraban los problemas.
-
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. -
En base a la experiencia en el proyecto, Weinberg y el ingeniero estadounidense Herbert D. Leeds publican el libro “Fundamentos de la programación informática” que es 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.
2. Pensar en la comprobación al codificar.
3. Conocer las herramientas de depuración disponibles.
4. Hacer que el programa demuestre que funciona. -
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. -
- Participa de la Conferencia de Ingeniería de Software, donde uno de los temas tratados fue la garantía de calidad de software.
- El informe de la conferencia incluyó el documento “Lista de chequeo para planificar la producción de sistemas de software” en el cual se dedica una sección a la garantía de la calidad de software.
-
- Se publicó su carta que criticaba el uso excesivo del Go To porque implicaba dificultades para las pruebas, esto marcó el inicio de la programación estructurada.
- En 1972, recibe el premio Turing y en su discurso menciona que los programadores no deben perder el tiempo depurando, sino que deben evitar los errores desde un principio.
-
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. -
Publica su libro clásico ”La psicología de la programación informática” donde resalta el aspecto humano de la programación.
-
-
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, donde se expusieron problemas relativos a la validación y pruebas de software. -
Publica su obra clásica “El mítico hombre-mes”, este libro contiene un conjunto de ensayos sobre ingeniería de software. -
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. -
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. -
- Introduce la complejidad ciclomática como métrica de software para el control cuantitativo de la complejidad de un programa.
- Propuso la prueba de ruta básica como una técnica de prueba de caja blanca.
-
Acuña el término oráculo para referirse a un mecanismo para determinar si una prueba ha pasado o fallado. -
Establece la terminología base de las pruebas de
software en un libro titulado “El arte de las pruebas de software” donde introduce el concepto de pruebas de caja negra. -
Introduce la noción de que el costo de arreglar un defecto en el software, llamado costo de retrabajo, aumenta conforme pasa el tiempo. -
-
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. -
Presenta el Modelo V para la creación de software, donde introduce un enfoque estructurado para las pruebas. -
Publica, en conjunto con Deborah L. Caswell, 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. -
- Publican el artículo “El crecimiento de las pruebas de software” donde describen cuatro modelos para pruebas de software.
- 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.
-
- Se publica el libro “Pruebas de software informático”, que se convirtió en un clásico por su enfoque pragmático.
- Se utiliza por primera vez el término prueba exploratoria.
- Kaner ha aportado además con leyes en Estados Unidos para el licenciamiento de software, regulación de la calidad de software, y comercio electrónico.
-
- Es considerado el padre de la calidad de software por sus contribuciones a la mejora del proceso de software.
- Es el fundador del programa de procesos de software del Instituto de Ingeniería de Software
- 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 “Técnicas de pruebas de software”.
- 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.
-
Unicom publica el primer “Reporte sobre pruebas de software asistidas por computador (CAST)” escrito por la consultora en pruebas de software Dorothy Graham. -
-
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 Hewlett-Packard 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.
-
- 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.
- Se enfoca en subsistemas de tamaño medio, tales como controladores de dispositivos, bibliotecas de clases, módulos de optimización en compiladores, entre otros.
-
- Publica el libro “Pruebas de software: Un enfoque artesanal”.
- En 2022, 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.
-
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.
-
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” -
- 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.
- El propósito es enfatizar que la selección de técnicas o heurísticas de prueba a utilizar debe tomar en cuenta el ambiente del proyecto, los elementos del producto, y los criterios de calidad.
-
Publica en conjunto con Mark Fewster el libro “Automatización de pruebas de software”, considerado una obra clásica en el ámbito de la automatización de pruebas.
-
- Describe el método de desarrollo de software que utilizó Linus Torvalds para crear el sistema operativo Linux.
- Presenta la llamada Ley de Linus, implica que cuanto más públicamente disponible esté el código fuente de un software para su comprobación, escrutinio, y experimentación por parte una base grande de probadores y desarrolladores, más rápidamente se descubrirán, caracterizarán, y solucionarán los defectos presentes en dicho software.
-
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.
-
Participa como uno de los autores del Manifiesto
Ágil. -
Crea la metodología Pruebas Rápidas de Software (RST) alineada a la Escuela de Pruebas Dirigidas por el Contexto.
-
-
- “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).
- También contribuye con los patrones de software, la familia de herramientas de pruebas unitarias xUnit , y la programación extrema (XP).
-
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.
-
- 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.
- Se incorpora a la lista a la escuela ágil.
-
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 “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, sirve para evaluar y mejorar el proceso de pruebas de las organizaciones y se basa en su predecesor, el modelo TMM desarrollado en 1996 en el Instituto de Tecnología de Illinois. -
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).
-
Publica en conjunto con Erik Van Veenendaal, Isabel Evans, y Rex Black 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).
-
- Publica el libro “Guía esencial de crowdtesting”.
- Crowdtesting 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.
-
Propone la escala de libertad del probador, modela el grado en que se nos permite pensar.
-
- Propone la “pirámide de automatización de pruebas”.
- 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.
-
Publica, en conjunto con Janeth Gregory, 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.
Este libro es considerado pionero en la disciplina de las pruebas ágiles. -
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.
-
- Propone utilizar la automatización para llevar a cabo tareas tales como configuración de pruebas, generación de datos, y avance a lo largo de un flujo de trabajo.
- Además, propone la utilización de pruebas exploratorias manuales para encontrar aquellos defectos insidiosos que de otro modo escaparían a la atención de los probadores.
-
Crispin y Gregory publicaron otro texto importante en el mismo ámbito, titulado “Más pruebas ágiles: Viajes de aprendizaje para todo el equipo”, 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.