Introducción — El rol del Test Manager de IA frente a la deuda técnica generada por asistentes/agentes

El artículo de José Alfonso Guerrero Juárez – IA y deuda técnica: ¿la está reduciendo o multiplicando? –  plantea una tensión legítima desde la óptica del desarrollo: la IA generativa puede tanto multiplicar como reducir la deuda técnica, y la diferencia está en la disciplina de verificación que rodea al código producido. Desde la perspectiva del aseguramiento y control de calidad de software, ese planteamiento -a mi modo de ver y para complementar lo tan bien expuesto por José Alfonso para elevar aún más el conocimiento- no es solo un problema de «buenas prácticas de desarrollo», sino un problema de gobierno de calidad que un Test Manager o Test Lead especializados en IA debe institucionalizar como parte de la estrategia de pruebas, habiéndolo acordado con el equipo de proyecto.

Bajo el marco ISTQB CTAL-TM, la responsabilidad del Test Manager ó Test Lead no termina en la planificación y estrategia de los diseños de la cobertura de prueba: incluye definir la estrategia de riesgo, los criterios de entrada/salida, y los mecanismos de control que aseguran que ningún artefacto —humano o generado por IA— entre a producción sin pasar por un gate de verificación objetivo. El enfoque de Holistic Testing refuerza esto al recordar que la calidad no es una fase posterior al código, sino una responsabilidad distribuida a lo largo de todo el ciclo, que ahora debe extenderse explícitamente a los agentes generativos que participan en la escritura de código.

Aquí me detengo para reflexionar unos instantes sobre este último punto: ahora más que nunca enfrentamos el gran desafío de aplicar / implementar las buenas prácticas de “trabajar en equipo” e “implementar testing de manera temprana (shift-left)”. Hay que hacerles ver a los directores y/o managers que no es un bloqueo ni costo, sino todo lo contrario, porque de no aplicar estas buenas prácticas y ahora más aún con los desarrollos impulsados con IA que se van generando y creciendo, los costos directos e indirectos aumentarán a partir de los retrabajos que se generarán, con las consecuencias que eso trae.

OK, salgo de la reflexión y vuelvo al tema central. 

Lo que el autor -a mi entender- describe como «errores silenciosos y repartidos» (hrefs mal formados, imports faltantes) es, en términos de testing, deuda técnica no detectada por ausencia de verificación estática y dinámica sistemática. La respuesta desde QA no es desconfiar de la IA ni mucho menos pensar para que alguien la prohíba, sino diseñar un segundo nivel de control: un agente de IA especializado en testing que revise, con criterios de caja blanca y con acceso a fuentes oficiales del lenguaje, lo que otro agente (o un desarrollador asistido por IA) produjo. Esto es exactamente el rol que un Test Manager o Test Lead de IA Generativa aplicada a Testing con conocimientos además en testear aplicaciones de IA debe diseñar: no reemplazar el juicio humano, sino construir *prompt frameworks* reutilizables, auditables y trazables que actúen como control de calidad, antes de que el código llegue a integración o producción.

Te comparto las estructuras de dos prompt frameworks, uno por escenario -de los planteados por José Alfonso-, ambos parametrizables por lenguaje y stack, y diseñados para ser ejecutados por un agente de IA con capacidad de herramientas (tool use / acceso a documentación oficial), no solo como un prompt de una sola pasada.

Sólo por si no has leído el artículo publicado por José Alfonso, menciona dos escenarios sobre los cuales me puse a investigar y de ahí a que resultó este trabajo.

Escenario A – Multiplica la deuda
Escenario B – Reduce la deuda

Te recomiendo que antes de seguir leyendo, accedas al buen contenido elaborado por José Alfonso y después sí, con “contexto” regreses por aquí para terminar de comprender la idea que te comparto.

Desarrollo de los Prompt Frameworks

Principio transversal a ambos frameworks

Antes de entrar en cada escenario, conviene fijar tres decisiones de diseño que aplican a ambos frameworks, porque son las que garantizan que el agente de QA no «alucine» buenas prácticas:

Primero: El agente nunca debe evaluar sintaxis o convenciones de memoria propia; debe anclarse a una fuente oficial del lenguaje (documentación oficial, guía de estilo del lenguaje, linter de referencia mantenido por la comunidad/lenguaje oficial) recuperada mediante una herramienta de búsqueda o consulta de documentación antes de emitir un veredicto. 

Segundo: El agente debe aplicar técnicas de diseño de casos de prueba de caja blanca (cobertura de sentencias, cobertura de condiciones/decisión, análisis de flujo de control y de rutas) no para diseñar pruebas nuevas desde cero, sino para verificar que el fragmento generado sea «testeable» (¿Te suena el enfoque “SMART”?) y que no existan rutas de código inalcanzables o mal formadas introducidas por la generación con IA.

Tercero: Cada framework debe producir una salida estructurada y trazable (severidad, ubicación, evidencia, recomendación), de forma que alimente métricas de gestión de defectos según CTAL-TM (densidad de defectos por origen: humano vs. IA, tendencia por herramienta/versión, etc.).

Prompt Framework A — «Auditor de Código Generado» 

(Mitigación del Escenario A: Multiplica la deuda)

**Objetivo del framework:** detectar exactamente las condiciones que el autor describe como causantes de multiplicación de deuda: código aceptado sin revisión, sintaxis/imports/rutas no verificados, uso de herramientas sin preview/compilación integrada, y acumulación dispersa de errores en el proyecto.

Estructura recomendada del prompt (rol – contexto – fuente de verdad – checklist – formato de salida):

«`

ROL:

Actúas como Agente de QA Estático especializado en auditoría de código generado por IA. No generas código nuevo ni corriges directamente:

tu función es detectar, clasificar y evidenciar defectos.

CONTEXTO DE ENTRADA:

– Lenguaje/stack: {LENGUAJE} (ej. React/JSX, Swift, Python, etc.)

– Fragmento o commit a auditar: {CODE_SNIPPET / DIFF}

– Herramienta de generación usada (si se conoce): {TOOL_NAME + VERSION}

– Historial de errores previos del proyecto (si existe): {ERROR_LOG}

PASO 1 — ANCLAJE A FUENTE OFICIAL (obligatorio antes de evaluar):

Antes de emitir cualquier hallazgo, consulta la documentación oficial del lenguaje/framework declarado en {LENGUAJE} (p. ej. developer.mozilla.org y react.dev para JSX/HTML; docs.swift.org y Swift API Design Guidelines para Swift; docs.python.org y PEP 8 para Python; documentación oficial del framework correspondiente). Cita la regla oficial en la que basas cada hallazgo. Si no puedes acceder a una fuente oficial, indícalo explícitamente como limitación en vez de asumir la regla de memoria.

PASO 2 — VERIFICACIÓN SINTÁCTICA Y ESTRUCTURAL:

– Verifica que cada etiqueta/bloque esté correctamente abierto y cerrado (HTML/JSX: <a href>, componentes anidados, cierres huérfanos).

– Verifica balance de paréntesis, llaves, indentación significativa según la gramática oficial del lenguaje.

– Reporta cualquier fragmento que no sea válido para un parser/compilador del lenguaje declarado, aunque «se vea bien» visualmente.

PASO 3 — VERIFICACIÓN DE IMPORTS Y DEPENDENCIAS:

– Lista cada símbolo/API usado en el fragmento y confirma que su módulo/framework de origen esté explícitamente importado (ej. Combine en Swift, hooks de React, librerías de terceros).

– Señala imports faltantes, imports no utilizados y dependencias con versión incompatible según el manifiesto del proyecto (package.json,

  Package.swift, requirements.txt, etc.).

PASO 4 — VERIFICACIÓN DE RUTAS Y REFERENCIAS:

– Verifica que rutas (href, imports relativos, endpoints, paths de archivos) existan o sigan el patrón de enrutamiento oficial del

  framework declarado.

– Marca rutas hardcodeadas, rutas rotas o inconsistentes con el árbol de rutas del proyecto.

PASO 5 — MADUREZ DE LA HERRAMIENTA DE GENERACIÓN:

– Con base en {TOOL_NAME + VERSION}, determina si la herramienta declara o evidencia capacidad de revisión/preview/compilación previa a la

  entrega del código.

– Si no se puede confirmar esa capacidad, clasifica el fragmento como «riesgo alto de deuda no detectada» y exige verificación manual

  adicional antes de aceptar el código.

PASO 6 — DETECCIÓN DE ACUMULACIÓN DISPERSA:

– Compara los hallazgos actuales contra {ERROR_LOG} para identificar patrones recurrentes (mismo tipo de error en múltiples archivos/PRs).

– Si el mismo patrón aparece en 3+ ubicaciones, elévalo a «deuda sistémica» y recomienda una regla de linter/CI que lo prevenga a

  futuro, no solo la corrección puntual.

FORMATO DE SALIDA (obligatorio):

| Severidad | Archivo/Línea | Tipo de defecto | Regla oficial citada | Evidencia (fragmento) | Recomendación | ¿Es patrón recurrente? (S/N)

«`

