¿Qué Es el Testing Dinámico?

El testing dinámico es el proceso de evaluar software ejecutándolo. Proporcionas entradas al sistema en ejecución, este las procesa, y observas si las salidas y comportamientos reales coinciden con lo esperado.

Cada vez que haces clic en un botón de una aplicación y verificas si hizo lo correcto, estás realizando testing dinámico. Cada vez que un framework de pruebas automatizadas lanza un navegador, llena un formulario y verifica el resultado, eso es testing dinámico.

La palabra clave es ejecución. Si el código se ejecuta, es dinámico. Si solo lees o analizas el código sin ejecutarlo, es estático.

Cómo el Testing Dinámico Complementa al Estático

Testing estático y dinámico no son competidores — son socios. Cada uno detecta defectos que el otro no puede.

El testing estático encuentra: Violaciones de estándares, código inalcanzable, potenciales problemas de null, patrones de seguridad, ambigüedades en requisitos.

El testing dinámico encuentra: Fallas reales en runtime, cuellos de botella de rendimiento, fugas de memoria bajo carga, fallas de integración entre componentes, problemas de UX, race conditions.

La Relación Complementaria

graph TB subgraph Testing Estático S1[Revisión de Requisitos] S2[Revisión de Código] S3[Herramientas de Análisis Estático] end subgraph Testing Dinámico D1[Pruebas Unitarias] D2[Pruebas de Integración] D3[Pruebas de Sistema] D4[Pruebas de Rendimiento] end S1 -->|Valida requisitos antes de| D3 S2 -->|Detecta issues de código antes de| D1 S3 -->|Identifica patrones antes de| D2 style S1 fill:#60a5fa,color:#000 style S2 fill:#60a5fa,color:#000 style S3 fill:#60a5fa,color:#000 style D1 fill:#34d399,color:#000 style D2 fill:#34d399,color:#000 style D3 fill:#34d399,color:#000 style D4 fill:#34d399,color:#000

Estático vs. Dinámico: Comparación

DimensiónTesting EstáticoTesting Dinámico
Ejecución de códigoNoSí
Cuándo es posibleDesde la fase de requisitosDesde la fase de implementación
Actividades típicasRevisiones, walkthroughs, análisis estáticoUnit tests, integration tests, system tests
Ambiente necesarioNinguno (solo el artefacto)Ambiente de ejecución requerido
Tipos de defectosViolaciones de estándares, bugs potencialesFallas reales, issues de rendimiento
Costo de encontrar defectosMenor (más temprano en SDLC)Mayor (requiere ambiente, ejecución)
Velocidad de feedbackRápida (minutos para herramientas)Varía (segundos para unit, horas para E2E)
Puede encontrar issues de runtimeNo (solo predichos)Sí (observados directamente)
Verifica requisitos no funcionalesLimitadoSí (rendimiento, usabilidad, confiabilidad)

Técnicas de Testing Dinámico

El testing dinámico abarca muchas técnicas que ya has encontrado o encontrarás:

Por conocimiento del código:

  • Black-box (Lección 2.27) — Tests basados en requisitos
  • White-box (Lección 2.26) — Tests basados en estructura del código
  • Grey-box (Lección 2.28) — Tests con conocimiento parcial

Por nivel de testing:

  • Unitario, integración, sistema, E2E, aceptación

Por propósito:

  • Funcional, rendimiento, seguridad, usabilidad, confiabilidad (Lección 2.25)

Por enfoque:

  • Testing con scripts — Casos de prueba prediseñados
  • Testing exploratorio (Lección 2.32) — Aprendizaje, diseño y ejecución simultáneos
  • Testing ad hoc (Lección 2.33) — No planificado, basado en intuición

Cuándo Iniciar el Testing Dinámico

Un error común es creer que el testing dinámico inicia solo después de construir toda la aplicación. En realidad, debe comenzar tan pronto como exista código ejecutable:

Fase SDLCActividad Dinámica
ImplementaciónDesarrolladores escriben y ejecutan unit tests
IntegraciónTests de integración verifican interacciones
Testing de sistemaQA ejecuta pruebas funcionales y no funcionales
UATUsuarios de negocio validan en ambiente similar a producción
ProducciónSmoke tests, monitoreo sintético, chaos engineering

