En el marco teórico, la deuda técnica no es un tema paralelo a la gestión de riesgos: es una de sus variables de entrada y, a la vez, uno de sus productos residuales. La relación se cierra en un ciclo.

La deuda como causa (entra al modelo de riesgo). 

La matriz de calor dinámica define la Probabilidad de fallo «basada en complejidad técnica, deuda técnica y frecuencia de uso». Es decir, la deuda técnica es un factor que empuja los riesgos de producto hacia arriba en el eje de Probabilidad: código frágil o sin pruebas unitarias falla más seguido y de forma menos predecible, comprometiendo atributos ISO 25010 (fiabilidad, seguridad). 

En paralelo, la misma deuda golpea al riesgo de proyecto por el lado del esfuerzo: establece que en sistemas con alta deuda el esfuerzo de prueba no es lineal sino exponencial, y obliga a aplicar un «impuesto de deuda» a las estimaciones en áreas heredadas (3X a 5X). Un mismo activo con deuda alta, entonces, mueve puntos hacia la zona roja del heatmap por ambos ejes a la vez: sube la probabilidad de fallo (producto) y consume cronograma y capacidad (proyecto).

La deuda como consecuencia (sale del modelo como riesgo residual). 

Cuando un riesgo de proyecto se materializa —presión de fechas que fuerza recortar la regresión, u overrides silenciosos de los quality gates— el riesgo no desaparece: se capitaliza como nueva deuda de validación o de pruebas. Es un préstamo con interés, y ese interés se paga después en forma de defectos escapados a producción. Por eso el Defect Escape Rate funciona como termómetro de la deuda que quedó impaga.

El puente que aporta el test management. 

El aporte estratégico del líder de QA es hacer esa deuda visible, cuantificable y priorizable en términos de riesgo. 

La matriz de calor (P×I) traduce la deuda —un problema abstracto de ingeniería— a un lenguaje de negocio (impacto y probabilidad), y las métricas de valor (Test Debt Index, DER, MTTR) actúan como sensores que monitorean cómo esa deuda «viaja» sprint a sprint. 

En síntesis: gestionar deuda técnica es, teóricamente, una acción de mitigación de doble efecto, porque reduce simultáneamente la probabilidad del riesgo de producto y la incertidumbre del riesgo de proyecto. 

El dashboard que armé materializa justamente ese circuito: convierte novedades (defectos, bugs, historias) en ítems de deuda priorizados que retroalimentan el riesgo residual.

Análisis del dashboard «Torre de control · Riesgos y deuda técnica» — Rol: Test Manager

1. Composición general

El dashboard se apoya en seis KPI fijos en la cabecera —riesgos críticos abiertos (6), cobertura de riesgo (40%), ítems de deuda abiertos (18), deuda a atender ahora (11), Defect Escape Rate (57%) y MTTR estimado (4 días)— que actúan como resumen ejecutivo permanente, visible sin importar la solapa activa. Debajo de ese resumen se despliegan cinco solapas con propósitos diferenciados pero interconectados por un mismo modelo de datos.

Solapa «Panel de control»

Objetivo y alcance: ofrecer una vista consolidada y visual del estado global de riesgos y deuda, pensada para lectura rápida en comités o daily/weekly de calidad. 

Contenido: 

• la matriz de calor dinámica Probabilidad×Impacto (grilla 5×5 coloreada por zona: crítico, alto, medio, bajo, con el conteo de riesgos en cada celda); 
• la matriz de deuda técnica valor vs. esfuerzo (gráfico de burbujas con cuatro cuadrantes —ganancias rápidas, grandes apuestas, rellenos, reconsiderar— donde el tamaño de burbuja representa el WSJF); 
• un donut de composición de la deuda por tipo de novedad (bug de producción, defecto dev/test, historia de usuario, deuda de automatización, test flaky, documentación, refactor); 
• un gráfico de barras de distribución por prioridad de acción (atender ahora, próximo sprint, backlog, diferir/monitorear); 
• un gráfico de aging o antigüedad de la deuda (bandas 0-7, 8-14, 15-21, 22-30 y más de 30 días); 
• y un gráfico de riesgos por atributo de calidad ISO 25010 segmentado entre producto y proyecto.

Solapa «Riesgos»

Objetivo y alcance: es el módulo de carga y administración del registro de riesgos, distinguiendo riesgo de producto (falla del software) de riesgo de proyecto (amenazas a cronograma, entorno o presupuesto). Contenido: una tabla editable con columnas ID, categoría, descripción, atributo de calidad, contexto (empresa/proyecto), probabilidad, impacto, score P×I, zona, estado (abierto, en mitigación, aceptado) y plan de mitigación, con filtros por categoría y estado y un botón para registrar nuevos riesgos.

Solapa «Deuda técnica y novedades»

Objetivo y alcance: es la puerta de entrada de las novedades operativas que alimentan la deuda —defectos dev/test, bugs de producción, historias de usuario del próximo sprint, deuda de automatización, tests flaky, documentación y refactor— y donde se calcula automáticamente su priorización. Contenido: tabla con ID, tipo, descripción, contexto, severidad, valor de negocio, criticidad temporal, reducción de riesgo, esfuerzo, WSJF calculado, acción recomendada, días de antigüedad y, de forma crítica, un campo «riesgo» que vincula cada ítem de deuda con un riesgo registrado en la solapa anterior (marcado como «prioritario» cuando ese riesgo es crítico o alto).

Solapa «Priorización y decisiones»

