Testing Estático: Revisiones y Walkthroughs

¿Qué Es el Testing Estático? #

El testing estático examina productos de trabajo del software — requisitos, documentos de diseño, código, planes de prueba — sin ejecutar el software. Observas el artefacto en sí, buscando defectos, inconsistencias y mejoras.

El testing dinámico ejecuta el software y verifica su comportamiento. El testing estático lee el software (o su documentación) y verifica su corrección.

Piensa en ello como revisar una receta antes de cocinar versus probar el plato después de cocinarlo. Ambos enfoques encuentran problemas, pero la revisión previa es más barata — detectas “agregar 10 tazas de sal en vez de 1 cucharadita” antes de arruinar los ingredientes.

¿Por Qué Importa el Testing Estático? #

El costo de corregir un defecto aumenta dramáticamente cuanto más tarde se encuentra:

El testing estático detecta defectos en la etapa más temprana posible — antes de escribir código. La investigación de IBM encontró que las inspecciones pueden eliminar 60-90% de los defectos antes de que comience el testing.

¿Qué Se Puede Probar Estáticamente? #

• Especificaciones de requisitos
• User stories y criterios de aceptación
• Documentos de arquitectura y diseño
• Código fuente
• Planes de prueba y casos de prueba
• Esquemas de base de datos
• Archivos de configuración
• Definiciones de pipelines CI/CD

Tipos de Revisiones #

Las revisiones son una forma de testing estático impulsada por personas. Van desde casuales hasta altamente formales.

Revisión Informal #

La forma más simple. Una persona pide a un colega que mire su trabajo. Sin proceso documentado, sin output formal.

Características:

• Sin proceso o roles definidos
• Frecuentemente una revisión rápida en el escritorio
• Sin hallazgos documentados (o solo retroalimentación verbal)
• Bajo overhead, fácil de hacer frecuentemente

Cuándo usar: Cambios diarios de código, verificaciones rápidas, borradores tempranos.

Walkthrough #

El autor guía a los revisores a través del producto de trabajo, explicando el contenido y recopilando retroalimentación. El autor lidera la sesión.

Características:

• Presentación liderada por el autor
• Puede ser abierta o basada en escenarios
• Los hallazgos pueden o no documentarse
• Enfoque en aprendizaje y transferencia de conocimiento tanto como en encontrar defectos

Cuándo usar: Diseños complejos que necesitan explicación, onboarding de nuevos miembros, requisitos que necesitan contexto de negocio.

Revisión Técnica #

Una revisión de pares donde revisores técnicamente calificados examinan el producto independientemente antes de reunirse. Más estructurada que un walkthrough.

Características:

• Liderada por un moderador (no el autor)
• Los revisores se preparan individualmente antes de la reunión
• Hallazgos y decisiones documentados
• Enfocada en encontrar defectos técnicos y asegurar cumplimiento de estándares
• Puede usar checklists

Cuándo usar: Cambios críticos de código, decisiones arquitectónicas, componentes sensibles a seguridad.

Inspección (Inspección de Fagan) #

El tipo de revisión más formal, desarrollado por Michael Fagan en IBM en 1976. Sigue un proceso estricto con roles, criterios de entrada/salida y métricas.

Roles:

• Moderador — facilita el proceso, asegura que se sigan las reglas
• Autor — creó el producto, responde preguntas pero no defiende
• Revisores — examinan el artefacto e identifican defectos
• Escriba — registra todos los defectos y decisiones

Cuándo usar: Sistemas de seguridad crítica, requisitos regulatorios, componentes de alto riesgo.

El Proceso de Revisión #

Una revisión estructurada sigue estas fases:

1. Planificación. El moderador selecciona revisores, distribuye materiales, establece cronograma y verifica criterios de entrada.

2. Overview/Kickoff. El autor proporciona contexto. El moderador explica el proceso y los roles.

3. Preparación Individual. Cada revisor examina el producto independientemente, anotando defectos potenciales. Esta es la fase más crítica — los estudios muestran que la mayoría de defectos se encuentran durante la preparación individual.

