Integrated Quality Lifecycle (IQL)

El IQL no reemplaza al STLC: lo absorbe. Es un operating model de Software Quality Engineering que integra las actividades del STLC dentro del SDLC y las extiende hasta producción.

Visión General

¿Tu enfoque actual de testing se siente fragmentado y reactivo?

IQL integra testing estratégico desde el inicio hasta la operación continua. Es una metodología completa y moderna que evoluciona del STLC tradicional hacia un enfoque integral e integrado de gestión de calidad durante todo el ciclo de vida del software.

Las Tres Fases del IQL

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   EARLY-GAME    │───▶│    MID-GAME     │───▶│   LATE-GAME     │
│    Testing      │    │     Testing     │    │    Testing      │
│                 │    │                 │    │                 │
│  "Construyámoslo│    │"¿El software    │    │"¿Cómo se        │
│  bien desde el  │    │cumple con los   │    │comporta en el   │
│  principio"     │    │requerimientos?" │    │mundo real?"     │
│                 │    │                 │    │                 │
│  ► Prevención   │    │  ► Detección    │    │  ► Observación  │
│  ► QA Analyst   │    │  ► QA Automation│    │  ► QA + DevOps  │
│  ► Steps 1-4    │    │  ► Steps 5-9    │    │  ► Steps 10-15  │
└─────────────────┘    └─────────────────┘    └─────────────────┘

Early-Game Testing (Fase 1)

Pregunta clave: "Construyámoslo bien desde el principio"
Enfoque: Prevención
Rol principal: QA Analyst
Steps: 1 Análisis de Requerimientos · 2 Desarrollo e Implementación (evento del SDLC, no es actividad de QA) · 3 Pruebas Exploratorias Tempranas · 4 Priorización Risk-Based

Mid-Game Testing (Fase 2)

Pregunta clave: "¿El software cumple con los requerimientos?"
Enfoque: Detección
Rol principal: QA Automation Engineer
Steps: 5 Documentación Asíncrona de Test Cases · 6 Evaluación de TCs para Automatización · 7 Automatización de los candidatos · 8 Verificación de la suite en CI · 9 Revisión del Pull Request

Late-Game Testing (Fase 3)

Pregunta clave: "¿Cómo se comporta en el mundo real?"
Enfoque: Observación
Roles: QA + DevOps
Steps: 10 Continuous Maintenance · 11 Canary Release Monitoring · 12 A/B Testing · 13 Real User Monitoring · 14 Chaos Engineering · 15 Feedback Loop

Evolución del STLC hacia IQL

"La calidad no es una fase separada, sino una parte integral del desarrollo desde el principio."

STLC Tradicional vs IQL

STLC LINEAL CLÁSICO
═══════════════════════════════════════════════════════════════
Requirements → Design → Code → [STLC] → Deploy

❌ Límites del STLC cuando se corre en línea recta:
  • El testing quedaba al final del ciclo
  • Feedback tardío y costoso
  • Silos entre desarrollo y testing
  • No consideraba producción


IQL MODERNO (Cíclico e Integrado)
═══════════════════════════════════════════════════════════════
            ┌─────────────────────────────┐
            │         IQL CORE            │
            │  ┌─────┐ ┌─────┐ ┌─────┐   │
            │  │Early│→│ Mid │→│Late │   │
            │  │Game │ │Game │ │Game │   │
            │  └─────┘ └─────┘ └─────┘   │
            └─────────────────────────────┘

✅ Ventajas del IQL:
  • Calidad integrada desde el inicio
  • Feedback continuo y temprano
  • Colaboración DevOps nativa
  • Monitoreo en producción

Comparación: STLC vs IQL

Aspecto	STLC lineal clásico	IQL
Detección de defectos	Al final del ciclo lineal	Durante todo el ciclo
Feedback loop	Retrasado	Continuo
Integración	Aislado (silos)	Dentro del SDLC, extendido hasta producción
Automatización	Se decide al final, si alcanza el tiempo	Se decide caso por caso, por ROI, en el step 4