Este framework opera como control de entrada previo a integración: su salida alimenta el criterio de «Definition of Done» ampliado por IA que el Test Manager ó Test Lead define en la estrategia de pruebas.

Prompt Framework B — «Validador de Compilación, Pruebas y Refactor» 

(Potenciación del Escenario B: Reduce la deuda)

**Objetivo del framework:** confirmar que la compilación y las pruebas del fragmento se ejecutaron realmente (no solo que «el preview se ve bien»), identificar patrones de error típicos del stack/desarrollador, y auditar específicamente los refactors de código legado asistidos por IA.

«`

ROL:

Actúas como Agente de QA Dinámico especializado en validación de compilación/ejecución y en auditoría de refactorización de código

legado asistida por IA.

CONTEXTO DE ENTRADA:

– Lenguaje/stack: {LENGUAJE}

– Evidencia de compilación/build: {BUILD_LOG o «no disponible»}

– Evidencia de ejecución de pruebas: {TEST_REPORT o «no disponible»}

– Fragmento refactorizado + versión legada original: {DIFF_LEGACY}

– Bitácora de patrones de error conocidos del equipo/stack: {KNOWN_PATTERNS}

PASO 1 — ANCLAJE A FUENTE OFICIAL:

Consulta la documentación oficial de build/test del lenguaje o framework (ej. guías oficiales de compilación de Swift/Xcode,

documentación oficial de pytest/unittest, guía oficial de build de Node/React) para validar que el proceso de build/test reportado sigue

el flujo estándar recomendado, no un atajo que oculte fallos.

PASO 2 — VALIDACIÓN DE COMPILACIÓN/EJECUCIÓN REAL:

– Exige evidencia de {BUILD_LOG} y {TEST_REPORT}; si no existen, detén la validación y clasifica el fragmento como «no verificado:

  no ejecutado», sin asumir corrección por apariencia visual.

– Si existen, confirma código de salida exitoso, ausencia de warnings críticos y cobertura ejecutada sobre el fragmento modificado.

PASO 3 — DISEÑO/REVISIÓN DE CASOS DE CAJA BLANCA SOBRE EL FRAGMENTO:

– Reconstruye el grafo de flujo de control del fragmento y verifica cobertura de sentencias y de decisión/condición sobre las rutas

  nuevas o modificadas.

– Señala ramas condicionales, manejo de errores (try/catch, guard, optional unwrapping) o casos límite no cubiertos por las pruebas

  reportadas.

PASO 4 — PATRONES DE ERROR TÍPICOS DEL STACK/DESARROLLADOR:

– Contrasta los hallazgos contra {KNOWN_PATTERNS} (bitácora acumulada de errores recurrentes propios del stack o del desarrollador, según

  recomienda documentar el autor del artículo).

– Si aparece un patrón ya documentado, repórtalo como «reincidencia conocida» y sugiere una regla automatizable (lint rule, pre-commit

  hook, test unitario permanente) para prevenirlo estructuralmente.

PASO 5 — AUDITORÍA DE REFACTOR DE CÓDIGO LEGADO:

– Compara {DIFF_LEGACY} funcionalidad por funcionalidad: confirma que el comportamiento observable no cambió salvo que el refactor lo

  buscara explícitamente.

– Verifica que el refactor no haya introducido regresiones de seguridad (validación de entradas, manejo de datos sensibles,

  control de acceso) ni deuda nueva al «modernizar» el código.

– Señala si el refactor eliminó pruebas o cobertura existente sin reemplazo equivalente.

PASO 6 — DIMENSIÓN DE SEGURIDAD (calidad + seguridad del código):

– Evalúa el fragmento contra prácticas de seguridad oficiales del lenguaje/stack (ej. OWASP para inyección/XSS en rutas y HTML/JSX,

  guías oficiales de manejo seguro de memoria/concurrencia en Swift, manejo seguro de dependencias y secretos).

– Clasifica cualquier hallazgo de seguridad con severidad propia, independiente de la severidad funcional.

FORMATO DE SALIDA (obligatorio):

| Verificado (S/N) | Evidencia de build/test | Cobertura caja blanca (sentencia/decisión) | Patrón reincidente | Riesgo de seguridad |

Recomendación de prevención estructural (lint/hook/test)

«`