4. Reunión de Revisión. Los revisores comparten hallazgos. El escriba registra defectos. El grupo decide sobre cada issue. La reunión no debe resolver problemas — solo identificarlos.

5. Corrección. El autor aborda todos los defectos identificados.

6. Seguimiento. El moderador verifica que todos los defectos fueron abordados.

Checklists de Revisión #

Checklist de Revisión de Requisitos #

• ¿Cada requisito tiene un identificador único (ID)?
• ¿Cada requisito es testeable?
• ¿Hay contradicciones entre requisitos?
• ¿Están todas las suposiciones explícitas?
• ¿Están definidas las condiciones límite (mín, máx, vacío, null)?
• ¿Se especifican condiciones de error y su manejo?
• ¿El requisito está libre de términos ambiguos (“rápido”, “fácil”)?
• ¿Están especificados todos los formatos de datos?

Checklist de Revisión de Código #

• ¿El código coincide con el diseño/requisitos?
• ¿Se manejan todas las condiciones de error?
• ¿Se liberan recursos correctamente (conexiones, archivos, memoria)?
• ¿Se validan los valores de entrada antes de usarlos?
• ¿Hay valores hardcodeados que deberían ser configurables?
• ¿El código está libre de vulnerabilidades de seguridad?
• ¿Hay pruebas unitarias para el código nuevo?
• ¿El código sigue la guía de estilo del equipo?

Beneficios de la Detección Temprana #

El testing estático proporciona beneficios más allá de encontrar bugs:

Transferencia de conocimiento. Las revisiones distribuyen el entendimiento del sistema en el equipo.

Cumplimiento de estándares. Las revisiones aseguran que estándares de codificación y patrones arquitectónicos se apliquen consistentemente.

Mentoría. Los desarrolladores junior aprenden al revisar código de seniors y al recibir retroalimentación sobre el propio.

Mejora de documentación. Revisar requisitos y diseños fuerza la claridad.

Ejercicio: Realiza una Revisión de Requisitos #

A continuación hay una especificación de requisitos para una funcionalidad de restablecimiento de contraseña. Usando el checklist proporcionado, identifica todos los defectos, ambigüedades e información faltante.

Especificación de Requisitos: Restablecimiento de Contraseña

REQ-1: Cuando un usuario haga clic en “Olvidé mi contraseña”, el sistema debe enviar rápidamente un email de restablecimiento.

REQ-2: El enlace de restablecimiento debe expirar después de cierto tiempo.

REQ-3: La nueva contraseña debe ser fuerte.

REQ-4: Después de restablecer la contraseña, el usuario debe poder iniciar sesión con la nueva contraseña.

REQ-5: El sistema debe manejar errores de manera elegante.

REQ-6: El email debe contener un enlace a la página de restablecimiento.

REQ-7: El usuario debe ingresar la nueva contraseña dos veces para confirmación.

REQ-8: Si el email no se encuentra en el sistema, no revelar esto al usuario (requisito de seguridad).

REQ-9: El token de restablecimiento debe ser criptográficamente seguro.

REQ-10: Rate limiting: el usuario no debe poder solicitar demasiados emails de restablecimiento.

Para cada defecto, especifica: ID del requisito, tipo de defecto y corrección recomendada.

Métricas de Revisión #

Puntos Clave #

• El testing estático examina productos de trabajo sin ejecutar código, detectando defectos en la etapa más temprana y barata
• Las revisiones van desde informales hasta formales (inspección con roles y métricas definidos)
• La preparación individual es la fase más efectiva — la mayoría de defectos se encuentran antes de la reunión
• Los checklists hacen las revisiones sistemáticas y previenen omisiones comunes
• El proceso sigue: planificación, kickoff, preparación, reunión, corrección, seguimiento
• Los beneficios van más allá de encontrar defectos: transferencia de conocimiento, cumplimiento de estándares y mentoría