"El IQL no reemplaza al STLC: lo absorbe. Es un operating model de Software Quality Engineering que integra las actividades del STLC dentro del SDLC y las extiende hasta producción." — Metodología IQL de UPEX

Las tres capas del IQL

El método se lee en tres capas, y conviene saber en cuál se está parado. El Core es lo que no cambia aunque cambie el stack, el tracker o el cliente: principios, los ocho stages con su contrato, los 15 steps que los desglosan, la escalera de artefactos y los niveles de madurez. El Implementation Standard es lo que UPEX prescribe o recomienda cuando implementa el IQL: KATA, Playwright, los guardrails de IA, las modalidades del TMS. Las Environment Integrations son lo que trae el cliente y con lo que el IQL se integra: tracker, repositorio, CI, chat, observabilidad. Los tres documentos se generan desde el syllabus, no se editan a mano y viven en docs/metodologia/ del repo:

iql-core.md
iql-implementation-standard.md
iql-environment-integrations.md

8 Enfoques Integrados del IQL

El Integrated Quality Lifecycle integra 8 enfoques complementarios que se aplican estratégicamente en diferentes fases, creando un sistema potenciado por inteligencia artificial.

Estos ocho enfoques no son los ocho stages. Que sean ocho de cada lado es coincidencia. Los enfoques son estrategias transversales —se aplican en varias fases a la vez, y una misma actividad puede usar tres—; los stages son la estructura del método, ocurren en un momento definido y cada uno declara su contrato. La tabla de stages está más abajo, en «El Flujo Completo».

1. Shift-Left Testing

Descripción: Mover actividades de calidad más temprano en el SDLC
Fase: Early Game Testing

2. Shift-Right Testing

Descripción: Extender validación de calidad hacia producción
Fase: Late Game Testing

3. Risk-Based Testing

Descripción: Priorizar pruebas basándose en impacto y probabilidad de fallo
Fases: Early Game Testing + Mid Game Testing

4. Continuous Testing

Descripción: Testing automatizado integrado en pipelines CI/CD
Fase: Mid Game Testing

5. Agile Testing

Descripción: Ciclos de testing rápidos y eficientes dentro de sprints
Fase: Mid Game Testing

6. Exploratory Testing

Descripción: Aprovechar inteligencia humana para encontrar issues inesperados
Fase: Early Game Testing

7. BDD (Behavior-Driven Development)

Descripción: Especificación colaborativa usando escenarios Given-When-Then
Fase: Early Game Testing

8. AI-Driven Testing

Descripción: Utilizar inteligencia artificial para mejorar eficiencia y cobertura de testing
Fases: Early Game Testing + Mid Game Testing + Late Game Testing

El Flujo Completo: los ocho stages del IQL

Desde el análisis de requerimientos hasta el monitoreo en producción: la metodología completa en una vista unificada.

La estructura del método son ocho stages con nombre. Cada uno declara su contrato: qué ejecuta el agente, qué decide y firma la persona, qué evidencia queda y con cuánta autonomía. Los 15 steps son el desglose de esos stages, no la estructura, y por eso conservan su número. Los stages nunca se numeran: «Stage 3» no existe.

Stage	Momento	Steps que lo desglosan
Shift-Left	pre-sprint	1
Planning	in-sprint	1
Execution	in-sprint	3
Reporting	in-sprint	3
Documentation	post-sprint	4, 5, 6
Automation	post-sprint	7, 8, 9
Regression	post-sprint	10
Observation	producción	11, 12, 13, 14, 15

El step 1 y el step 3 pertenecen cada uno a dos stages. No es un error de la tabla: el análisis de la historia ocurre antes del sprint (Shift-Left) y se materializa como ítems ya dentro del sprint (Planning); la corrida se ejecuta (Execution) y después se registra (Reporting). Son dos momentos con dos contratos distintos sobre el mismo step.

El método es agnóstico del ejecutor. Los mismos stages, los mismos artefactos y los mismos gates se cumplen con ejecución manual o con ejecución agéntica. Cambia el costo y el ritmo, no el método.

