Setenta años de historia del testing en un artículo: las cinco visiones que transformaron la disciplina, terminología ISTQB (error, falla, defecto), el modelo de calidad McCall con sus 11 factores, la norma ISO 9126 y los cinco principios fundamentales del tester profesional.
Durante décadas, el testing de software fue visto como una actividad menor: algo que hacían los programadores al final del proceso, casi como un trámite. Hoy sabemos que esa visión no solo era incorrecta, sino costosa. La historia del testing es la historia de cómo la industria aprendió a tomarse en serio la calidad del software.
Si le preguntamos a diez profesionales qué es hacer pruebas, obtenemos diez respuestas distintas: encontrar errores, adquirir confianza, verificar el funcionamiento, asegurar la satisfacción del cliente. Todas son aproximaciones correctas, pero ninguna captura la complejidad real de la disciplina.
La definición más abarcadora es la de Bill Hetzel (1988): el testing es cualquier actividad orientada a evaluar un atributo o capacidad de un programa y determinar si alcanza los resultados requeridos. Esta definición introduce el concepto de calidad como cumplimiento de requisitos — el corazón de la disciplina moderna.
La disciplina puede rastrearse desde los primeros programas escritos. Cada era produjo una visión diferente de qué significa probar software.
En los primeros años de la computación, las pruebas y el debugging eran la misma cosa. Si un programa fallaba, el programador buscaba el error y lo corregía. No había distinción conceptual entre encontrar un problema y solucionarlo. La prueba era una extensión directa de la programación.
Tras la primera conferencia formal de testing en Estados Unidos, emergió una nueva visión: las pruebas abarcan actividades asociadas a obtener confianza de que un programa hace lo que se supone que tiene que hacer. El énfasis pasó de corregir a confiar — un cambio conceptual pequeño pero significativo.
"El testing es el proceso de ejecutar un programa o sistema con la intención de encontrar errores." — Myers, 1979, p.5
Myers invirtió la lógica predominante: hasta entonces, muchos testers elegían casos que tenían baja probabilidad de hacer fallar el sistema. Myers argumentó lo contrario: los datos de prueba deben seleccionarse con alta probabilidad de causar fallas, no de que el sistema las supere. Un cambio radical que redefinió la profesión.
Con los primeros estándares de la industria, el testing dejó de verse como algo al final del ciclo. Cualquier actividad orientada a evaluar un atributo del software — revisiones de requerimientos, inspecciones de código, controles de escritorio — es una forma de testing. Nace el concepto de pruebas tempranas.
La visión contemporánea distingue dos actividades clave. Verificar responde a ¿estamos construyendo el sistema correctamente? Validar responde a ¿estamos construyendo el sistema correcto? Esta distinción, formalizada por la norma ISO 9000 y sintetizada por Boehm (1981), es uno de los pilares de la ingeniería de software moderna.
Uno de los problemas históricos del testing fue la ambigüedad terminológica. El International Software Testing Qualifications Board (ISTQB) estableció definiciones precisas que hoy son el estándar internacional en todo el mundo.
La cadena causal es: un error del desarrollador introduce un defecto en el código, que bajo ciertas condiciones de ejecución produce una falla observable. Un defecto no siempre produce una falla — solo cuando la ejecución pasa por esa parte del código defectuosa. Por eso el tester busca deliberadamente provocar fallas para detectar defectos antes que el usuario final.
Desarrollado originalmente para la Fuerza Aérea de Estados Unidos, el modelo de McCall define 11 factores de calidad organizados en tres perspectivas: Operación del producto (corrección, confiabilidad, usabilidad, integridad, eficiencia), Transición del producto (portabilidad, reutilización, interoperabilidad) y Revisión del producto (mantenibilidad, flexibilidad, facilidad de prueba).
Cada factor se desglosa en criterios medibles mediante listas de comprobación. El factor Corrección, por ejemplo, depende de la Completitud, la Trazabilidad y la Consistencia — cada una normalizada en el intervalo [0, 1]. Por primera vez, la calidad del software podía expresarse como un número, no como una impresión subjetiva.
Adoptada en 2001 y reemplazada por ISO 25000 en 2005, la ISO 9126 consolida décadas de investigación en seis características de calidad: Funcionalidad, Fiabilidad, Usabilidad, Eficiencia, Mantenibilidad y Portabilidad. Cada una se divide en subcaracterísticas y se mide con métricas internas (estáticas), externas (dinámicas) o de uso (en operación real).
Mensaje central de la ISO 9126: la calidad no es binaria. No existe software "de calidad" o "sin calidad" — existe software con distintos niveles en distintas dimensiones. Cada organización debe definir qué características importan más en su contexto.
Por más pequeño que sea un programa, probar todos los casos posibles es computacionalmente imposible. No es una limitación práctica superable: es una imposibilidad teórica. La respuesta correcta es gestionar el riesgo, priorizar los casos con mayor probabilidad de revelar defectos críticos y distribuir el esfuerzo según el impacto potencial de cada falla.
Existe la falsa creencia de que cualquiera puede hacer pruebas sin experiencia. Hetzel (1988) identifica cuatro ingredientes esenciales: creatividad e intuición, conocimiento del negocio, experiencia en pruebas, y metodología. Los primeros tres no se enseñan en un curso — se desarrollan con la práctica y el estudio profundo del sistema.
Diseñar casos de prueba desde la etapa de requerimientos — antes de escribir una sola línea de código — obliga a pensar con precisión en el comportamiento esperado del sistema y detecta ambigüedades donde corregirlas es mucho menos costoso. El mejor proceso de pruebas es el que da feedback rápido.
La cantidad de pruebas es directamente proporcional al riesgo de falla y al impacto que esa falla tendría. Un sistema de control de vuelos requiere cobertura radicalmente distinta a la de una app de notas. El riesgo es la brújula que guía qué probar, cuándo y con qué intensidad.
Improvisar pruebas es casi tan ineficaz como no hacerlas. Un plan de pruebas define qué se va a probar, en qué orden, con qué criterios de éxito y con qué recursos. Es corolario del principio 1: si no se puede probar todo, se necesita una selección cuidadosa y una planificación rigurosa.
"Si no está ahí antes de que empiece la prueba, no estará cuando termine." — Roger Pressman, 2006
La historia del testing es la historia de una maduración colectiva. La industria aprendió — a veces con costos altísimos — que la calidad no se agrega al final del proceso. Se construye desde el principio, con intención, con metodología y con rigor. Los estándares ISTQB, ISO 9126 y el modelo de McCall no son burocracia académica: son el destilado de décadas de fracasos y aprendizajes. Conocerlos es la diferencia entre hacer pruebas y hacer pruebas bien.