Acceso a fuentes oficiales por lenguaje: cómo lo resuelve el agente

Ambos frameworks dependen de que el agente no «recuerde» reglas, sino que las **recupere** de una fuente autorizada antes de dictaminar. En términos de diseño de agente esto se resuelve dándole al Test Manager o Test Lead de IA una capa de herramientas (tool use / RAG) que el prompt invoca explícitamente en el Paso 1 de cada framework: acceso a documentación oficial del lenguaje (por ejemplo MDN y react.dev para JS/JSX, docs.swift.org para Swift, docs.python.org/PEP para Python, documentación oficial de Java/Kotlin/Go según corresponda), a las guías de estilo oficiales o ampliamente adoptadas por el mantenedor del lenguaje, y a la configuración recomendada de linters oficiales del ecosistema (ESLint config recomendada, SwiftLint, flake8/ruff, etc.). 

El Test Manager debe versionar estas fuentes como parte de la base de conocimiento del agente y revisarlas periódicamente, ya que —como señala el propio autor del artículo— las herramientas y sus capacidades de revisión evolucionan rápido, y una fuente desactualizada reintroduce exactamente el riesgo del Escenario A.

Integración de las recomendaciones del autor 

(«Cómo sigo previniendo estos errores»)

El checklist personal que describe el autor se traduce, en un enfoque de QA gobernado, en controles institucionalizados y no dependientes de la memoria individual del desarrollador: 

• la exigencia de «compilar o correr siempre» se convierte en el Paso 2 del Framework B como criterio de bloqueo (no verificado = no aceptado); 
• la revisión explícita de imports se convierte en el Paso 3 del Framework A; la verificación de sintaxis HTML/JSX pasa a ser el Paso 2 del Framework A; 
• la actualización de herramientas se convierte en el Paso 5 del Framework A, evaluando la madurez de la herramienta generadora como factor de riesgo; 
• y la documentación de patrones de error propios se convierte en {KNOWN_PATTERNS} y {ERROR_LOG}, bitácoras vivas que ambos frameworks consultan y alimentan en cada ejecución, generando así una mejora continua medible en línea con la mejora de procesos de prueba que promueve CTAL-TM.

Con esta arquitectura, el Test Manager o Test Lead de IA no depende de la buena voluntad o memoria del desarrollador para prevenir deuda técnica: convierte esa disciplina en un gate de calidad automatizado, auditable y trazable, aplicable a cualquier lenguaje mediante la parametrización de {LENGUAJE}, {TOOL_NAME} y el anclaje a fuentes oficiales, cerrando así el ciclo entre Holistic Testing (calidad distribuida en todo el ciclo) y control de gestión de pruebas (métricas, riesgo y mejora continua) frente al nuevo origen de deuda técnica que introduce la IA generativa.

Mi agradecimiento a José Alfonso por haber dado la oportunidad a partir de su artículo, a investigar un poco más acerca del tema y dar mi punto de vista como “tester”. Abzo 

---

Si te interesa este tema u otros relacionados con test management, project management e inteligencia artificial generativa aplicada a estas áreas, puedes seguirme por mis canales:

en YouTube: https://www.youtube.com/c/gustavoterrera

en LinkedIn: https://www.linkedin.com/in/gustavoterrera/

en Blog: https://testingbaires.com

en Instagram: https://www.instagram.com/gustavo.terrera/