Detectar defectos antes de que el software se ejecute es una de las prácticas más rentables en aseguramiento de calidad. Las pruebas estáticas permiten examinar artefactos —requisitos, código fuente, diseño— sin correr una sola línea, atrapando errores que costarían días o semanas si llegaran a producción. Comprender cuándo y cómo aplicar cada técnica marca la diferencia entre un equipo reactivo y uno que previene problemas desde el origen.
¿Qué diferencia al testing estático del dinámico?
El testing dinámico requiere que el software corra: se le da una entrada, se observa una salida y se compara con lo esperado [0:25]. Las pruebas unitarias, de integración, de sistema y de aceptación entran en esta categoría. El testing estático, en cambio, examina artefactos sin ejecutarlos [0:42]. La analogía es clara: un médico que estudia una radiografía antes de operar detecta el problema sin tocar al paciente.
¿Qué artefactos se pueden revisar de esta forma?
- Requisitos y especificaciones de diseño.
- Código fuente.
- Planes de prueba.
- Documentación de usuario.
Cualquier documento que no necesite ejecutarse es candidato para una revisión estática.
¿Cómo interrumpen la cadena error-defecto-falla?
Recordando la cadena que conecta un error humano con un defecto en el artefacto y luego con una falla en ejecución [1:12], las pruebas estáticas actúan como una puerta que frena la propagación lo más temprano posible. Si un analista malinterpreta una regla de negocio y la plasma mal en un documento de requisitos, ese defecto ya existe. Sin revisión, viaja al diseño, luego al código y termina como falla en producción.
¿Qué defectos concretos atrapan?
- En requisitos: contradicciones entre secciones, frases ambiguas, información faltante [1:38].
- En código: variables declaradas pero nunca usadas, código muerto, variables usadas sin valor asignado, vulnerabilidades de seguridad [1:48].
- Bloques de manejo de errores que solo se disparan con combinaciones exóticas de datos y que ninguna prueba dinámica suele tocar.
Una revisión de código encuentra en minutos lo que podría esconderse durante años [2:05].
¿Cuáles son las tres técnicas principales de revisión estática?
Ordenadas de menor a mayor formalidad, cada una responde a un escenario distinto.
¿Cuándo basta con una revisión informal?
La revisión informal es la más ligera [2:18]. Un colega lee tu trabajo y da retroalimentación sin reunión programada, sin roles definidos, sin reporte formal. Funciona bien para borradores, artefactos de bajo riesgo o cuando se necesita feedback rápido sin coordinar agendas.
¿Qué aporta un walkthrough?
En el walkthrough, el protagonista es el autor [2:40]. La persona que creó el artefacto guía al grupo paso a paso por el contenido, como un maestro que recorre su plan de clase con otros colegas antes de impartirla. El objetivo es doble: construir entendimiento compartido y detectar problemas a través de las preguntas del grupo.
Dos señales de alerta valiosas:
- Si los revisores hacen preguntas que el documento debería responder solo, hay un hueco.
- Si dos personas interpretan la misma sección de formas distintas, hay ambigüedad.
¿Qué hace especial a la inspección?
La inspección es la técnica más formal [3:14]. Incluye roles definidos: moderador, relator, revisores y autor. Tiene agenda, registro de hallazgos y seguimiento de acciones correctivas. Una regla clave: el autor no puede ser moderador ni relator, para mantener la objetividad.
Las checklists juegan un papel central, pero deben estar escritas como preguntas, no como órdenes [3:30]. En vez de "verificar el botón de login", se escribe: "¿el botón responde correctamente bajo todas las condiciones?" Esto mantiene al revisor pensando, no solo marcando casillas.
¿Cómo elegir la técnica adecuada según el riesgo?
La regla es directa: a mayor riesgo, mayor formalidad [3:52].
- Un requisito ambiguo en un sistema de pagos merece inspección.
- Una historia de usuario incompleta se resuelve bien con un walkthrough.
- Un borrador temprano de bajo riesgo basta con revisión informal.
Una acción que se puede implementar hoy: agregar tres preguntas a los pull requests [4:10].
- ¿El código sigue los estándares del equipo?
- ¿Hay código muerto o variables sin usar?
- ¿El cambio corresponde con lo que dice la historia de usuario?
Cinco minutos extra por revisor convierten algo que ya ocurre en una revisión informal integrada al flujo de trabajo.
Si en tu equipo no se revisa ningún artefacto antes de que llegue a código, ya sabes por dónde empezar. ¿Qué técnica probarías primero en tu contexto actual?
