Revisiones que sí encuentran defectos: todo se decide antes de la reunión

La escena se repite en muchas oficinas: un equipo recibe la convocatoria para revisar una especificación técnica o una historia de usuario. El archivo llega apenas unas horas antes del encuentro y tiene decenas de páginas. Durante la sesión, nadie ha leído con detenimiento. La reunión se alarga entre desacuerdos de redacción, opiniones sobre el estilo de quien escribió y silencios incómodos. Al final, el grupo aprueba el texto por puro cansancio. Los problemas siguen ahí, pasan intactos a la etapa de desarrollo y el equipo concluye que revisar documentos no sirve para nada.

Ese fracaso no ocurre por falta de capacidad técnica de los asistentes, sino por una preparación deficiente. Una revisión es una evaluación que realizan una o más personas sobre un producto de trabajo —como un requisito, un diseño o código fuente— sin ejecutar el sistema. Su meta fundamental es encontrar problemas antes de que se construya el software. Cuando una revisión se convoca sin rumbo, se degrada hasta convertirse en una junta improductiva. Cuando se prepara de forma intencional, se convierte en un filtro que encuentra defectos antes de que lleguen al código.

Para qué sirve revisar y qué errores evitar

El propósito central de revisar es detectar cualquier defecto, entendido como una imperfección o deficiencia en el documento que impida cumplir con lo solicitado. Como vimos al explicar la diferencia entre error, defecto y fallo, corregir una deficiencia en los requisitos evita que el código nazca roto.

Toda revisión productiva necesita una meta explícita y criterios de salida cuantificables, que son las condiciones acordadas para declarar concluida la tarea. Si no establecemos qué esperamos lograr y cómo sabremos que terminamos, la sesión carece de límites. Además, existe una regla estricta: evaluar a las personas o medir su rendimiento laboral jamás debe ser el objetivo de una revisión. Cuando los participantes sienten que la sesión evalúa su capacidad profesional, esconden dudas, defienden posturas personales y el análisis técnico desaparece.

El tipo de revisión depende del objetivo

No todas las revisiones requieren la misma ceremonia. La elección del formato responde al riesgo del proyecto, el tiempo disponible y el objetivo buscado. Los estándares internacionales agrupan estas evaluaciones en varios tipos principales:

• Revisión informal: carece de un proceso documentado y no genera un reporte formal de salida. Dos compañeros de equipo pueden sentarse a examinar un fragmento de lógica o una solicitud de cambio (pull request). Su meta principal es hallar anomalías evidentes de manera ágil.
• Revisión guiada (walkthrough): es una sesión conducida por el propio autor del trabajo. El creador guía paso a paso a sus colegas a través del artefacto. Este formato sirve para transferir conocimiento del negocio, capacitar a los integrantes del equipo y construir un entendimiento compartido, además de recoger preguntas y posibles inconsistencias.
• Revisión técnica: está liderada por un moderador capacitado y cuenta con la participación de especialistas técnicos, excluyendo al autor del papel de moderador. Su objetivo es evaluar la idoneidad técnica del artefacto, resolver dilemas de diseño y alcanzar consenso entre colegas calificados.
• Inspección: representa el nivel más formal y estructurado de evaluación humana. Creada por Michael E. Fagan en la década de 1970, utiliza mediciones cuantitativas, reglas estrictas y roles formalmente asignados para identificar el mayor número posible de defectos.

En el desarrollo contemporáneo, la revisión más común ocurre en las solicitudes de cambio de código en plataformas de control de versiones. En 2013, Alberto Bacchelli y Christian Bird observaron en entornos industriales que, aunque la motivación principal para revisar código sigue siendo encontrar defectos, en la práctica estas revisiones aportan mucho más a la transferencia de conocimiento entre ingenieros y a la comprensión compartida del sistema.

Los roles que sostienen el proceso

Una revisión fracasa cuando los asistentes asumen que su única tarea es sentarse a escuchar pasivamente. Para funcionar, el proceso distribuye responsabilidades específicas entre los participantes:

• Líder o gerente: decide qué productos de trabajo entran a revisión, asigna los recursos necesarios y otorga el tiempo laboral indispensable para la tarea.
• Autor: crea el documento o código bajo examen. Su responsabilidad posterior es resolver y corregir los problemas que el equipo confirme.
• Moderador (o facilitador): asegura el buen manejo del tiempo, media en las discusiones técnicas y garantiza un ambiente de respeto donde todos los involucrados puedan expresarse con libertad.
• Escriba (o registrador): documenta con precisión cada anomalía reportada, las decisiones acordadas y las acciones pendientes en un registro formal.
• Revisor: examina con detenimiento el material, aporta su perspectiva técnica o de negocio y señala las inconsistencias encontradas.

Una revisión paso a paso: la historia del descuento

Para entender cómo operan estos principios en la realidad, sigamos el proceso completo sobre una historia de usuario: "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".

1. La preparación y las condiciones de inicio

El líder del equipo define un objetivo claro: verificar la consistencia de las reglas de negocio y su viabilidad técnica. En lugar de enviar un documento de requerimientos completo de varias páginas, aísla una sola historia de usuario como una pieza pequeña y manejable para evitar la fatiga mental.

El líder programa la actividad y protege tiempo formal en el calendario de los revisores para que estudien el texto antes de reunirse. Asigna los roles con anticipación: una persona como moderadora, otra como escriba y dos especialistas como revisores, asegurándose de que cada integrante comprenda el alcance de su función. Además, entrega una lista de verificación corta, diseñada con unas diez preguntas específicas para historias de usuario (por ejemplo, evaluar la claridad de los límites numéricos y el comportamiento ante excepciones).

2. La revisión individual con enfoques distintos

Cada revisor analiza el texto a solas desde una perspectiva técnica distinta. Gracias a este enfoque diferenciado, los defectos aparecen en el documento mucho antes de convocar a una junta:

• El primer revisor, con enfoque en reglas funcionales, detecta tres ambigüedades lógicas: el texto no aclara si llevar exactamente cinco artículos activa el beneficio o si debe superar esa cantidad estricta. Además, nota que la regla incluye una disyunción ("o"): no se especifica si ambas condiciones se acumulan para dar un 20% de descuento ni si existe un tope máximo de ahorro. Por último, señala una palabra vaga: «cliente frecuente» no dice cuántas compras hacen falta ni en qué periodo.
• El segundo revisor, con enfoque contable y de integración, identifica otros dos vacíos: el documento no indica si los mil pesos se calculan antes o después de aplicar el impuesto al valor agregado (IVA). Asimismo, detecta una omisión en el flujo de devoluciones: no se describe qué ocurre con el saldo a favor si el cliente devuelve un producto y el monto final recalculado queda por debajo del umbral mínimo de compra.

3. La reunión de revisión

Con las observaciones ya anotadas, el equipo se reúne en una sesión facilitada por la persona moderadora. Su tarea es mantener la discusión enfocada exclusivamente en el objetivo y asegurar un clima de respeto donde se critique el documento, no la capacidad del autor.

El grupo repasa la lista de anomalías registradas. Durante el análisis, una de las observaciones preliminares —una supuesta incompatibilidad con cupones externos— se descarta tras verificar que la plataforma maneja las promociones de cupones en un módulo totalmente independiente. La anomalía no era un defecto real, sino un falso positivo. El escriba toma nota formal de las cinco inconsistencias confirmadas y registra los acuerdos tomados sin perder tiempo rediseñando soluciones sobre la marcha.

4. Cierre, corrección y retroalimentación

La persona autora recibe el registro formal de defectos y reescribe la historia de usuario para subsanar los vacíos. El proceso concluye cuando se cumplen los criterios de salida pactados: todas las dudas cuentan con una redacción aprobada y sin ambigüedades. Finalmente, la retroalimentación regresa de manera constructiva al autor, lo que le permite entender qué elementos omitió y prevenir deficiencias similares en las siguientes entregas.

Por qué fracasan las sesiones y qué dice la investigación

Cuando las revisiones fallan no suele ser por mala voluntad, sino por descuidar factores organizacionales que el ejemplo anterior resolvió de origen: la falta de capacitación de los miembros sobre su rol, la ausencia de un moderador que neutralice discusiones circulares y la falta de apoyo directivo para respetar el tiempo de lectura. Como vimos al estructurar criterios de entrada y salida de la planeación, iniciar una tarea técnica sin condiciones mínimas garantizadas condena el resultado al fracaso.

En su resumen sobre la investigación de revisiones bajo el estándar ISO/IEC 20246, Stuart Reid aporta conclusiones fundamentales para cualquier equipo de software:

• La preparación a solas concentra los hallazgos: Reid resume que en la revisión individual, cuando cada persona examina el producto en solitario, se detecta la gran mayoría de los defectos.
• La reunión tiene otro propósito: la investigación de los últimos años concluye que, por lo general, la reunión de revisión no incrementa la efectividad en la detección de defectos. Su verdadero valor reside en compartir conocimiento, alcanzar consenso y filtrar falsos positivos. A cambio, la junta representa una parte importante del costo total de revisar, es difícil de coordinar y fuerza a todos a avanzar a la misma velocidad.
• El número adecuado de revisores: agregar revisores en la fase individual ayuda a descubrir más defectos, pero su efectividad depende de su experiencia. Según Reid, un revisor promedio detecta alrededor de un tercio de los defectos. Si se cuenta con personal experimentado, utilizar solo dos revisores suele ser la opción más eficiente en costo y esfuerzo. En la reunión grupal, hacia el quinto participante el costo de la interacción del grupo pesa más que lo que aporta la experiencia individual.
• Listas de comprobación breves: Reid recomienda asignar listas distintas a los revisores para no duplicar esfuerzos. Estas listas deben ser específicas para el producto analizado y contener alrededor de diez elementos, actualizándose con regularidad para retirar preguntas que ya no detectan anomalías e incorporar los problemas que se hayan escapado recientemente. Además, Reid indica que suele ser muy útil ejecutar una revisión informal antes de una formal más costosa, como una inspección, para confirmar que el material esté en condiciones de ser evaluado.

El factor humano: evaluar el producto, jamás al autor

La calidad del software se construye mediante interacciones sociales. Cuando una persona siente que su trabajo es atacado de forma destructiva, adopta una postura defensiva y la revisión técnica fracasa.

La retroalimentación debe dirigirse siempre al producto de trabajo y nunca a la persona que lo creó. En lugar de señalar "redactaste mal la condición del descuento", la observación constructiva se formula sobre el texto: "la cláusula no define qué ocurre si el cliente devuelve un producto". La persona que modera tiene la obligación de frenar cualquier comentario personal y sostener un espacio donde expresar dudas sea una práctica segura y constructiva.

Guía rápida para preparar la siguiente revisión

Antes de enviar una nueva invitación de calendario, conviene verificar que se cumplan las siguientes condiciones:

1. Objetivo claro: declarar en un enunciado qué busca el equipo (por ejemplo, detectar vacíos en las reglas comerciales o validar la viabilidad técnica).
2. Piezas pequeñas: limitar el material a una extensión que los participantes puedan leer con atención sin agotarse.
3. Tiempo de estudio protegido: asegurar que las agendas de los revisores cuenten con margen para estudiar el documento a solas antes de reunirse.
4. Roles asignados: definir con anticipación quién modera, quién registra las notas y quiénes revisan con enfoques complementarios.
5. Lista de comprobación acotada: entregar una guía de alrededor de diez preguntas directas y relevantes para ese producto de trabajo.
6. Criterios de salida conocidos: pactar de antemano qué condiciones deben cumplirse para dar por terminada la revisión.

El rendimiento de una revisión de software se decide mucho antes de entrar a la sala. Si el equipo define metas claras, fracciona los documentos, asigna roles y protege el tiempo de estudio individual, las revisiones dejan de ser una junta improductiva y empiezan a encontrar defectos.

Fuentes

• Bacchelli, Alberto, y Bird, Christian, 2013. "Expectations, Outcomes, and Challenges of Modern Code Review." ICSE 2013. https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/ICSE202013-codereview.pdf
• Fagan, Michael E., 1976. "Design and Code Inspections to Reduce Errors in Program Development." IBM Systems Journal 15(3): 182-211; resumen en IfSQ. https://www.ifsq.org/work-fagan-1976.html
• ISTQB, 2024. "Certified Tester Foundation Level Syllabus v4.0.1." International Software Testing Qualifications Board, §3.2. https://www.istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/
• Reid, Stuart, 2018. "Software Reviews using ISO/IEC 20246." stureid.info. https://www.stureid.info/wp-content/uploads/2018/01/Software-Reviews.pdf
• Glosario ISTQB (International Software Testing Qualifications Board). https://glossary.istqb.org/es_ES/home