Modalidades de Aprendizaje en UPEX DOJO

Modalidad	Descripción	Enfoque
Clase Live	Sesión en vivo con instructor	Teoría + Práctica guiada
Checkpoint	Trabajo asíncrono grabado	Práctica independiente + Entregables

Los Checkpoints son donde se realiza el trabajo paralelo (Step 2) y la práctica individual de cada módulo.

Early-Game Testing (Steps 1-4: Prevención)

Step	Nombre	Etapa
1	Análisis de Requerimientos	TMLC 1st Stage
2	Desarrollo e Implementación	Parallel Work
3	Pruebas Exploratorias Tempranas	TMLC 2nd Stage
4	Priorización Risk-Based	TMLC 3rd Stage

El Step 2 no es una actividad de QA. Es el punto de sincronización con el SDLC: el período en que desarrollo construye mientras QA trabaja en paralelo. Se cuenta entre los 15 para que el ciclo sea legible, y por eso es el único step que no pertenece a ningún stage.

Mid-Game Testing (Steps 5-9: Detección)

Step	Nombre	Etapa
5	Documentación Asíncrona de Test Cases	TMLC 4th Stage
6	Evaluación de TCs para Automatización	TALC 1st Stage
7	Automatización de los candidatos	TALC 2nd Stage
8	Verificación de la suite en CI	TALC 3rd Stage
9	Revisión del Pull Request	TALC 4th Stage

"Asíncrona" no es un adorno. En la modalidad por defecto (jira-native) los casos se documentan después de ejecutarlos y reportarlos, no antes. Ver Las Dos Modalidades del TMS.

Los tres veredictos de ROI — Candidate, MANUAL y Deferred — se deciden en el Step 4, antes de que exista el TC. El Step 5 documenta en el TMS solo lo que salió Candidate o MANUAL, y el Step 6 revisa esos TCs ya documentados para confirmar cuáles se automatizan. KATA es Komponent Action Test Architecture.

Late-Game Testing (Steps 10-15: Observación)

Step	Nombre	Etapa
10	Continuous Maintenance	Production Ops
11	Canary Release Monitoring	Shift-Right
12	A/B Testing	Experimentation
13	Real User Monitoring	Observability
14	Chaos Engineering	Resilience
15	Feedback Loop	Continuous Learning

El Late Game se implementa por niveles de madurez. IQL define qué observar y qué mejorar; el nivel de madurez define hasta dónde implementar Late Game; los targets concretos los define cada producto. Los cuatro niveles son L1 Prevention (steps 1-2), L2 Early Detection (steps 3-4), L3 Continuous Detection (steps 5-10) y L4 Production Observation (steps 11-15). Los targets de las métricas del Late Game (MTTD, MTTR, error rate, SLO) son benchmarks de referencia, no objetivos universales: un banco y una app interna de RRHH no necesitan el mismo SLO.

Los Artefactos del IQL

El IQL no produce solo actividades: produce entregables con nombre propio. Cada uno vive en una altitud distinta del producto, y su nombre dice en el primer token de qué se trata.

La cadena completa

El eje PLAN → RESULTS tiene cuatro altitudes, y solo cuatro:

ALTITUD              PLAN                              RESULTS
═══════════════════════════════════════════════════════════════════════
Producto        MTP  Master Test Plan                  —
                       │
Feature         FTP  Feature Test Plan                 —
(épica)                │                    (el FTR se eliminó: duplicaba
                       │                     al STR — Feature no tiene runner)
Sprint          STP  Sprint Test Plan         ───▶  STR  Sprint Test Results
                       │
Historia        ATP  Acceptance Test Plan     ───▶  ATR  Acceptance Test Results
                       │
                       └─────────────────────▶  ATS  Acceptance Test Set
                                                (cobertura, no ejecución)

Las cuatro altitudes