El Proceso de Testing Dinámico

  1. Planificar — Identificar qué probar, seleccionar técnicas, preparar datos
  2. Diseñar — Crear casos de prueba con entradas, pasos y resultados esperados
  3. Preparar — Configurar ambiente, desplegar build, configurar datos
  4. Ejecutar — Correr las pruebas, observar resultados reales
  5. Comparar — Comparar resultados reales con esperados
  6. Reportar — Documentar: pass, fail o bloqueado
  7. Re-probar — Después de correcciones, verificar resolución

Ejercicio: Clasifica Actividades de Testing

Para cada actividad, clasifícala como testing estático o dinámico y explica tu razonamiento.

  1. Un desarrollador ejecuta pytest para correr unit tests
  2. Un QA lee una user story para verificar si los criterios de aceptación son claros
  3. SonarQube escanea un proyecto Java y reporta 15 code smells
  4. Un tester abre la app web, ingresa credenciales y verifica el login exitoso
  5. Un equipo realiza un walkthrough de código de un módulo de pagos
  6. Un test de Playwright navega al checkout y verifica el precio total
  7. Una herramienta SAST busca API keys hardcodeadas
  8. Una herramienta de rendimiento envía 1,000 requests concurrentes y mide tiempos
  9. Un desarrollador lee un diff de PR y comenta sobre el manejo de errores
  10. Un QA usa Postman para enviar un POST a /users y verifica el status code
  11. ESLint busca variables no utilizadas en el proyecto
  12. Un tester instala la app en un dispositivo y prueba el onboarding
PistaLa pregunta clave: "¿Necesita el software estar ejecutándose para esta actividad?" Si sí → dinámico. Si solo se examina un artefacto sin ejecutarlo → estático.
Solución
  1. Dinámico — pytest ejecuta el código y verifica salidas reales.
  2. Estático — El QA lee un documento sin ejecutar software. Es una revisión de requisitos.
  3. Estático — SonarQube analiza código fuente sin ejecutarlo.
  4. Dinámico — El tester interactúa con la aplicación en ejecución.
  5. Estático — Un walkthrough es una actividad de revisión sin ejecución.
  6. Dinámico — Playwright lanza un navegador, la aplicación se ejecuta.
  7. Estático — SAST escanea código fuente sin ejecutarlo.
  8. Dinámico — La herramienta envía requests reales a una aplicación en ejecución.
  9. Estático — El desarrollador lee código y da feedback sin ejecutar nada.
  10. Dinámico — Postman envía un request HTTP real a un servidor en ejecución.
  11. Estático — ESLint lee archivos fuente y aplica reglas sin ejecutar.
  12. Dinámico — El tester ejecuta la app real en un dispositivo.

Resumen: 1, 4, 6, 8, 10, 12 son dinámicas. 2, 3, 5, 7, 9, 11 son estáticas.

Por Qué Ambos Importan: Ejemplo Real

Considera una función que calcula costos de envío:

Análisis estático podría encontrar: complejidad ciclomática alta, variable no usada, rama siempre verdadera.

Revisión de código podría encontrar: no maneja envío internacional, lógica de descuento contradice los requisitos.

Test unitario dinámico podría encontrar: para un pedido de $49.99, envío gratis aplicado incorrectamente (bug de valor límite).

Test de integración dinámico podría encontrar: el servicio de envío retorna pesos en kilogramos pero la calculadora espera libras.

Cada técnica revela problemas diferentes. Depender de solo una deja vacíos significativos.

Puntos Clave

  • El testing dinámico requiere ejecutar el software; el estático no
  • Ambos enfoques son esenciales — detectan diferentes tipos de defectos a diferentes costos
  • El testing dinámico comienza cuando hay código ejecutable, no solo después de completar la aplicación
  • El testing estático detecta issues potenciales más temprano; el dinámico confirma comportamiento real
  • Los requisitos no funcionales solo se validan completamente mediante testing dinámico
  • Los equipos modernos combinan análisis estático en CI con tests dinámicos en múltiples niveles