IQL: Integrated Quality Lifecycle

El IQL de un vistazo

El método se describe con cuatro números. Cada uno responde a una pregunta distinta, y conviene no mezclarlos:

El lugar de la IA en el método cabe en una frase que el sitio deja en inglés: Agent executes. Evidence proves. Human owns the decision. El agente ejecuta las skills, la evidencia respalda cada conclusión y la persona decide qué se prioriza, qué se automatiza y qué se aprueba.

Las tres fases

Cada fase tiene un rango de steps, un rol protagonista y una pregunta de fondo. El detalle de cada una está en su propia página.

Los cuatro bloques de madurez

El método también se lee en cuatro bloques. Cada uno ataca un problema concreto y deja un resultado. Son los mismos cuatro niveles de madurez (L1 a L4) con los que un equipo decide hasta dónde implementar.

El bucle completo

El ciclo vuelve sobre sí mismo. Los stages se agrupan en cuatro momentos (antes del sprint, dentro del sprint, cierre y release, producción) y alrededor están los eventos del SDLC que producen artefactos sin ser stages. El diagrama dibuja tres flechas de vuelta que un modelo lineal no tiene: el defecto que reabre la ejecución (defecto, fix, retest), el NO-GO de la regresión que devuelve el release a la automatización, y las señales de producción que alimentan el Shift-Left siguiente.

La vuelta de producción al análisis tiene un mecanismo con nombre: el error budget, la escape rate y la change failure rate. Si ningún número vuelve al step 1, el último step es un final y el bucle se corta.

Principios e invariantes

Lo que no cambia aunque cambien el stack, el tracker o el cliente. El sitio les da un identificador corto a cada uno; aquí van con su idea central.

Las tres costuras de la I

1. Humano ↔ agente ↔ evidencia

   Cada stage las cose con su contrato: qué hace el agente, qué firma la persona y qué evidencia exige el gate. Esta costura es la que hace agéntico al método.

2. TMLC ↔ TALC

   Los candidatos del QA Analyst alimentan al QA Automation Engineer, y el gate de ROI decide cuáles pasan. Es la costura original del método.

3. STLC dentro del SDLC

   Las actividades del STLC se reparten por el SDLC y llegan hasta producción. El step 2 es el punto donde las dos líneas se sincronizan.

Modo light y lo que nunca se colapsa

Algunos gates se pueden colapsar en un sprint concreto. Lo decide el QA Lead, por escrito en el STP, y la decisión no se hereda al sprint siguiente. Cada gate colapsado deja un ítem de deuda en el backlog con su condición y su fecha; sin esa nota, el gate se perdió.

Los stages y su contrato agéntico

El stage es lo que se ejecuta y lo que se gatea. Cada uno declara qué hace el agente, qué firma la persona, qué evidencia exige y con cuánta autonomía corre, en una escala de 0 a 5. La escalera completa está en .agents/skills/agentic-qa-core/references/stage-gates.md; los stages que corre cada proyecto, en qa.methodology.stages de .agents/project.yaml.

El contrato de cada stage

La evidencia que exige cada gate, las transiciones de Jira y el detalle de cada stage están en las páginas de fase (Early-Game, Mid-Game, Late-Game) y en Observation. En el repo, el contrato vive en .agents/skills/agentic-qa-core/references/stage-gates.md, y esa es la fuente cuando los niveles de autonomía de esta tabla difieran.

Eventos del SDLC que no son stages

Cuatro momentos producen artefactos sin ser un stage del método:

Si el tracker del cliente no tiene el work type de plan, el evento del STP se saltea con una nota declarada, nunca en silencio. El STR tampoco suma los ATR: los ATR se leen junto a él.

Los 15 steps

Los steps son el desglose de los stages. Dos detalles para leer la tabla: el step 1 y el 3 se reparten entre dos stages cada uno, y el step 2 es el único que no pertenece a ningún stage porque es trabajo de desarrollo.

El sitio marca los steps 11 a 15 como «Panorama»: están declarados, pero el boilerplate no cubre Shift-Right y ninguna skill los ejecuta.

