Los defectos se agrupan, y saber dónde cambia todo

Todos los equipos tienen uno: ese módulo que siempre da problemas. Da igual cuántas veces lo arregles, siempre vuelve a romperse. Cada retrospectiva alguien menciona que habría que reescribirlo, pero nunca hay tiempo. Los tickets de soporte se acumulan alrededor de las mismas pantallas, los mismos flujos, los mismos tres archivos que nadie quiere tocar. Si esto te suena familiar, no es casualidad. Hay un principio que explica por qué ocurre, y entenderlo puede cambiar cómo distribuyes el esfuerzo de testing en tu equipo.

El principio de agrupamiento de defectos

ISTQB lo define como su cuarto principio fundamental: “Defect clustering”. La formulación es directa. Un número pequeño de módulos suele contener la mayoría de los defectos descubiertos durante el testing previo al release, o es responsable de la mayoría de los fallos operativos en producción.

Este comportamiento no es exclusivo del software. El principio de Pareto, formulado por el economista italiano Vilfredo Pareto a finales del siglo XIX, describe un patrón de distribución desigual que aparece en campos muy diversos. En testing, la versión más conocida dice que el 80 % de los defectos se concentra en el 20 % del código. Los porcentajes exactos varían según el proyecto, pero la tendencia es consistente: los bugs no se distribuyen de forma uniforme.

Capers Jones, uno de los investigadores más prolíficos en métricas de software, documentó este patrón analizando miles de proyectos a lo largo de varias décadas. Sus datos confirman que la densidad de defectos varía enormemente entre módulos dentro del mismo sistema, y que los módulos más problemáticos tienden a serlo de forma persistente.

Por qué los defectos se agrupan

No es cuestión de mala suerte. Hay razones técnicas y organizativas que explican por qué ciertos módulos atraen defectos como imanes.

• La complejidad ciclomática alta es uno de los factores más directos. Un módulo con muchas ramas condicionales, bucles anidados y caminos de ejecución posibles tiene más superficie para albergar defectos. Es aritmética pura: más caminos significan más combinaciones que validar y más oportunidades para que algo falle.
• El código legacy sin tests es un clásico. Nadie se atreve a tocarlo porque no hay red de seguridad, así que cada cambio es una apuesta. Los parches se acumulan unos sobre otros y la deuda técnica crece hasta que el módulo se convierte en una zona de riesgo permanente.
• La alta rotación de desarrolladores en ciertos módulos genera un problema de contexto. Cada persona que pasa por el código entiende una parte, añade su lógica y se va. Con el tiempo, nadie tiene una visión completa de cómo funciona el conjunto, y las interacciones no documentadas entre componentes se convierten en fuente constante de bugs.
• Las integraciones con sistemas externos concentran defectos porque dependen de contratos que pueden cambiar, de servicios con latencia variable y de formatos de datos que no siempre cumplen la especificación. El módulo que habla con tres APIs externas será siempre más frágil que el que solo lee de una tabla local.
• Las zonas con requisitos cambiantes acumulan defectos simplemente porque se modifican con más frecuencia. Cada cambio es una oportunidad para introducir una regresión, y los módulos que se tocan mucho son los que más regresiones sufren.

Ejemplos que reconocerás

El más universal es el formulario de registro. En casi todos los productos en los que he trabajado, el flujo de registro y login es una de las zonas con mayor concentración de tickets. Validaciones de email, políticas de contraseñas, flujos de recuperación, integración con OAuth, verificación en dos pasos, todo se acumula en un punto que además es la puerta de entrada del usuario. Si falla ahí, no hay producto.

Otro clásico es el módulo de facturación o pagos. Combina lógica de negocio compleja con integraciones externas, normativa fiscal que cambia, múltiples divisas, descuentos, impuestos y casos límite que aparecen en los momentos menos oportunos. En un proyecto donde trabajé, el 40 % de los bugs de producción durante seis meses venían del módulo de facturación, que representaba menos del 10 % del código total.

Y luego está el código que nadie quiere tocar. Ese archivo de dos mil líneas que lleva tres años sin una refactorización seria, escrito por alguien que ya no está en la empresa, con comentarios crípticos y una estructura que desafía cualquier intento de comprensión rápida. Todos saben que es un problema, pero el coste percibido de arreglarlo siempre parece mayor que el de seguir parcheándolo.

Errores comunes al ignorar este principio

El error más frecuente es distribuir el esfuerzo de testing de forma uniforme por todo el sistema. Si dedicas el mismo tiempo a probar el módulo de "Acerca de" que al motor de pagos, estás desperdiciando recursos. Los defectos no se distribuyen uniformemente y tu esfuerzo de testing tampoco debería hacerlo.

Otro problema habitual es no analizar los datos que ya tienes. La mayoría de los equipos disponen de un sistema de seguimiento de bugs, ya sea Jira, Linear, GitHub Issues o cualquier otro. Esos datos contienen información valiosa sobre dónde se concentran los problemas, pero sorprendentemente pocos equipos los analizan de forma sistemática. Se corrige el bug, se cierra el ticket y se pasa al siguiente sin preguntarse si hay un patrón.

