Al finalizar esta unidad podrás

Antes de empezar

¿Alguna vez usaste una aplicación que falló justo después de que el equipo que la desarrolla aseguró que "ya estaba probada"?

¿Cómo sabes, en realidad, si algo "ya se probó lo suficiente"?

Esta unidad te da el vocabulario y los principios para responder esa pregunta con precisión.

Una situación

Pregunta orientadora

Mapa de la unidad

Actividad — Diagnóstico inicial

¿Qué es la calidad de software?

La calidad de software es el grado en el que un producto cumple con los requisitos establecidos y con las expectativas razonables de quienes lo utilizan, de forma consistente y sostenida en el tiempo.

Características observables de calidad

La calidad se construye durante todo el ciclo de vida

Actividad — Caracterización de la calidad de software

Garantía de calidad (Quality Assurance)

Conjunto de actividades preventivas integradas en el proceso de desarrollo. Ejemplo: definir un estándar de codificación antes de escribir código, o exigir revisión de pares antes de integrar un cambio.

Aseguramiento de calidad

Actividades de revisión, evaluación y mejora continua sobre si las actividades preventivas realmente se están cumpliendo.

Verificación y validación

Ejemplo: un sistema que rechaza contraseñas de menos de 4 caracteres pasa la verificación si cumple esa regla pero puede fallar la validación si 4 caracteres son insuficientes para proteger las cuentas en la práctica.

Los cuatro términos, en un solo lugar

Actividad — Análisis de caso

¿Para qué probamos?

Una prueba evalúa un producto de software para identificar diferencias entre su comportamiento real y el esperado.

Las pruebas como reducción de riesgo

No todas las partes de un sistema requieren el mismo esfuerzo de prueba: conviene priorizar aquellas con mayor impacto y mayor probabilidad de fallo.

En la situación inicial: la funcionalidad que falló merecía un nivel de prueba proporcional a su impacto, sin importar si era la más compleja del sistema.

Las pruebas dentro del ciclo de vida

Actividad — Identificación de riesgos

Cuatro principios que orientan cuándo y cómo probar

Presencia de defectos, no ausencia

Que una funcionalidad haya pasado todas las pruebas diseñadas no
significa que no tenga defectos: significa que no se encontraron
defectos con las pruebas que se ejecutaron.

Criterios de salida

Un proceso de pruebas necesita condiciones explícitas para decidir
cuándo una etapa puede considerarse terminada.

Ejemplo verificable: "no quedan defectos abiertos de severidad alta".

Ejemplo no verificable: "el sistema funciona bien".

Ampliación — Los 7 principios ISTQB

Principio 2 — Las pruebas exhaustivas no existen

Exhaustive testing is impossible. Probar todas las combinaciones
posibles de entradas y precondiciones no es viable, salvo en casos
triviales.

Para qué sirve: en vez de intentarlo, se usa análisis de riesgo,
técnicas de diseño de pruebas y priorización — el "cómo elegir qué
probar" que se formaliza en la Unidad III.

Principio 5 — La paradoja del pesticida

Pesticide paradox. Si se repite el mismo conjunto de pruebas una y
otra vez, eventualmente deja de encontrar defectos nuevos — igual que
un pesticida pierde eficacia contra una plaga con el tiempo.

Principio 6 — Las pruebas dependen del contexto

Testing is context dependent. No se prueba igual un sitio web
informativo que el software de control de un avión de pasajeros. A
mayor riesgo de pérdida humana o económica, mayor debe ser la
inversión en pruebas.

Principio 7 — Falacia de ausencia de errores

Absence-of-errors fallacy. Encontrar y corregir muchos defectos no
garantiza el éxito de un sistema: puede seguir siendo difícil de usar,
no cumplir las necesidades reales del usuario, o ser inferior frente a
la competencia.

Caso — CrowdStrike (19 de julio de 2024)

CrowdStrike — qué falló en el proceso de prueba

Principio ilustrado: Principio 1 (las pruebas muestran presencia
de defectos, no su ausencia) — confiar en que una herramienta de
prueba "siempre ha funcionado" no prueba que esté libre de defectos.

Lección: si automatizas validaciones, la herramienta de validación
también necesita sus propias pruebas.

Caso — Boeing 737 MAX (2018–2019)

Boeing 737 MAX — qué falló en el proceso de prueba

Principio ilustrado: Principio 6 (las pruebas dependen del
contexto) — un sistema donde una falla puede costar vidas exige un
nivel de prueba de redundancia muy superior al de software no crítico.

Lección: nunca confiar en una sola fuente de datos; un único punto
de falla en un sistema crítico es un defecto de diseño, no solo de
implementación.

Cobertura de requisitos

La cobertura de requisitos mide qué proporción de los requisitos
definidos tiene al menos un caso de prueba asociado.

Un requisito sin ningún caso de prueba es un requisito sin evidencia de
que se haya verificado.

Cobertura de código (introductoria)

Métricas básicas de defectos

Actividad — Evidencia conceptual de cierre

Instrucciones completas: Actividades de la Unidad 01, Actividad A5.
Criterios de desempeño: Rúbrica de la Unidad 01.

El ecosistema de estándares de pruebas de software

El ecosistema de estándares (continuación)

Ficha completa de cada norma, con su relevancia real para esta unidad: unidad01_materiales_referencias.md §4 (REF-U1-08 a REF-U1-19).

Cierre — volviendo a la situación inicial

Con lo aprendido en esta unidad, ahora puedes explicar con precisión:

• el equipo pudo confundir verificación con validación;
• "ya se probó" no es verificable sin criterios de salida ni
  cobertura conocida;
• sin priorizar por impacto y probabilidad, el esfuerzo de prueba no
  fue proporcional al riesgo;
• que la prueba manual "no encontrara nada" no demostraba ausencia de
  defectos.

En síntesis

• La calidad es un conjunto de características, no una propiedad
  binaria, y se juega en todo el ciclo de vida.
• Garantía, aseguramiento, verificación y validación son
  cuatro comprobaciones distintas.
• Las pruebas identifican defectos, mejoran la confiabilidad y
  reducen riesgo.
• Cuatro principios generales orientan cuándo y cómo probar (y el
  ISTQB reconoce tres más, con las mismas ideas de fondo).
• Cobertura y métricas básicas permiten valorar si un proceso de
  pruebas fue suficiente.
• Casos reales como CrowdStrike y Boeing 737 MAX muestran el
  costo de saltarse estos principios en la práctica.

Lo que sigue

En la Unidad II vas a trabajar con requisitos, criterios de
aceptación y trazabilidad: el puente entre "por qué probar" y "qué
probar".

Referencias

• Myers, Sandler y Badgett — The Art of Software Testing (3.ª ed., 2011).
• Jorgensen — Software Testing: A Craftsman's Approach (4.ª ed., 2013).
• Patton — Software Testing (2.ª ed., 2005).
• Black, van Veenendaal y Graham — Foundations of Software Testing ISTQB Certification (2012).
• Toledo — Introducción a las pruebas de sistemas de información (2024).
• ISO/IEC/IEEE 29119 (Partes 1, 2, 3, 4, 5, 6, 11).
• ISO/IEC 25010:2011, ISO/IEC/IEEE 12207, ISO/IEC 20246, ISO/IEC 33000.
• CrowdStrike, Channel File 291 Incident: Root Cause Analysis (2024).
• Wikipedia, Boeing 737 MAX groundings (resumen con fuentes primarias).

Ficha completa de cada fuente: unidad01/referencias/unidad01_materiales_referencias.md (REF-U1-01 a REF-U1-21).