Evolución de la Calidad de Software

  • Period: to

    Periodo 1

  • Ada Lovelace

    Ada Lovelace
    Matemática y escritora inglesa, es considerada la autora del primer programa de computación, al diseñar un algoritmo para la máquina analítica de Charles Babbage. Lovelace fue la primera en anticipar el potencial del software y los errores de programación, destacando la importancia de las instrucciones correctas para el funcionamiento de las máquinas.
  • Alan Turing

    Alan Turing
    Matemático y científico pionero de la computación, propuso un método general para la verificación de programas, base de la prueba de software actual. Turing sugirió que la persona que prueba debe ser diferente de quien programa y que los programadores deben hacer aserciones claras para facilitar la comprobación de la corrección del programa.
  • Period: to

    Periodo 2

  • Daniel D. McCracken

    Daniel D. McCracken
    Científico computacional y autor del primer libro sobre programación, destacó la importancia de que el cliente prepare los casos de prueba para detectar errores lógicos y malentendidos entre el programador y el cliente, señalando que las soluciones de prueba deben prepararse con antelación.
  • Charles L. Baker

    Charles L. Baker
    Físico e ingeniero aeroespacial, destacó la diferencia entre probar y depurar programas, una distinción que no existía al inicio de los años 50. Antes, los desarrolladores se enfocaban en corregir defectos sin separar formalmente las pruebas de la depuración.
  • Gerald M. Weinberg

    Gerald M. Weinberg
    Pionero en la teoría de pruebas de software, coescribió el primer libro que dedicaba un capítulo completo a las pruebas de software, estableciendo principios clave como pensar en la comprobación al codificar. Resaltó la importancia de las pruebas automáticas y el enfoque en la adaptabilidad del software. En 1971enfatizó el aspecto humano de la programación, y en 2010, argumentó que las pruebas no garantizan calidad perfecta, pero son esenciales debido a la imperfección humana.
  • Bill Elmendorf

    Bill Elmendorf
    Ingeniero eléctrico que en introdujo la necesidad de un enfoque disciplinado para las pruebas funcionales de software. En 1970, Elmendorf propuso el uso de pruebas basadas en modelos para automatizar la validación del software, marcando un avance clave en el desarrollo de técnicas de pruebas más estructuradas.
  • Robert W. Bemer

    Robert W. Bemer
    Matemático e ingeniero, en 1968 participó en la Conferencia de Ingeniería de Software organizada por la NATO, donde se discutió la garantía de calidad de software. Contribuyó al desarrollo de un enfoque sistemático para garantizar la calidad mediante una lista de chequeo, que planteaba preguntas clave sobre la utilidad, el ciclo de producción y los recursos asignados a las pruebas de software.
  • Edsger Dijkstra

    Edsger Dijkstra
    Físico y matemático, es conocido por su crítica al uso excesivo del "Go To", argumentando en 1968 que complicaba las pruebas, lo que marcó el inicio de la programación estructurada. En su discurso tras recibir el Premio Turing en 1972, destacó que las pruebas solo demuestran la presencia de errores, no su ausencia, y que la única manera efectiva de garantizar la confianza en un programa es probar su corrección desde el principio.
  • Period: to

    Periodo 3

  • William C. Hetzel y David Gelperin

    William C. Hetzel y David Gelperin
    En 1973, Hetzel publicó un libro pionero sobre métodos de prueba de software, y en 1984, junto con Gelperin, organizaron la primera conferencia dedicada exclusivamente a pruebas de software. En 1988, ambos propusieron cuatro modelos de pruebas (demostración, destrucción, evaluación y prevención). Hetzel publicó una guía completa sobre pruebas de software y ambos fundaron conferencias internacionales clave como STAR y EuroSTAR, promoviendo el avance de las pruebas de software a nivel global.
  • Frederick Brooks

    Frederick Brooks
    Científico computacional, publicó "El mítico hombre-mes", una obra sobre ingeniería de software que incluye el ensayo "No hay bala de plata". Enfatizó que el costo de un programa es al menos tres veces mayor que el de un programa depurado, y que los probadores juegan un papel dual como adversarios y aliados. Afirmó que la parte más difícil del desarrollo de software está en la especificación, diseño y pruebas, señalando que los errores conceptuales son más significativos que los de sintaxis.
  • Tom Gilb

    Tom Gilb
    Ingeniero de sistemas, en 1975 publicó el artículo "Leyes de la no fiabilidad", donde abordó la fiabilidad del sistema y su relación con el error humano. Su libro "Métricas de software", lanzado en 1976, se convirtió en un texto fundamental por su extenso análisis de métricas. En 1993, junto con Dorothy Graham, publicó "Inspecciones de software", que describe el proceso de revisión formal de software, contribuyendo significativamente a las prácticas de aseguramiento de calidad en la industria.
  • Michael E. Fagan

    Michael E. Fagan
    Físico e ingeniero eléctrico, en 1976 publicó "Inspecciones de diseño y código para reducir errores en el desarrollo de programas", donde propuso un proceso sistemático de inspección de diseños y códigos para minimizar el costo del retrabajo. IBM implementó sus métodos, logrando mejoras significativas en la calidad, duplicando la producción de líneas de código mientras reducía en dos tercios el número de defectos por cada mil líneas.
  • Thomas J. McCabe

    Thomas J. McCabe
    En 1976, McCabe publicó "Una medida de la complejidad", introduciendo la complejidad ciclomática como métrica para evaluar cuantitativamente la complejidad de un programa, independientemente de su tamaño o lenguaje. También propuso la prueba de ruta básica, una técnica de prueba de caja blanca, que se centra en la estructura del programa para mejorar la calidad y efectividad de las pruebas de software.
  • Glenford Myers

    Glenford Myers
    Ingeniero eléctrico y científico computacional, en 1976 publicó "Fiabilidad del software: Principios y prácticas", donde afirmaba que "el objetivo de los probadores es hacer que el programa falle". En 1979, Myers estableció la terminología fundamental de las pruebas de software en "El arte de las pruebas de software", donde introdujo el concepto de pruebas de caja negra, marcando un hito en el enfoque de validación de software.
  • William C. Howden

    William C. Howden
    Matemático y doctor en ciencias de la computación, en 1978 publicó "Estudios teóricos y empíricos sobre la comprobación de programas", donde introdujo el término "oráculo" para describir un mecanismo que determina si una prueba ha pasado o fallado. Este concepto ha sido fundamental en el desarrollo de metodologías de prueba de software.
  • Barry W. Boehm

    Barry W. Boehm
    Matemático y científico computacional, en 1981 publicó "Economía de la ingeniería de software", destacando que el costo de arreglar un defecto en el software aumenta con el tiempo. Introdujo un gráfico que ilustra cómo el costo de corregir errores varía a lo largo del ciclo de vida del software, siendo más alto en etapas posteriores. Presentó el Modelo de Costos Constructivos (COCOMO), un método para estimar el costo de desarrollo de software, que ha sido ampliamente utilizado en la industria.
  • James Martin

    James Martin
    Físico y consultor de tecnologías de información, en 1984 publicó "Manifiesto de los sistemas de información", donde analizó la distribución de la inserción de defectos en proyectos de software, señalando que el 56% de los defectos se introducen en la fase de requisitos, el 27% en el diseño y el 7% en la codificación. Su trabajo subrayó la importancia de prestar atención a las primeras fases del desarrollo para mejorar la calidad del software.
  • Paul E. Rook

    Paul E. Rook
    Científico computacional inglés, en 1986 publicó "Control de proyectos de software", donde presentó el Modelo V. Este modelo asocia cada fase del ciclo de vida del desarrollo con una fase de pruebas correspondiente: requerimientos con pruebas de aceptación, diseño de sistema con pruebas de sistemas, diseño de software con pruebas de integración y diseño de componentes con pruebas de unidad. Su enfoque enfatiza la importancia de las pruebas en cada etapa del desarrollo.
  • Robert B. Grady

    Robert B. Grady
    Ingeniero eléctrico estadounidense, en 1987 publicó "Métricas de software" junto a Deborah L. Caswell, donde definieron las métricas y su utilidad. En 1992, en "Métricas de software prácticas", introdujo una taxonomía de defectos de software para Hewlett-Packard, enfocada en prevenir defectos en futuros proyectos. En 1996, en "Mejora exitosa de los procesos de software", explicó cómo aplicar el ciclo PDCA para mejorar procesos en el desarrollo de software.
  • Cem Kaner

    Cem Kaner
    Matemático, abogado y psicólogo estadounidense, coautor de "Pruebas de software informático" (1988), donde introdujo el término "prueba exploratoria". En 1996, presentó las escuelas de pensamiento en pruebas de software con James Bach, y en 1999 se estableció la Escuela de Pruebas Dirigidas por el Contexto. También coescribió "Lecciones aprendidas en pruebas de software" (2001) y ha contribuido a la legislación sobre calidad y licenciamiento de software en EE. UU.
  • Watts Humphrey

    Watts Humphrey
    Físico y administrador estadounidense, considerado el padre de la calidad de software. Fundador del programa de procesos de software del SEI en Carnegie Mellon. En 1989, publicó "Gestión del proceso de software", introduciendo el modelo de madurez de capacidades (CMM). En 2005, presentó el "Personal Software Process" (PSP) y en 2006, el "Team Software Process" (TSP) para dirigir equipos de desarrollo.
  • Boris Beizer

    Boris Beizer
    En 1990, el físico e ingeniero belga Boris Beizer publicó "Técnicas de pruebas de software", donde clasificó los defectos de software. Introdujo la "paradoja del pesticida", que describe cómo, al probar el software repetidamente, se vuelve más resistente a las pruebas que se le aplican.
  • Dorothy Graham

    Dorothy Graham
    En 1991, Dorothy Graham publicó el primer "Reporte sobre pruebas de software asistidas por computador (CAST)". En 1999, coescribió "Automatización de pruebas de software", un texto clásico en la automatización de pruebas. En 2006, junto a otros autores, publicó "Fundamentos de las pruebas de software: Certificación ISTQB", que aborda el programa de certificación en pruebas. En 2017, tuvo la oportunidad de conocer a Graham en el 7mo Congreso Mundial de Calidad de Software en Lima, Perú.
  • Brian Marick

    Brian Marick
    En 1994, Brian Marick publicó "El arte de las pruebas de software", comparando probar software con carpintería, sugiriere que se aprende mejor mediante la supervisión de expertos. El libro se centra en subsistemas de tamaño medio. En 2001, Marick fue uno de los autores del Manifiesto Ágil. En 2003, publicó "Cuadrantes de pruebas ágiles", donde categoriza los tipos de pruebas en dos dimensiones: orientadas al negocio frente a tecnológicas, y apoyo a la programación frente a críticas del producto.
  • Paul C. Jorgensen

    Paul C. Jorgensen
    En 1995, publica "Pruebas de software: Un enfoque artesanal", que se ha convertido en una referencia clave en el campo. En 2022, lanzó la quinta edición junto con Byron DeVries, actualizando el contenido para reflejar las tecnologías en evolución en pruebas de software.
  • R. Geoff Dromey

    R. Geoff Dromey
    En 1996 en su artículo "Acorralando a la quimera", propone un modelo de calidad para abordar la intangibilidad de las características de calidad establecidas en la norma ISO/IEC 9126:1991, que se centra en la calidad del producto en ingeniería de software.
  • James Bach

    James Bach
    En 1996, introduce el Modelo de Estrategia de Pruebas Heurísticas, que consiste en patrones para diseñar y seleccionar pruebas en proyectos de software, enfatizando que las técnicas elegidas deben considerar el ambiente del proyecto y los criterios de calidad. En 2001, crea la metodología Pruebas Rápidas de Software (RST), alineada con la Escuela de Pruebas Dirigidas por el Contexto.
  • Eric S. Raymond

    Eric S. Raymond
    En 1999, publica "La catedral y el bazar", donde describe el método de desarrollo de software de Linus Torvalds para el sistema operativo Linux. Raymond detalla 19 pautas para crear software de código abierto y presenta la Ley de Linus: "Si hay suficientes ojos, todos los errores son superficiales." Esta ley sugiere que un mayor escrutinio del código fuente por parte de muchos usuarios acelera la detección y solución de defectos en el software.
  • Jonathan Bach

    Jonathan Bach
    En 2000, publica el artículo "Gestión de pruebas basada en la sesión", donde define una sesión como un bloque ininterrumpido de pruebas exploratorias con un objetivo específico. En 2007, propone la escala de libertad del probador, que mide el grado de autonomía que tiene un probador, desde "completamente guiado" hasta "estilo libre exploratorio", enfatizando la importancia de la libertad de pensamiento en el proceso de prueba.
  • Period: to

    Periodo 4

  • Kent Beck

    Kent Beck
    En 2002, publica Desarrollo dirigido por pruebas: Mediante el ejemplo, donde redescubre y denomina la técnica de escribir pruebas antes del código como Desarrollo Guiado por Pruebas (TDD). Beck también contribuye a patrones de software, a la herramienta de pruebas unitarias xUnit y a la programación extrema (XP).
  • Bret Pettichord

    Bret Pettichord
    En 2003, presenta la conferencia Cuatro escuelas de pruebas de software, donde propone varias escuelas de pensamiento en las pruebas: analítica, dirigida por normas, orientada hacia la calidad y dirigida por el contexto. Posteriormente, se añade la escuela ágil a esta lista.
  • Michael Bolton

    Michael Bolton
    En 2004, se convierte en coautor de la metodología de Pruebas Rápidas de Software (RST) creada por James Bach. En 2009, en su artículo Probando vs. comprobando, Bolton diferencia entre ambos términos: "comprobar" implica la verificación mediante herramientas automáticas, mientras que "probar" se refiere a un proceso de exploración, descubrimiento e investigación llevado a cabo por los probadores.
  • Erik Van Veenendaal

    Erik Van Veenendaal
    En 2005, Erik Van Veenendaal y otros expertos fundan la Fundación TMMI para desarrollar el Modelo de Madurez de Pruebas Integrado (TMMI). Este modelo evalúa y mejora los procesos de pruebas en organizaciones, basándose en el modelo TMM creado en 1996 en el Instituto de Tecnología de Illinois.
  • Doron Reuveni

    Doron Reuveni
    En 2007, Doron Reuveni y Roy Solomon publican "Guía esencial de crowdtesting", introduciendo el término "crowdtesting", derivado del "crowdsourcing" acuñado en 2006. Este enfoque se centra en realizar pruebas en el entorno natural en lugar de en laboratorios, buscando abarcar diversos contextos de uso y dispositivos mediante la participación de grupos de voluntarios.
  • Mike Cohn

    Mike Cohn
    En 2009, publica Triunfando con la agilidad, donde introduce la pirámide de automatización de pruebas. Este modelo sugiere que una estrategia de automatización efectiva debe abarcar tres niveles: pruebas de unidad, pruebas de servicio y pruebas de interfaz de usuario.
  • Lisa Crispin

    Lisa Crispin
    En 2009, Lisa Crispin, junto a Janeth Gregory, publica "Pruebas ágiles: Una guía práctica para probadores y equipos ágiles", un texto pionero en pruebas ágiles que incluye un capítulo sobre pruebas exploratorias con la colaboración de Michael Bolton. En 2014, ambas autoras lanzan "Más pruebas ágiles: Viajes de aprendizaje para todo el equipo", que trata sobre la adaptación de pruebas ágiles en diferentes entornos y equipos, enfatizando el aprendizaje continuo y la mejora de procesos de prueba.
  • Jonathan Kohl

    Jonathan Kohl
    En 2012, contribuye con el capítulo “La automatización es mucho más que pruebas de regresión: Pensando fuera de la caja” en el libro “Experiencias de automatización de pruebas”, escrito por Dorothy Graham y Mark Fewster. Kohl sugiere usar la automatización para tareas como configuración de pruebas y generación de datos, y aboga por la prueba exploratoria manual para detectar defectos que podrían pasar desapercibidos.