También es común confundir síntomas con causas. Que un módulo tenga muchos bugs reportados puede significar que tiene muchos defectos, sí, pero también puede significar que es el más usado y por tanto el más observado. O que los usuarios de ese módulo son más exigentes o más propensos a reportar problemas. Antes de reasignar esfuerzo de testing, conviene entender por qué los defectos se concentran ahí.

Por último, hay equipos que caen en la trampa de solo probar los hotspots. El principio dice que los defectos se agrupan, no que los módulos sin defectos conocidos estén libres de bugs. Si abandonas completamente el testing del resto del sistema, estás creando nuevos puntos ciegos. El equilibrio correcto es dedicar más esfuerzo a las zonas de alto riesgo sin descuidar el resto.

Cómo aplicarlo en tu equipo

Analiza tus datos de bugs

El primer paso es saber dónde se concentran los defectos en tu proyecto. Extrae los bugs de los últimos seis meses de tu herramienta de tracking y agrúpalos por módulo, funcionalidad o componente. No necesitas herramientas sofisticadas para esto, ya que una hoja de cálculo es suficiente. Ordena por frecuencia y verás aparecer los hotspots. Casi siempre, dos o tres zonas concentran la mayoría de los problemas.

Si quieres ir un paso más allá, cruza esa información con la severidad. No es lo mismo diez bugs cosméticos en un módulo que tres bugs críticos en otro. Un análisis que combine frecuencia y severidad te dará una imagen mucho más útil de dónde enfocar el esfuerzo.

Usa herramientas de detección de hotspots en el código

CodeScene es probablemente la herramienta más conocida para esto. Analiza el historial de Git y cruza la frecuencia de cambios con la complejidad del código para identificar los archivos que son a la vez complejos y muy modificados. Esas son las zonas de mayor riesgo. Otras herramientas como SonarQube también ofrecen métricas de complejidad y mantenibilidad que ayudan a identificar módulos problemáticos.

La idea es no depender solo de la intuición del equipo para saber dónde están los problemas. Los datos del repositorio contienen señales objetivas que complementan la experiencia de las personas.

Prioriza el testing basándote en riesgo

Una vez que conoces tus hotspots, ajusta la distribución del esfuerzo de testing. Los módulos con alta densidad de defectos, complejidad elevada o importancia crítica para el negocio deberían recibir más atención: más tests automatizados, más testing exploratorio, revisiones de código más exhaustivas.

En la práctica, esto puede significar que el módulo de pagos tiene un 85 % de cobertura de tests y sesiones de testing exploratorio mensuales, mientras que la página de "Preguntas frecuentes" tiene un smoke test básico. No es que una sea más importante que otra en abstracto, sino que el historial de defectos y el impacto en el negocio justifican una asignación desigual.

Métricas de densidad de defectos por módulo

Introduce una métrica sencilla en tus retrospectivas o informes de calidad: número de defectos por módulo en el último ciclo. No hace falta sofisticar más la fórmula al principio. Con el tiempo puedes normalizarla por líneas de código o por número de cambios, pero el valor real está en hacer visible la distribución y observar cómo evoluciona.

Si un módulo aparece consistentemente en los primeros puestos, es una señal clara de que necesita intervención. Quizá más tests, quizá una refactorización, quizá ambas cosas. Pero el primer paso es hacerlo visible para que el equipo pueda tomar decisiones informadas.

Invierte en la causa raíz, no solo en más tests

A veces el problema no es que falten tests, sino que el código es inherentemente frágil. Un módulo con una complejidad ciclomática de 50 va a seguir generando defectos por mucho que lo pruebes, porque las interacciones entre sus ramas son demasiadas para cubrirlas todas. En esos casos, la solución más efectiva a largo plazo es refactorizar el módulo para reducir su complejidad, idealmente acompañado de tests que protejan la refactorización.

En mi experiencia, convencer al equipo de dedicar tiempo a refactorizar un módulo problemático es mucho más fácil cuando puedes mostrar datos concretos: “Este módulo ha generado 23 bugs en los últimos tres meses y representa el 35 % de nuestro tiempo de debugging. Invertir dos sprints en refactorizarlo nos ahorrará ese coste de forma recurrente”. Los datos transforman una opinión en un argumento de negocio.

Los datos te dicen dónde mirar

El principio de agrupamiento de defectos no es una curiosidad teórica. Es una herramienta práctica para tomar mejores decisiones sobre dónde invertir tiempo y esfuerzo de testing. Los defectos no se distribuyen de forma aleatoria y tu estrategia de testing no debería ser aleatoria tampoco.

Conocer tus hotspots te permite ser más eficiente con recursos limitados, porque siempre hay más funcionalidad que probar que tiempo disponible. La clave está en usar los datos que ya tienes para enfocar el esfuerzo donde más impacto produce.

Si solo puedes hacer una cosa esta semana, haz esta: extrae los bugs de tu proyecto de los últimos tres a seis meses, agrúpalos por módulo y mira qué patrón aparece. Apuesto a que el 80 % de los problemas viene del mismo puñado de sitios. Una vez que lo veas con datos, las decisiones sobre dónde enfocar el testing se toman solas.