Blog

¿Cómo es eso de que las Pruebas Estáticas y las Pruebas Dinámicas se complementan? ¿Tienen objetivos similares? ¿Cuáles son las diferencias? ¿Que defectos podemos encontrar mediante pruebas estáticas? ¿Cómo “aterrizar” estos conceptos al terreno de la práctica para entender su alcance?

Estas fueron algunas de las preguntas que me hice en su momento para poder comprender y obtener las respuestas que estaba buscando ya que estos temas como tantos otros, son aplicables en nuestro día a día. 

Este tema refiere a la sección 3.1.3. Diferencias entre Pruebas Estáticas y Pruebas Dinámicas del programa de estudios del ISTQB CTFL v4.0

¿Cómo es eso de que las Pruebas Estáticas y las Pruebas Dinámicas se complementan?

Las pruebas estáticas y dinámicas se complementan porque tienen objetivos comunes como así también algunas diferencias que te las explicaré aquí. 

Las pruebas estáticas, que no requieren la ejecución del software, son útiles para identificar defectos en fases tempranas del desarrollo, como errores en los requisitos, diseños, y código, y pueden encontrar defectos que no se detectan mediante pruebas dinámicas, como código inalcanzable o violaciones de estándares. 

Recordemos:

• las pruebas estáticas

Las pruebas dinámicas, por otro lado, implican la ejecución del software para detectar fallas que se manifiestan durante la ejecución, lo que permite descubrir defectos en la funcionalidad, el rendimiento y otros comportamientos del software. 

Por lo tanto, si aplicamos ambas pruebas en conjunto, podremos lograr mayor cobertura de testing y mejorar la calidad del producto que estamos desarrollando.

¿Tienen objetivos similares?

Comparten los siguientes objetivos:

• Detectar defectos en los productos de trabajo. 
• Asegurar la calidad del software (Nota: lo hacen de diferente manera).
• Las pruebas estáticas se enfocan en identificar defectos directamente en productos de trabajo no ejecutables, como la documentación y el código.
• Las pruebas dinámicas se enfocan en desencadenar fallas en el software ejecutable para identificar defectos​.

¿Cuáles son las diferencias?

• Ejecución del software: 
  • Las pruebas estáticas no requieren la ejecución del software.
  • Las pruebas dinámicas sí lo hacen.
• Detección de defectos: 
  • Las pruebas estáticas encuentran defectos directamente en los productos de trabajo.
  • Las pruebas dinámicas desencadenan fallas que luego se analizan para identificar defectos.
• Aplicabilidad: 
  • Las pruebas estáticas se pueden aplicar a productos de trabajo no ejecutables, como requisitos, historias de usuario y código.
  • Las pruebas dinámicas sólo se aplican a productos de trabajo ejecutables.
• Tipos de defectos: 
  • Las pruebas estáticas pueden detectar defectos en rutas de código raramente ejecutadas o difíciles de alcanzar mediante pruebas dinámicas.
  • Las pruebas dinámicas son más efectivas para detectar defectos que solo se manifiestan durante la ejecución del software.
• Medición de características de calidad: 
  • Las pruebas estáticas pueden medir características de calidad que no dependen de la ejecución del código (ej. mantenibilidad).
  • Las pruebas dinámicas miden características que dependen de la ejecución (ej. eficiencia del rendimiento​).

¿Qué defectos podemos encontrar por medio de pruebas estáticas?

• Pruebas estáticas:
  • Defectos en los requisitos, como inconsistencias, ambigüedades, contradicciones, omisiones, inexactitudes, y duplicaciones.
  • Defectos de diseño, como estructuras de base de datos ineficientes y mala modularización.
  • Defectos de codificación, como variables con valores indefinidos, variables no declaradas, código inalcanzable o duplicado, y complejidad excesiva del código.
  • Desviaciones de los estándares, como la falta de adherencia a las convenciones de nomenclatura.
  • Especificaciones de interfaz incorrectas, como número, tipo u orden de parámetros no coincidentes.
  • Tipos específicos de vulnerabilidades de seguridad, como desbordamientos del búfer​.

¿Qué defectos podemos encontrar por medio de pruebas dinámicas?

• Errores de lógica y cálculo: 
  • Cálculos incorrectos
  • Errores aritméticos
  • Fallos en la lógica de la aplicación.
• Problemas de flujo de control: 
  • Bucles infinitos o condiciones de flujo de control mal implementadas.
• Errores de interacción y comunicación: 
  • Problemas en la interacción entre diferentes componentes del sistema o en la comunicación con otros sistemas.
• Defectos de rendimiento: 
  • Cuellos de botella
  • Uso ineficiente de recursos
  • Problemas de respuesta bajo carga.
• Problemas de seguridad: 
  • Vulnerabilidades que pueden ser explotadas durante la ejecución.
• Errores de manejo de datos: 
  • Gestión incorrecta de la entrada y salida de datos, como validación insuficiente o falta de manejo de excepciones.
• Defectos de interfaz de usuario: 
  • Problemas en la interacción con el usuario, como elementos no funcionales, mensajes de error poco claros o incoherencias en la interfaz gráfica.

¿Cómo “aterrizar” estos conceptos al terreno de la práctica para entender su alcance?

Supongamos que formamos parte de un equipo de desarrollo para un proyecto en el que se está aplicando metodología ágil.

Situación 1

Durante una revisión de código (Code Review), se detecta que un desarrollador ha incluido varias líneas de código comentadas y algunas variables que no se utilizan en ningún lugar del programa. El equipo decide discutir estos puntos en la retrospectiva para evaluar que mejoras aplicar en las pruebas estáticas que se han aplicado e implementarlas en el próximo sprint siempre y cuando se acuerde la prioridad.

Situación 2

Durante un Sprint, el equipo de desarrolladores ha completado una nueva funcionalidad que fue revisada a través de una reunión de revisión de requisitos (Requirement Review) para garantizar que cumple con las necesidades solicitadas por el cliente. Posteriormente, se planifican pruebas para validar el correcto funcionamiento de esta funcionalidad. Durante la sesión de planificación se discuten las diferencias clave que hay entre la revisión realizada y las pruebas que se deben planificar.

Concluimos con los desarrolladores en que la revisión es una prueba estática enfocada en la validación de los requisitos sin ejecutarlos, mientras que las pruebas a planificar son pruebas dinámicas que verificarán el comportamiento del software al ser ejecutado.

Situación 3

El equipo de desarrolladores ha implementado una herramienta de análisis estático de código (p.e. SonarQube) que se ejecuta automáticamente cada vez que se sube una nueva versión del código al repositorio. Esta herramienta ayuda a detectar problemas como violaciones de convenciones de codificación y posibles vulnerabilidades de seguridad. Más adelante, el equipo planea realizar pruebas exploratorias sobre la nueva funcionalidad del software. 

Durante una reunión algunos desarrolladores preguntaron cuál es la diferencia principal entre el uso de la herramienta de análisis estático y las pruebas exploratorias.

En esa reunión se explicó que la herramienta de análisis estático realiza pruebas sin ejecutar el código para encontrar defectos en la estructura y calidad del código, mientras que las pruebas exploratorias implican la ejecución del software para descubrir defectos en su comportamiento.

Momento para reflexionar:

• ¿Cuántas mejoras podríamos estar obteniendo si de alguna forma chequeamos que el código desarrollado no presenta alguno de los defectos arriba mencionados?
• Lo mismo para el caso de las pruebas dinámicas.
• ¿Cuánto nos puede ayudar en este sentido una IAGen?