Altitud	Plan	Results	Cardinalidad
Producto	MTP — Master Test Plan	—	Uno por producto
Feature / Épica	FTP — Feature Test Plan	— (el `FTR` se eliminó: duplicaba al STR)	Un FTP por feature; sus corridas se registran en el sprint
Sprint	STP — Sprint Test Plan	STR — Sprint Test Results	Uno por sprint — `STP: Sprint#{N}: {objetivo del sprint}`
Historia de usuario	ATP — Acceptance Test Plan	ATR — Acceptance Test Results	Un ATP por story; el ATR es el `Test Execution` — `ATR: {STORY-KEY}: Story Testing`, un run

La asimetría del sprint se lee al revés con facilidad. El STP dejó de decir "Regression": su título lleva el objetivo del sprint (STP: Sprint#30: Endurecer los pagos). El STR sí lo conserva (STR: Sprint#30: Regression Testing), porque ahí "Regression Testing" no es el alcance del plan sino el nombre de la actividad que se corrió.

A la altitud de la historia se le suma un tercer artefacto que no planifica ni ejecuta: el ATS — Acceptance Test Set, el Test Set que agrupa los casos de la historia (ATS: {STORY-KEY}: {story title}). Es obligatorio, uno por historia, aunque haya un solo caso, y se crea antes que el ATP y que el ATR, porque los dos derivan su lista de casos de la membresía del ATS.

El Axioma de Nomenclatura

Plan y results se distinguen en el primer token: P = Plan, R = Results.

La primera letra dice la altitud (Master, Feature, Sprint, Acceptance), la última dice qué clase de artefacto es: P = Plan, R = Results, S = Set. Por eso la pareja de la historia es ATP → ATR, y la del sprint STP → STR.

⚠️ La regla tiene una excepción, y es deliberada: la altitud Feature tiene plan (FTP) y no tiene resultados.

FTR no existe. Se eliminó porque duplicaba al STR: las corridas de una feature se registran en el sprint que las ejecutó. Si la frase habla de la corrida de un sprint, es el STR; si habla de la de una historia, el ATR.

FTX nunca existió. No hay "Feature Test Execution" en ninguna parte del estándar. La validación exploratoria temprana de una historia se cierra con el ATR, y la actividad se nombra "testing exploratorio", sin sigla propia.

El ATS y la cobertura

El ATS (Acceptance Test Set) existe por una razón muy concreta: su enlace a la historia es el único que llena el panel de cobertura. Los enlaces del ATP y del ATR a la historia son trazabilidad administrativa y aportan cobertura cero.

Esto está medido, no supuesto: una historia enlazada a un Test Plan de 16 casos y a un Test Execution de 16 casos se leía UNCOVERED · 0 tests; otra con un Test Set de 22 casos leía correctamente 22. La dirección del enlace también importa: la historia tiene que ser la parte inward (is tested by); un enlace invertido da cero cobertura en silencio.

De ahí la cascada de resolución de un caso hacia su historia, en este orden:

Escalón	Camino	Qué aporta
1	`TC → ATS → Historia`	Cobertura. Es el camino canónico y el que llena el panel
2	`TC → ATP → Historia`	Solo ubicación (placement): el panel no lo cuenta
3	`TC → Historia` directo	Último recurso válido, no un anti-patrón: también da cobertura
—	ninguno de los tres	El caso queda huérfano

Dos capas distintas. En la capa de Jira los enlaces son issue links (slug test). La membresía de un caso en un ATS, un ATP o un ATR es otra cosa: en modalidad jira-xray vive dentro de Xray (asociaciones por GraphQL) y nunca se expresa como issue link. En jira-native no hay capa Xray, así que ahí la membresía sí se escribe como enlaces TC → ATS.

TC y ATC: el caso genérico y el caso que nace de un criterio

El TC y el ATC cuelgan de la historia, pero no son una altitud más: ninguno de los dos planifica y ninguno de los dos registra una ejecución, así que no entran bajo las columnas PLAN y RESULTS sin romper el axioma de arriba. Van en su propio cuadro.

              (criterios de aceptación de la historia)
                              │
                              ▼
      TC  Test Case    ⊃     ATC  Acceptance Test Case
      (el contenedor          (lo que un TC ES cuando
       genérico)               nace de un criterio)

      todo ATC es un TC; no todo TC es un ATC

El ATC no es una entidad distinta del TC: es lo que un TC es cuando su origen es un criterio de aceptación de la historia. Por eso rima con ATP, ATR y ATS — son la familia de la historia. La A es de Acceptance, nunca de Automated.

	TC — Test Case	ATC — Acceptance Test Case
Qué es	El caso de prueba individual: un comportamiento afirmado	El mismo caso, cuando nace de un criterio de aceptación
Dónde vive	En el TMS (Jira nativo o Xray)	En el TMS, igual que cualquier TC
Relación	Contenedor genérico	Todo ATC es un TC; no todo TC nace de un criterio
Si se automatiza	—	El método KATA lo referencia con `@atc('PROJ-101')`

Dos confusiones que conviene desarmar:

El ATC no es "un TC implementado en código". El decorador @atc('PROJ-101') nombra la representación en código de ese mismo ATC, no otro objeto que viva aparte.
La A no es de Automated. Un ATC puede quedarse en regresión manual toda su vida y sigue siendo un ATC: lo que lo define es de dónde nació, no si tiene método.

KATA es Komponent Action Test Architecture (con K), la arquitectura donde viven las representaciones en código de los ATCs. Esas cuatro palabras son el nombre, no un inventario de capas. Las capas reales del framework van de abajo hacia arriba: TestContext (config, logger, faker, entorno), las bases ApiBase y UiBase, los componentes de dominio —UsersApi, LoginPage, donde vive el @atc— y los fixtures que inyectan todo al archivo de test. Una capa alta usa una baja, nunca al revés.

El FTP es un Documento Vivo

El FTP se crea una vez a nivel épica y se refina continuamente a lo largo de ella. No se escribe y se congela: el equipo aprende con cada historia entregada, y ese aprendizaje vuelve al plan de la feature.

De ahí sale la herencia épica → historia: cuando ya existe un FTP, el ATP de cada historia cita sus riesgos, puntos de integración y respuestas del PO en lugar de volver a derivarlos. Cite, do not re-derive.

Y de ahí sale también la disciplina de mirar alrededor: cuando un tester encara una historia, analiza además las historias hermanas de la misma épica — las ya desarrolladas, las que están en desarrollo y las que solo están definidas. Ese panorama completo de la feature es lo que hace que los ATPs salgan mejores.

Las Dos Modalidades del TMS

Cuándo un caso de prueba se convierte en un ítem del TMS depende de la modalidad del proyecto, y eso es lo que decide el momento en que se documenta.

	`jira-native` (la default)	`jira-xray`
Stage Planning	Solo outlines en el ATP: nombres más una línea de precondición y resultado esperado. Ningún ítem `Test`.	Los `Test` se crean y se ejecutan en Planning, con detalle ejecutable.
Por qué	Un `Test` nativo ya es documentación, así que espera al gate de regression-worthy de Documentation, que corre después de ejecutar y reportar.	En Xray el `Test` es la unidad de ejecución: sin él no corre nada.
Stage Documentation	Crea los `Test` solo para lo que pasó el ROI.	Promueve al set de regresión los que pasaron el ROI.

Invariante: el set de regresión persistente se decide por ROI en Documentation, nunca se asume en Planning.

Los stages que se nombran acá son stages del método, no steps del IQL. Planning cubre el step 1 ya dentro del sprint; Documentation cubre los steps 4, 5 y 6 —Analizar → Priorizar → Documentar—, así que la priorización por ROI es el step 4 y la documentación en el TMS el step 5. Desde que los stages se nombran en vez de numerarse, la colisión que obligaba a esta aclaración dejó de existir.

Esto es lo que le da sentido a la palabra Asíncrona del Step 5: en la modalidad por defecto, documentar ocurre después de ejecutar, no antes.

Los Tres Veredictos de ROI

El Step 4 (Priorización Risk-Based) cierra cada escenario del ATP con uno de tres veredictos, nunca con dos:

Veredicto	Qué significa	Destino
Candidate	Vale la pena automatizarlo	Se documenta como TC en el Step 5 y entra al TALC
MANUAL	Vale la pena repetirlo, pero a mano	Se documenta como TC en el Step 5; queda en la regresión manual
Deferred	No entra en el set de regresión	Se registra en el reporte de priorización; no se crea TC en el TMS

La mayoría de los escenarios derivados termina en Deferred, y eso es lo esperado: un caso se documenta porque se va a volver a ejecutar, nunca para llegar a un número de cobertura.

Por qué el veredicto va antes que el TC. Deferred significa no se crea el TC, así que la decisión tiene que correr antes de documentar. Esa es la Priorización del Step 4; el Step 5 solo persiste lo que sobrevivió. El Step 6 es otra decisión, más chica: sobre los TCs ya documentados, cuáles son factibles de automatizar con KATA. Ahí el veredicto no se inventa, se estampa como estado del ticket — READY → In Review → Candidate, o READY → MANUAL.

⚠️ Veredicto y estado no son lo mismo aunque compartan nombre. Candidate y MANUAL son a la vez veredictos de ROI y estados del Test Case; Deferred es a la vez veredicto de ROI y estado terminal del Bug.

El Modelo de Colaboración: Analyst + Automation Engineer

IQL define una simbiosis perfecta entre dos roles especializados que trabajan de forma asíncrona y paralela.

QA Analyst - The "What" and "Why"

Responsabilidades Clave:

Análisis de requerimientos y evaluación de riesgos
Análisis AI-asistido de requerimientos y AC
Escritura de criterios de aceptación (BDD)
Creación de planes de testing estratégicos
Identificación de candidatos para automatización
Generación de casos con AI y testing exploratorio

"El Analyst actúa como 'navegador', usando su comprensión del producto y el usuario para dibujar el mapa (plan de testing) y destacar los destinos más importantes (candidatos para automatización)."

QA Automation Engineer - The "How" and "Where"

Responsabilidades Clave:

Diseño y construcción de frameworks de automatización
Implementación de self-healing tests con AI
Escritura de scripts robustos y mantenibles
Integración de tests en pipelines CI/CD
Análisis predictivo y mantenimiento de suites

"El Engineer actúa como 'conductor', usando su experiencia técnica para construir un vehículo rápido y confiable (framework de automatización) y navegar hábilmente a los destinos definidos por el analista."

Workflow Asíncrono de Colaboración

┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│  Fase 1: Analyst Define el 'QUÉ'                               │
│  ────────────────────────────────                               │
│  Crea criterios de aceptación específicos para el equipo       │
│  de desarrollo                                                  │
│                          │                                      │
│                          ▼                                      │
│  Fase 2: Analyst Prioriza el 'POR QUÉ'                         │
│  ──────────────────────────────────────                         │
│  Identifica candidatos prioritarios para automatización         │
│  y los documenta                                                │
│                          │                                      │
│                          ▼                                      │
│  Fase 3: Engineer Construye el 'CÓMO'                          │
│  ─────────────────────────────────────                          │
│  Implementa la automatización basada en la priorización        │
│  del analyst                                                    │
│                                                                 │
│  ═══════════════════════════════════════════════════════════   │
│  Resultado: Ciclo Virtuoso de Calidad                          │
│  Este workflow crea una "relación simbiótica" donde ambos      │
│  roles se especializan y escalan eficientemente.               │
└─────────────────────────────────────────────────────────────────┘

Workflow Operativo IQL en Jira

Visualiza cómo se implementa la metodología IQL en la práctica con la integración de múltiples ciclos de trabajo que operan de forma coordinada en Jira.

Los Dos Ciclos Principales

Ciclo	Nombre	Descripción
SDC	Story Development Cycle	Gestión de Historias de Usuario
BLC	Bug Life Cycle	Gestión de Defectos

SDC y BLC son los nombres pedagógicos con los que se estudian acá. En el Jira de UPEX los workflows reales se llaman UPEX Feature (US) Workflow y UPEX BUG/DEFECT LIFE CYCLE: mismo viaje, mismos estados, lo único que cambia es el nombre del ticket.

Story Development Cycle (SDC)

Define cómo las User Stories fluyen desde la concepción hasta la implementación, integrando QA desde el diseño inicial.

Fases del SDC:

Creación: BDD y criterios de aceptación
Refinamiento: Análisis de riesgos y complejidad
Desarrollo: Implementación por Devs
Validación: Testing y aprobación QA

Bug Life Cycle (BLC)

Define cómo los defectos viajan desde el reporte hasta el cierre verificado. El QA es quien abre el ticket y el único que lo cierra, después de retestear el fix con evidencia.

Fases del BLC:

Reporte: El defecto nace en Open, con evidencia, pasos de reproducción y clasificación
Triage: Desde Open el bug puede aplazarse (Deferred) o cerrarse sin arreglo (no reproducible, duplicado, funciona según lo diseñado, es una mejora)
Arreglo: In Progress → In Review → Ready For QA, en manos de Devs
Cierre: El QA retestea; si pasa, Closed; si falla, el mismo ticket vuelve al ciclo de arreglo

Del testing manual a la automatización

Los dos ciclos de arriba mueven tickets. El trabajo de testing en sí atraviesa otra cadena: el TMLC (Test Manual Life Cycle) analiza, explora, prioriza por riesgo y documenta los casos; el TALC (Test Automation Life Cycle) toma de ahí los candidatos que valen la pena y los convierte en pruebas automatizadas. Primero se prioriza y se documenta con criterio, después se automatiza: sin esa cadena, la automatización corre a ciegas.

Diagramas de flujo

Los siete diagramas viven en el repositorio, como SVG dentro de componentes React, y se generan desde las fuentes de verdad: los pasos salen del syllabus, los artefactos de lib/qa-standard/artifacts.ts, y los estados de Jira de .agents/jira-workflows.json del boilerplate.

Diagrama	Ruta
El IQL completo	`/metodologia/diagramas/iql-completo`
Sprint Testing, los pasos del QA Analyst	`/metodologia/diagramas/sprint-testing`
Gestión de tests, la cascada de cobertura	`/metodologia/diagramas/gestion-de-tests`
Automatización, los pasos del QA Automation	`/metodologia/diagramas/automatizacion-de-tests`
Workflow de Jira: User Story	`/metodologia/diagramas/jira-user-story`
Workflow de Jira: Bug	`/metodologia/diagramas/jira-bug`
Workflow de Jira: Test	`/metodologia/diagramas/jira-test`

El código está en app/metodologia/_components/diagrams/, con el registro único en registry.ts. Antes de esto había un solo PNG de 1.4 MB en Supabase Storage, subido en septiembre de 2025: envejeció casi un año sin que nadie lo notara, porque un binario no se diffea en un pull request. Ese es el motivo del cambio de formato, no una preferencia estética.

Integración con el Modelo ATLAS

El Integrated Quality Lifecycle se implementa a través del Modelo ATLAS, nuestro framework pedagógico único.

Cómo se Conectan

┌──────────────────────────────────────────────────────────────┐
│                                                              │
│  1  IQL define QUÉ hacer                                    │
│  ─────────────────────────                                   │
│  Las fases, actividades y objetivos estratégicos de         │
│  gestión de calidad                                          │
│                          │                                   │
│                          ▼                                   │
│  2  ATLAS define CÓMO aprenderlo                            │
│  ─────────────────────────────────                           │
│  La estructura pedagógica, herramientas y progresión        │
│  de competencias                                             │
│                          │                                   │
│                          ▼                                   │
│  3  Resultado: QA Completo                                  │
│  ────────────────────────────                                │
│  Profesional con metodología integral y competencias        │
│  técnicas sólidas                                            │
│                                                              │
└──────────────────────────────────────────────────────────────┘

IQL vs ATLAS

Aspecto	IQL (Metodología Real)	ATLAS (Estrategia de Aprendizaje)
Propósito	El proceso profesional que usarás en tu trabajo	Simulas TODOS los roles con IA para practicar IQL sin depender de nadie
Requisito	Requiere equipo (BA/PO, Devs, QAs)	Aprendizaje autónomo con IA

La Analogía de la "Fábrica de Juguetes Increíbles"

Para explicar IQL de manera simple, imaginemos que estamos construyendo la nave espacial LEGO más increíble para nuestros amigos.

Paso 1: Ana Escribe las "Reglas de Diversión"

Antes de tocar cualquier pieza LEGO, Ana toma una libreta y piensa qué hará que la nave espacial sea súper divertida para nuestros amigos.

Regla #1: La nave debe tener dos alas que no se caigan
Regla #2: La puertita del piloto debe abrir y cerrar fácilmente
Regla #3: Debe tener un botón rojo grande que haga '¡Bip-Boop!'

Paso 2: Leo Construye sus "Robots Verificadores"

Mientras otros construyen la nave usando las reglas de Ana, Leo construye pequeños robots LEGO para verificar cada regla automáticamente.

Robot 1: Verifica automáticamente que la nave tenga exactamente dos alas
Robot 2: Abre y cierra la puertita una y otra vez para asegurar que no se rompa
Robot 3: Presiona el botón rojo para verificar que siempre haga '¡Bip-Boop!'

Paso 3: La Gran Verificación

Una vez terminada la nave, no tenemos que verificar todo manualmente. ¡Los Robots Verificadores de Leo hacen su trabajo!

¡Zas! ¡Pop! ¡Bip-Boop! En un minuto verifican todo de la lista
Si encuentran un problema, sabemos exactamente qué arreglar
Ana observa a nuestros amigos jugar y usa sus ideas para escribir reglas aún mejores

¿Qué es el "Plan de la Fábrica de Juguetes Increíbles"?

En lugar de construir toda la nave espacial y solo verificarla al final, nuestro plan es mucho más inteligente:

Primero decidimos qué la hace divertida (reglas de Ana), luego construimos robots especiales para verificar nuestro trabajo durante el proceso (robots de Leo), y finalmente observamos a la gente jugar para aprender cómo hacerla aún mejor la próxima vez.

Así encontramos problemas temprano, ahorramos mucho tiempo, y siempre construimos los juguetes más divertidos para todos.

Diferencia Clave: Ciclo vs Fase

❌ STLC lineal clásico

Testing como fase separada, que en el modelo lineal quedaba al final del desarrollo.

Lineal y secuencial
Reactivo (después de desarrollar)
Silos entre equipos
No consideraba producción

✅ IQL Moderno

Calidad como ciclo continuo integrado en todo el SDLC. No reemplaza al STLC: absorbe sus actividades y las extiende hasta producción.

Circular y continuo
Proactivo (desde el diseño)
Colaboración DevOps
Incluye monitoreo en producción

Herramientas por Fase

Early-Game Testing

Tracker (Jira o equivalente) y wiki del cliente
Harness agéntico (Claude Code, OpenCode, Codex) con MCPs de lectura
Cliente de API (Postman, Bruno, curl)

Mid-Game Testing

Playwright + KATA
Xray (o Jira nativo, según la modalidad del TMS)
Repositorio, CI y Docker del cliente

Late-Game Testing

Observabilidad del cliente (Sentry, Grafana, Datadog) y monitor de uptime
Despliegue progresivo y feature flags
k6 solo cuando performance entra por riesgo

Estado Actual de Disponibilidad

✅ Early-Game Testing: Completamente disponible
✅ Mid-Game Testing: Completamente disponible
🔄 Late-Game Testing: Declarado, todavía sin skill

Navegación

Early-Game Testing - Fase 1: Prevención y estrategia temprana
Mid-Game Testing - Fase 2: Detección e implementación
Late-Game Testing - Fase 3: Observación y producción
IQL Core - Principios, steps, artefactos y niveles de madurez
IQL Implementation Standard - Lo que UPEX prescribe o recomienda al implementar
IQL Environment Integrations - Lo que trae el cliente y cómo se integra

Qué es IQL