Iniciar sesión Suscribirse
Pruebas estáticas

Pruebas estáticas: los defectos que se encuentran leyendo, antes de ejecutar nada

No hace falta esperar a que el software se ejecute para empezar a probar. Revisar requisitos, diseños y código permite encontrar el defecto directamente en el documento original, antes de que se convierta en un fallo costoso de rastrear.

Diario Bug Bot, Alvaro Sánchez

• 6 min de lectura
Compartir
Pruebas estáticas: los defectos que se encuentran leyendo, antes de ejecutar nada

En la práctica es común que los equipos pospongan las pruebas hasta que exista una versión ejecutable del sistema. Cuando esto ocurre, los defectos introducidos semanas atrás en documentos de requisitos o bocetos de diseño viajan en silencio hasta el código. Al llegar a la aplicación se manifiestan como comportamientos incorrectos, y encontrarlos ahí cuesta más que haberlos encontrado en el documento.

En este artículo explicamos qué son las pruebas estáticas, por qué encuentran el defecto en su origen, antes de que se convierta en un fallo, y cómo se complementan con las pruebas basadas en ejecución.

Qué es una prueba estática

A diferencia de la prueba dinámica, que requiere la compilación del sistema y el procesamiento de datos para examinar su comportamiento en ejecución, las pruebas estáticas analizan los productos de trabajo sin necesidad de ejecutarlos.

Casi cualquier documento o archivo generado durante el desarrollo puede someterse a una prueba estática. Entre los productos de trabajo se encuentran:

  • Especificaciones de requisitos e historias de usuario.
  • Documentos de arquitectura y modelos de datos.
  • Contratos técnicos y especificaciones de interfaces entre sistemas.
  • Código fuente y archivos de configuración.
  • Planes de prueba y casos de prueba documentados.

Para entender el valor de este enfoque, consideremos una historia de usuario común en un sistema de comercio electrónico:

Historia de usuario: Regla de promociones
"Como cliente frecuente, quiero recibir un 10% de descuento en mi carrito de compra si llevo más de cinco artículos o si el total supera los mil pesos, para ahorrar en compras grandes."

A simple vista, la redacción parece clara. Sin embargo, contiene ambigüedades. ¿Qué sucede si el carrito contiene exactamente cinco artículos? La frase dice "más de cinco", lo que excluye al número cinco, pero quien diseñó la aplicación podría interpretar que la promoción aplica a partir de cinco piezas. Asimismo, la conjunción "o" no aclara si ambos beneficios son acumulables o si se aplica un tope. Una lectura cuidadosa permite identificar estas inconsistencias antes de escribir una sola línea de código.

Encontrar el defecto frente a provocar un fallo

La diferencia más importante entre ambos enfoques radica en qué parte del problema revelan. Una prueba estática encuentra un defecto de forma directa en el documento o en el código. En cambio, una prueba dinámica provoca un fallo, que es la manifestación visible del problema durante la ejecución.

Cuando el equipo confía únicamente en las pruebas dinámicas, debe invertir tiempo en depuración para diagnosticar la causa de cada fallo. Por ejemplo, si quien programó la aplicación entendió que el descuento aplica a partir de cinco artículos, un carrito de cinco artículos por novecientos pesos cobra ochocientos diez en lugar de novecientos, y el equipo debe reproducir el escenario, revisar registros del servidor, inspeccionar las variables del código y rastrear el origen hasta aquella historia de usuario ambigua. La prueba dinámica sí llevó al defecto, pero después de programar y depurar; la prueba estática lo localiza antes, directamente en la frase de la historia del usuario.

Diagrama con dos rutas hacia un mismo defecto; la ruta superior muestra la prueba estática localizando la frase ambigua en una historia de usuario; la ruta inferior muestra la prueba dinámica requiriendo compilación de código, un fallo en el cobro y una sesión de depuración para llegar al mismo texto

Qué detecta cada enfoque que el otro no puede

Las pruebas estáticas y dinámicas no compiten entre sí; son técnicas complementarias con capacidades distintas. Existen tipos de anomalías que solo un enfoque puede resolver con efectividad.

Las pruebas estáticas detectan con facilidad:

  • Defectos en requisitos: contradicciones lógicas, omisiones en las reglas de negocio y criterios de aceptación incompletos.
  • Problemas de diseño: estructuras de bases de datos ineficientes o acoplamiento excesivo entre módulos.
  • Desviaciones de estándares: violaciones a convenciones de nombres y reglas internas de arquitectura.
  • Código inalcanzable: instrucciones que nunca se van a ejecutar bajo ninguna condición real.
  • Mantenibilidad: código demasiado enredado o complejo que dificultará cambios futuros.

Por su parte, las pruebas dinámicas encuentran los fallos que aparecen al ejecutar el sistema, como el cobro equivocado del ejemplo, y evalúan lo que solo se puede medir en ejecución, como el desempeño: los tiempos de respuesta lentos ante alta demanda de usuarios.

Aspecto de comparación Pruebas estáticas Pruebas dinámicas
Ejecución del software No requiere ejecutar código Requiere compilar y ejecutar el sistema
Punto de detección Encuentra el defecto directamente en el texto o código Provoca un fallo visible y requiere depurar para hallar el defecto
Artefactos evaluables Requisitos, diseño, código fuente, contratos, pruebas Únicamente código compilable o componentes desplegables
Defectos típicos Ambigüedades, omisiones, código inalcanzable, mala modularidad Resultados incorrectos al ejecutar, tiempos de respuesta lentos y otros problemas de desempeño