Objetivo y alcance: traducir todo lo anterior en una cola de trabajo accionable para la toma de decisiones de sprint. Contenido: un listado ordenado de forma descendente por WSJF (1 a 18), donde cada ítem muestra su score, tipo, empresa/contexto, esfuerzo, antigüedad, el riesgo vinculado (marcado como prioritario si corresponde) y una etiqueta de acción recomendada.

Solapa «Método y trazabilidad»

Objetivo y alcance: documentar de forma transparente («sin puntajes ocultos») las fórmulas y umbrales que sostienen todo el dashboard. Contenido: explicación del cálculo de la matriz de calor P×I, la fórmula completa del WSJF (valor de negocio + criticidad temporal + reducción de riesgo, dividido esfuerzo), los umbrales de clasificación de acción, la definición de las métricas de valor (Defect Escape Rate, cobertura de riesgo, MTTR) y la trazabilidad con el marco de referencia utilizado.

2. Relación y dependencia entre solapas

Las solapas no son módulos independientes sino un mismo flujo de datos visto desde distintos ángulos. «Riesgos» es la fuente primaria de amenazas; «Deuda técnica y novedades» ingiere hechos operativos (bugs, defectos, historias) y los enlaza a esos riesgos, calculando el WSJF; «Priorización y decisiones» es una proyección ordenada de esa misma tabla de deuda, sin datos propios; «Panel de control» es la capa de visualización agregada que resume ambos registros (riesgos y deuda) en KPIs y gráficos; y «Método y trazabilidad» es la capa de auditoría que explica cómo se derivan los números que aparecen en todas las demás. 

En consecuencia, cualquier cambio en «Riesgos» (por ejemplo, escalar un riesgo a crítico) recalcula automáticamente la zona en la matriz de calor, puede modificar la marca «prioritario» en los ítems de deuda vinculados y reordena la cola de «Priorización y decisiones»; del mismo modo, cargar una novedad nueva en «Deuda técnica» altera de inmediato los KPI y los gráficos del «Panel de control».

3. Cómo debe leerlo e interpretarlo el Test Manager / Test Lead

La lectura correcta no es lineal por solapa sino por ciclo de gestión de riesgo. El punto de entrada recomendado es el Panel de control, para captar de un vistazo la salud general (¿Cuántos riesgos están en zona roja?, ¿Qué proporción de la deuda está en «atender ahora»?, ¿El Defect Escape Rate está en niveles aceptables?). 

Luego se debe bajar a «Riesgos» para validar que la probabilidad e impacto asignados reflejen la realidad actual del producto y no estén desactualizados, y a «Deuda técnica y novedades» para confirmar que cada novedad recién ingresada tenga bien cargados sus factores de WSJF (un esfuerzo o valor de negocio mal estimado distorsiona toda la priorización). 

La solapa «Priorización y decisiones» es la que el Test Manager debe usar operativamente para decidir qué se ataca en el sprint actual, priorizando siempre los ítems marcados como «prioritario» por estar atados a un riesgo crítico o alto, incluso si su WSJF numérico no es el más alto de la lista. «Método y trazabilidad» debe consultarse cada vez que alguien cuestione un número, para defender la metodología con la fórmula visible en lugar de una caja negra.

En cuanto a qué debe suministrar el Test Manager al equipo de proyecto: el estado consolidado de riesgos críticos y su plan de mitigación, la cola priorizada de deuda técnica ya traducida a lenguaje de negocio (qué se atiende primero y por qué, no solo el número WSJF), las métricas de calidad accionables (Defect Escape Rate, MTTR, cobertura de riesgo) con su tendencia sprint a sprint, y alertas tempranas cuando un ítem de deuda supere los 21-30 días de antigüedad (riesgo residual creciente) o cuando un riesgo de proyecto (presión de fechas, entorno compartido) amenace con degradar la regresión.

4. Información que deben suministrar los demás roles e interesados

El Product Owner debe aportar el valor de negocio y la criticidad temporal de cada historia o defecto (insumos directos del cálculo WSJF), además de decidir sobre los riesgos de producto aceptados versus los que requieren mitigación, ya que sin su criterio de negocio la priorización pierde sentido comercial. 

El Product Manager debe proveer la visión de roadmap y prioridades estratégicas de producto que permitan contrastar si la cola priorizada por WSJF es coherente con los objetivos de negocio de mediano plazo, y validar el impacto reputacional o de mercado de los riesgos críticos (por ejemplo, exposición de datos o cumplimiento normativo). 

El Project Manager debe suministrar información de cronograma, capacidad del equipo y presupuesto, insumos clave para estimar correctamente el «esfuerzo» en la fórmula WSJF y para evaluar los riesgos de proyecto (dependencias, entornos compartidos, presión de fechas) que aparecen en la matriz de calor. 

Los stakeholders y key users, por su parte, deben aportar la validación funcional del impacto real de cada riesgo de producto desde la perspectiva del usuario final (severidad percibida, frecuencia de uso de la funcionalidad afectada) y comunicar tempranamente nuevas necesidades o cambios de alcance que se traduzcan en historias de usuario a cargar en «Deuda técnica y novedades», cerrando así el ciclo de retroalimentación que mantiene vivo el dashboard.

Fuente de consulta e inspiración: Trazabilidad BCU: Unidad 3 — Gestión basada en riesgos (MO_3_1 §3.2 y MO_3_3 §2.1), con anclajes en la Unidad 1.3 (Risk-Based Testing Canvas) y 1.4/1.1 (testware y Test Debt)