Los ciclos internos

Dentro del IQL corren cinco ciclos. Dos son nombres pedagógicos de UPEX para agrupar steps; en este repo el trabajo se organiza por stages. Los otros tres son máquinas de estado del tracker, o lo serán.

Mapa de los nombres pedagógicos a los stages: TMLC 1st es Shift-Left y Planning; TMLC 2nd es Execution y Reporting; TMLC 3rd y 4th son Documentation; TALC 1st es la frontera entre Documentation y Automation; TALC 2nd a 4th son Automation. Los estados del SDC y del BLC salen de .agents/jira-workflows.json.

Dos modalidades: jira-native y jira-xray

La modalidad decide cuándo un Test Case se vuelve work item del TMS. Cambia con la herramienta; el método es el mismo. La modalidad se resuelve por sondeo: si no hay Xray configurado (tms_cli: null), el repo cae en jira-native. La instancia de UPEX trabaja en jira-xray.

La escalera de artefactos

La planificación sube por cuatro altitudes: producto, feature, sprint e historia. El primer token del nombre dice la altitud y si el artefacto es plan o resultado: en la sigla, la P marca un plan (Plan) y la R, una corrida (Results).

{ACRONYM}: {scope-id}: {descriptor}

ATP: PROJ-123: Apply discount at checkout
STR: Sprint#30: Regression Testing

La A de ATC es de Acceptance, nunca de Automated. Cuando el caso se automatiza, el decorador @atc('PROJ-101') nombra su representación en código: es el mismo ATC. RTP y RTR vienen de la convención de este repo (.agents/skills/agentic-qa-core/references/planning-ladder.md); el sitio oficial nombra la escalera de MTP a ATR.

La cascada de cobertura

El ATS se crea antes que el ATP y el ATR porque los dos derivan de él su lista de casos. Su enlace a la historia es el único que llena el panel de cobertura: una historia enlazada solo a su plan y a su ejecución se lee UNCOVERED, con cero casos.

El modelo Analyst + Automation Engineer

El IQL reparte el trabajo entre dos roles que avanzan en paralelo y de forma asíncrona. El sitio lo explica con una nave de LEGO:

QA Analyst (Ana)

Antes de tocar una pieza, escribe las reglas que hacen buena a la nave: dos alas que no se caen, una puerta que abre y cierra, un botón rojo que hace «Bip-Boop!». Es el Early-Game: análisis, exploración y la decisión de qué merece quedarse.

QA Automation Engineer (Leo)

Mientras otros construyen, arma robots que verifican cada regla solos. Cuando la nave está lista, los robots la revisan en un minuto y dicen qué arreglar. Es el Mid-Game: automatización, CI y pull request.

Después, Ana mira cómo juegan los amigos y usa lo que ve para escribir mejores reglas. Esa vuelta es el Late-Game alimentando el siguiente ciclo. El punto de entrega entre los dos roles es la salida del step 5 hacia el step 6.

STLC contra IQL

El STLC clásico trata el testing como una etapa con principio y fin, y arranca cuando el código ya existe. El IQL conserva esas actividades y las reparte por todo el SDLC, desde el requerimiento hasta producción.

Los enfoques que integra

El sitio lista ocho enfoques de testing que el IQL integra. Ninguno es invento de UPEX: lo que el IQL agrega es el orden (en qué fase se aplica cada uno, con qué entregable y quién lo ejecuta). El único que corre en las tres fases es AI-Driven Testing: agentes que analizan, generan y mantienen el trabajo de calidad. Ejecutar, observar y juzgar si algo es un defecto sigue siendo tarea del QA, que firma la clasificación final. La lista completa de los ocho está en la página oficial.

La Trifuerza

La Trifuerza es el modelo de exploración del stage Execution: las tres capas que recorres para validar una feature. También es el conocimiento mínimo que UPEX le pide a un QA.

El orden importa: primero el smoke valida el entorno, después la Trifuerza valida la feature. Saltarse el smoke es el anti-patrón clásico.