Las dos formas de probar sin ejecutar

La prueba estática se divide en dos grandes modalidades de trabajo: la revisión realizada por personas y el análisis automatizado mediante herramientas.

La revisión humana

Una revisión es la evaluación manual de un producto de trabajo llevada a cabo por una o más personas. Su valor va más allá de identificar erratas o descuidos lógicos.

En un estudio sobre revisión moderna de código en la industria, Alberto Bacchelli y Christian Bird (2013) observaron que, aunque la motivación principal declarada sigue siendo la búsqueda de defectos, las revisiones aportan beneficios organizacionales indispensables: facilitan la comprensión del cambio, promueven la transferencia de conocimiento técnico entre integrantes y refuerzan la conciencia colectiva sobre las modificaciones que sufre el sistema. Los autores también encontraron que las herramientas actuales no cubren la mayoría de las necesidades de comprensión de quien revisa.

El análisis estático con herramientas

El análisis estático consiste en examinar código fuente, modelos o sintaxis formal mediante herramientas de software especializadas, sin ejecutar el programa. Estas herramientas buscan variables no inicializadas, código muerto o violaciones a reglas de codificación.

A pesar de su velocidad, las herramientas pueden presentar un desafío operativo: la generación de falsos positivos, es decir, alertas sobre problemas que en la práctica no representan un defecto real. Suphi Cankurt (2026), en un artículo técnico que recopila prácticas del sector pero no cita el estudio de origen, reportó que las herramientas automatizadas de escaneo de código pueden generar entre un 30% y un 60% de alertas que resultan ser falsos positivos inofensivos si no se calibran de forma rigurosa.

Este volumen de alertas genera fatiga. De acuerdo con información publicada por Praetorian (2026), ante el bombardeo continuo de notificaciones de baja precisión, los analistas técnicos pueden verse forzados a dedicar apenas unos 90 segundos a cada alerta. La sobrecarga cognitiva provoca que los equipos comiencen a ignorar las advertencias, aumentando el riesgo de pasar por alto defectos críticos que quedan ocultos en el ruido. Por esta razón, el análisis estático automatizado debe acompañarse siempre del criterio de revisores humanos.

Qué documento revisar mañana y qué buscar en él

No es necesario transformar todo el proceso de trabajo de un día para otro para aprovechar las pruebas estáticas. Cualquier persona analista o de producto puede seleccionar un artefacto breve, como una historia de usuario o una especificación funcional, y convocar a una lectura compartida antes de pasar el documento a desarrollo.

Al revisar ese artefacto, conviene concentrarse en cuatro aspectos fundamentales:

  1. Ambigüedades: palabras vagas como "rápido", "adecuado", "seguro" o "frecuente". Cada adjetivo debe reemplazarse por una condición medible.
  2. Definición de límites: aclaración de términos numéricos. Si un texto dice "más de cinco", debe definirse si el valor cinco queda incluido o excluido.
  3. Omisiones: caminos alternativos y escenarios de error ausentes. Por ejemplo, qué debe hacer el sistema si el servicio de promociones no responde o si el usuario ingresa cupones vencidos.
  4. Contradicciones: reglas que chocan entre sí o con políticas existentes del negocio.

La historia de usuario después de la revisión

Historia de usuario: Regla de promociones
"Como cliente frecuente, quiero recibir un 10% de descuento en mi carrito de compra si llevo seis artículos o más, o si el total, antes de impuestos, es mayor a 1,000 pesos, para ahorrar en compras grandes."
Con cinco artículos o menos y un total de 1,000 pesos o menos, no hay descuento. Si se cumplen las dos condiciones, el descuento sigue siendo de 10%: los beneficios no se acumulan y no hay tope. Es cliente frecuente quien hizo al menos tres compras en los últimos 90 días.

Cada pregunta de la revisión quedó contestada en el texto. «Seis artículos o más» ya no deja dudas sobre el cinco, y la segunda frase dice qué pasa justo en los límites. La tercera aclara que los beneficios no se suman ni tienen tope. Al reescribirla apareció una pregunta más, si los mil pesos incluyen impuestos, y la versión nueva también lo dice. Y «frecuente», una de las palabras vagas de la lista anterior, ahora es una condición medible. Además, ahora la historia se puede probar: cada frase se convierte en un caso con un resultado esperado. Para un cliente frecuente, un carrito de cinco artículos y 900 pesos no recibe descuento; uno de seis artículos y 600 pesos, sí.

Conclusión

Las pruebas estáticas demuestran que el aseguramiento de calidad comienza mucho antes de tener una aplicación interactiva. Examinar los requisitos, los diseños y el código fuente sin ejecutarlo permite resolver las deficiencias directamente en su redacción original, lo que evita sesiones prolongadas de depuración en fases avanzadas del proyecto.

Al combinar la perspectiva contextual de las revisiones humanas con la rapidez de las herramientas de análisis estático, los equipos construyen bases sólidas. Esta disciplina complementa a las pruebas dinámicas: cada una encuentra defectos que la otra no puede ver.

Fuentes