Bloque 01
Prevention
- Problema
- Los defectos más caros nacen en historias ambiguas, antes de que exista una línea de código.
- Resultado
- Historias con criterios verificables y un plan de aceptación por historia antes de que arranque el sprint.
Metodología Integral
Integrated Quality Lifecycle
La metodología de calidad de UPEX: una sola línea de trabajo desde el requerimiento hasta la operación, en lugar del STLC como fase separada al final.
- steps
- 15steps
- fases
- 3fases
- ciclos
- 2ciclos
- altitudes de artefactos
- 4altitudes de artefactos
~$
Para leer sentado, imprimir o consultar sin conexión
// En el ecosistema
IQL es la metodología de todo el ecosistema
Galaxy lo enseña, la división de servicios lo implementa y Satellite conecta a las personas formadas en él.
- 01 · PreventionPasos 1-2
Historias con criterios verificables y un plan de aceptación por historia antes de que arranque el sprint.
- 02 · Early DetectionPasos 3-4
Feedback al desarrollador antes del pull request, con evidencia real y bugs priorizados por riesgo.
- 03 · Continuous DetectionPasos 5-10
Regresión confiable en CI: solo se documenta y automatiza lo que demostró valor, y corre en cada pull request.
- 04 · Production ObservationPasos 11-15
Producción alimenta la estrategia: métricas reales deciden qué observar, qué probar y qué mejorar en el siguiente ciclo.
¿Qué quieres hacer con el IQL?
- UPEX GalaxyAprenderlo
- UPEX WorkbenchImplementarlo
- UPEX SatelliteContratar gente formada en él
Vista ejecutiva
El IQL en cuatro bloques
Cuatro bloques, cada uno con el problema que ataca y el resultado que deja. Son los mismos cuatro niveles de madurez con los que después se decide hasta dónde llegar.
Bloque 02
Early Detection
- Problema
- Un bug encontrado después del merge cuesta el retrabajo de todo el equipo.
- Resultado
- Feedback al desarrollador antes del pull request, con evidencia real y bugs priorizados por riesgo.
Bloque 03
Continuous Detection
- Problema
- Repositorios de casos que nadie mantiene y suites automatizadas en las que nadie confía.
- Resultado
- Regresión confiable en CI: solo se documenta y automatiza lo que demostró valor, y corre en cada pull request.
Bloque 04
Production Observation
- Problema
- Lo que pasa en producción no vuelve al backlog.
- Resultado
- Producción alimenta la estrategia: métricas reales deciden qué observar, qué probar y qué mejorar en el siguiente ciclo.
Hasta dónde llegar
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.
El mapa
El IQL completo, de un vistazo
Quince pasos en tres fases, con los dos ciclos de vida marcados sobre los pasos que abarcan. Todo lo que sigue en esta página es un acercamiento a una parte de este dibujo.
Integrated Quality Lifecycle
El IQL completo, sus quince steps
Las tres fases del IQL con sus quince pasos, el rol que conduce cada una y dónde caen las etapas del TMLC y del TALC.
Steps 1-4
Early-Game
Prevención · QA Analyst
Steps 5-9
Mid-Game
Detección · QA Automation Engineer
Steps 10-15
Late-Game
Observación · QA + DevOps
Qué le pasa al STLC dentro del IQL
El STLC lineal clásico trata al testing como una etapa con principio y fin: se planifica, se diseñan los casos, se ejecutan y se cierra el ciclo. El IQL no borra esas actividades, las absorbe: las reparte a lo largo del ciclo de desarrollo y las extiende hasta producción.
STLC clásico · IQL
La inversión: ejecutar primero, documentar después
Tres carriles sobre el mismo eje temporal del SDLC. El STLC clásico arranca cuando el código ya existe; el IQL empieza en el requerimiento y cruza el orden de los dos pasos que definen el método.
Las seis diferencias, mapeadas al dibujo
El caso de prueba se documenta después de ejecutar
En el STLC lineal clásico el orden es Test Case Development (03) y después Test Execution (05). En el IQL la ejecución exploratoria es el step 03 y la documentación asíncrona de los casos es el step 05: se escribe sabiendo ya cuáles valen la pena. Es el cambio de mayor peso y por eso es el centro visual.
Las dos flechas que se cruzan entre el carril del STLC y el carril del IQL. La cian va de derecha a izquierda; la violeta baja recta y salta por encima.
El shift-left deja de ser opcional
El plan de pruebas se crea mucho antes: participa en las etapas de requerimientos y diseño del SDLC, no espera a que exista código.
La flecha cian que baja desde Requerimientos hasta el step 01, Análisis de Requerimientos.
Durante la codificación, QA acompaña al equipo de desarrollo
Se puede probar incluso en localhost. No es obligatorio: el camino normal sigue siendo esperar el despliegue y hacer el sprint testing entonces, pero las ejecuciones tempranas pueden empezar ahí.
La flecha punteada que baja desde Codificación hasta el step 02, Desarrollo e Implementación. El trazo discontinuo marca «opcional» en la leyenda.
La ejecución del plan es exploratoria, no literal
El plan da instrucciones para autodescubrir problemas, no un guion rígido paso a paso. Esa libertad la vuelve más exhaustiva: se ejecuta lo que el plan indica más todo lo exploratorio que aparezca en el camino.
La nota «plan + lo que aparezca» colgada del step 03, Pruebas Exploratorias Tempranas.
Recién con esa información se deciden los candidatos de regresión
En el STLC lineal clásico la regresión parece no estar contemplada. Acá sí lo está, y la automatización también: el step 06 evalúa qué casos merecen convertirse en automáticos, con la ejecución ya hecha como insumo.
El step 06, Evaluación de TCs para Automatización, primer paso de la capa TALC.
La I de Integrated es la costura entre el analista y la automatización
El TMLC (capa de análisis, del step 1 al 5, salteando el 2, que es trabajo del equipo de desarrollo) y el TALC (capa de automatización, steps 6-9) no son dos ciclos paralelos: están integrados, y el punto de entrega es la salida del step 05 hacia el step 06.
La articulación «I · INTEGRATED» en el pliegue: el flujo del TMLC entra por arriba y sale hacia el bloque del TALC.
«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
Los 8 enfoques que el IQL integra
Ninguno es invento de UPEX. Lo que el IQL aporta es el orden: cuál se aplica en qué fase, con qué entregable y quién lo ejecuta.
Shift-Left Testing
Mover actividades de calidad más temprano en el ciclo de desarrollo
Involucrar a QA desde el inicio para descubrir defectos más pronto y reducir retrabajo, antes de que exista código que romper. En el IQL no queda en intención: la historia lleva la subtarea «[QA] Shift-Left Review», que se abre al empezar el refinamiento y se cierra al entregarlo, y QA redacta el Acceptance Test Plan de la historia.
- Early-GamePrevención · Steps 1-4 · QA Analyst
Navegar el IQL completo
Las tres fases del Integrated Quality Lifecycle, con sus steps, su rol protagonista y su pregunta de fondo.
Early-Game
Fase 1 · Prevención · Steps 1-4
«Construyámoslo bien desde el principio»
QA Analyst
Ir a Early-GameMid-Game
Fase 2 · Detección · Steps 5-9
«¿El software cumple con los requerimientos?»
QA Automation Engineer
Ir a Mid-GameLate-Game
Fase 3 · Observación · Steps 10-15
«¿Cómo se comporta en el mundo real?»
QA + DevOps
Ir a Late-GameEarly-Game
Mid-Game
Late-Game
Los 15 steps del IQL
Del análisis del requerimiento al monitoreo en producción. Cada step tiene una etapa de ciclo de vida, un entregable y una transición en Jira: no son temas, son trabajo con resultado verificable. Cada fase se despliega por separado.
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
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 con Playwright + Patrón de Diseño KATA
TALC 2nd Stage
8. Verificación de ATCs en CI
TALC 3rd Stage
9. Pull Request Review
TALC 4th Stage
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
Step 1: Análisis de Requerimientos
Early-GameTMLC 1st StageEntender los requerimientos: el análisis del Epic y el de cada Story ocurren ANTES del sprint, y de ahí sale el ATP de la historia, que pre-sprint vive SOLO en el campo `acceptance_test_plan` (todavía sin ítem Test Plan). El ítem FTP no nace acá: se crea o se refina dentro de /sprint-testing, al cargar el contexto del Epic, ya en sprint. El FTP es un documento vivo: se escribe una vez por épica y se refina a lo largo de ella, porque el equipo aprende con cada historia que entrega. Y la historia no se analiza sola: se analizan también sus hermanas de la misma épica —las ya desarrolladas, las que están en desarrollo y las que solo están definidas— porque ese panorama completo de la feature es lo que hace que los ATPs salgan mejores.
Entregable
ATP (Acceptance Test Plan) por Story, pre-sprint en el campo de la historia + FTP (Feature Test Plan) por Epic, cuyo ítem se crea al abrir el sprint
- Herramientas
- Harness agéntico (Claude Code, OpenCode, Codex)Jira (o tracker equivalente)Confluence (o wiki del equipo)
- Boilerplate
- Stage 0 · Shift-Left QA + Stage 1 · Planning/shift-left-testing + /sprint-testing
Step 2: Desarrollo e Implementación
Early-GameParallel WorkEvento del SDLCConstruir y desplegar la US en un entorno de staging mientras QA prepara la estrategia
Entregable
Entorno funcional para testing
- Herramientas
- GitHub / GitLab (repositorio y pull requests)
- Boilerplate
- sin stage: es trabajo del equipo de desarrollo
Step 3: Pruebas Exploratorias Tempranas
Early-GameTMLC 2nd StageValidar la US en dos movimientos y en este orden: primero el smoke test de Go/No-Go, que valida el ENTORNO, y recién después la exploración por Trifuerza (UI · API · DB), que valida la FEATURE ejecutando lo planificado en el ATP y en el FTP. Saltarse el smoke es el anti-patrón clásico. Los hallazgos se reportan en el momento: el reporte de defectos no es un step aparte, vive dentro de la exploración. Antes de filear hay que CLASIFICAR el hallazgo — Bug, Defect o Improvement — y la clasificación sigue la etapa de vida de la FEATURE, no el entorno donde apareció. Cada hallazgo se documenta con información clara y reproducible.
Entregable
US aprobada o bugs reportados en Jira, con el ATR (Acceptance Test Results) de la historia como registro de la ejecución. La altitud Feature no tiene ejecución propia: el FTP se consume como contexto y no genera resultados.
- Skills
- Clasificación Bug / Defect / ImprovementBug report writingSeverity/Priority classificationEvidence collection
- Herramientas
- Harness agéntico (Claude Code, OpenCode, Codex)MCPs (OpenAPI, base de datos, tracker, navegador)Cliente de API (Postman, Bruno, curl)Jira (o tracker equivalente)
- Boilerplate
- Stage 2 · Execution + Stage 3 · Reporting/sprint-testing
Step 4: Priorización Risk-Based
Early-GameTMLC 3rd StageDecidir qué escenarios del ATP merecen un Test Case (TC) persistente en el TMS y cuáles se quedan como exploratorios. La decisión corre DESPUÉS de ejecutar y reportar: el set de regresión persistente se decide por ROI, nunca se asume al planificar.
Entregable
ATP refinado, con un veredicto de ROI por escenario
- Criterios
- Impacto potencialProbabilidad de defectosValor-Costo-Riesgo
- Herramientas
- Jira (o tracker equivalente)
- Boilerplate
- Stage 4 · Documentation, fase Prioritize (ROI)/test-documentation
La escalera de artefactos
La escalera de planificación de UPEX: producto → feature → sprint → historia. El primer token del nombre codifica la altitud.
El axioma
Plan y results se distinguen en el primer token: P = Plan, R = Results
P = PlanMTP · FTP · STP · ATPR = ResultsSTR · ATR
La gramática del nombre
{ACRONYM}: {scope-id}: {descriptor}
Un nombre que respeta la gramática se lee sin abrir el issue: la sigla dice la altitud y si es plan o corrida, el scope dice a qué se refiere y el descriptor, de qué se trata.
MTPPlan
Master Test Plan
Epic 'QA Master Test Plan'
1 por producto
Resultados sin agregación
Esta altitud planifica y no abre una corrida propia, y nada suma sus resultados: se leen en el STR de cada sprint, uno por uno, y en los ATR de las historias que ese sprint ejecutó.
Cobertura acumulada
El ATS se declara en la historia, uno por historia y obligatorio. La cobertura de esta altitud es la suma de los ATS de las historias que tiene debajo: se acumula desde abajo, no se declara aquí.
Test Management
La cascada de cobertura de un Test Case
Los tres caminos por los que un caso de prueba resuelve hasta su historia, cuál de ellos llena el panel de cobertura y cuál se lee como sin cobertura aunque el enlace exista.
Los dos ciclos que corren adentro
Las fases dicen cuándo. Los ciclos dicen cómo: cuatro etapas para el trabajo manual y cuatro para el automatizado, corriendo en paralelo sobre los mismos steps.
TMLC
Test Manual Life Cycle · QA Analyst
El ciclo del análisis y la exploración. Termina documentando, no empieza documentando: se escribe el caso cuando ya se sabe que vale la pena conservarlo.
- 1st StageAnálisisstep 1 · Análisis de Requerimientos
- 2nd StageExploraciónstep 3 · Pruebas Exploratorias Tempranas
- 3rd StagePriorizaciónstep 4 · Priorización Risk-Based
- 4th StageDocumentaciónstep 5 · Documentación Asíncrona de Test Cases
TALC
Test Automation Life Cycle · QA Automation Engineer
El ciclo del código de prueba. Arranca evaluando qué merece automatizarse y cierra en el review del pull request, igual que cualquier otro cambio del repositorio.
- 1st StageEvaluaciónstep 6 · Evaluación de TCs para Automatización
- 2nd StageAutomatizaciónstep 7 · Automatización con Playwright + Patrón de Diseño KATA
- 3rd StageVerificación CIstep 8 · Verificación de ATCs en CI
- 4th StagePR Reviewstep 9 · Pull Request Review
Sprint Testing
Los pasos del QA Analyst en el sprint
Las tres stages de /sprint-testing y el orden exacto de la planificación, donde el ATS se crea antes que el plan y que la corrida.
Test Automation
Los pasos del QA Automation y las capas de KATA
Los cuatro steps del IQL que conduce el QA Automation Engineer y las capas de la arquitectura KATA donde se implementan, con la capa intermedia opcional en su lugar.
El modelo de colaboración: Analyst + Automation Engineer
El IQL define una simbiosis entre dos roles especializados que trabajan de forma asíncrona y paralela.
El IQL en Jira, sin metáforas
Los estados reales del workflow. Bug, Defect e Improvement son tres work types distintos que COMPARTEN el workflow UPEX BUG/DEFECT LIFE CYCLE: Bug si la feature ya está viva por encima de Staging, Defect si todavía es pre-release (la salida normal del sprint testing) e Improvement si el comportamiento no viola ningún criterio de aceptación. Clasificar antes de filear es obligatorio. Ojo con tres nombres ambiguos por diseño: Candidate y MANUAL son a la vez estados del TC y veredictos de ROI del step 4; Deferred es a la vez veredicto de ROI y estado terminal del Bug. El veredicto y el estado no son lo mismo aunque compartan nombre.
User Story
13 estados- Backlog
- Shift-Left QAAnalyze
- EstimationEstimate
- Ready For DevEstimated and Ready to work
- In ProgressStart working
- In ReviewPull Request
- Ready For QADeployed
- In TestStart Testing
- QA ApprovedQA Sign-Off
- Ready For Releaseinclude in release
- Deployed to Productionreleased
Desvíos
- In Test → BLOCKED (defect reported)
- BLOCKED → In Progress (Fix defect)
- ABORTED → Ready For Dev (Recover)
Bug
11 estados- Open
- In Progressstart fixing
- In ReviewPull Request
- Ready For QAFixed & Deployed
- ClosedReTest Passed
Desvíos
- Open → Cannot Reproduce (is CNR)
- Open → Deferred (defer)
- Open → Duplicated (is duplicated)
- Open → REJECTED (is WAD)
- Open → Enhancement (is not a Bug)
- Deferred → In Progress (resume fix)
Test Case
10 estados- Draft
- In Designstart design
- READYready to run
- In Reviewautomation review
- Candidateapprove to automate
- In Automationstart automation
- Pull Requestcreate PR
- AUTOMATEDmerged
Desvíos
- READY → MANUAL (for manual)
- Candidate → MANUAL (manual execution)
- MANUAL → Candidate (for automation)
- AUTOMATED → Pull Request (Fix)
- DEPRECATED → Draft (recover)
Fuente: .agents/jira-workflows.json del boilerplate agentic-qa-boilerplate (configuración real de la instancia, con ids de estado y de transición). Donde un SKILL.md contradiga ese JSON, gana el JSON.
Jira · UPEX Feature (US) Workflow
Ciclo de vida de una historia de usuario
Los trece estados de una historia en Jira, agrupados en las cuatro etapas por las que pasa: refinamiento, desarrollo, QA y cierre. Un defecto encontrado en pruebas la bloquea y la devuelve a desarrollo.
Jira · UPEX BUG/DEFECT LIFE CYCLE
Ciclo de vida de un bug
Los once estados de un bug en Jira. De los seis caminos que salen de Open, cuatro lo cierran sin arreglarlo (no reproducible, duplicado, funciona según lo diseñado, es una mejora), uno lo aplaza a Deferred y uno entra al ciclo de arreglo.
Jira · UPEX Test (TC) Workflow
Ciclo de vida de un caso de prueba
Los diez estados por los que pasa un TC en Jira, del borrador a automatizado, con la bifurcación que decide si el caso se automatiza o se queda manual.
Dónde vive cada artefacto
El plan, el set y la ejecución no son documentos sueltos en una carpeta: son issues enlazados a la propia historia, y aparecen donde Jira los pone de verdad — en el bloque de linked issues, debajo de los criterios de aceptación. Así se ve una historia en test, con su ATP, su ATS y su ATR nombrados con la gramática de la escalera.
Las siete pestañas son navegables: los dos boards con sus columnas agrupadas, la historia con su panel de cobertura de Xray, y las cuatro fichas del plan, la corrida, el caso y el defecto vistas por dentro. El interruptor del panel de cobertura apaga el enlace del ATS y muestra lo que pasa entonces.
JJira · UPEX Coin Sandbox
Sprint#7 · UPEX Coin Sandbox — historias y defectos
Por empezar 2
Backlog · Open
Notificar el depósito por email
GX-16
Backlog
El saldo no se actualiza cuando el depósito tiene decimales
GX-58
Open
Refinamiento 2
Shift-Left QA · Estimation
Exportar movimientos a CSV
GX-15
Shift-Left QA
Definir límites diarios de retiro
GX-19
Estimation
Desarrollo 3
Ready For Dev · In Progress · In Review
Editar el alias de la wallet
GX-17
Ready For Dev
Retirar saldo a una cuenta bancaria
GX-14
In Progress
El historial pierde el filtro al paginar
GX-20
In Review
Pruebas 2
Ready For QA · In Test
Confirmar el depósito con doble factor
GX-13
Ready For QA
Registrar depósito en mi wallet
GX-12
In Test
Cierre 2
QA Approved · Ready For Release · Deployed to Production · Closed
Ver el historial de movimientos
GX-9
QA Approved
Iniciar sesión con email
GX-11
Deployed to Production
Desvíos 2
BLOCKED · ABORTED · Deferred · Duplicated · Enhancement · Cannot Reproduce · REJECTED
Bloquear la wallet por intentos fallidos
GX-18
BLOCKED
El monto acepta más de dos decimales
GX-21
Deferred
Dos modalidades, el mismo método
Cuándo un Test Case se convierte en work item del TMS. Cambia con la herramienta, no con la metodología. OJO con las dos numeraciones: acá «Stage 1» y «Stage 4» son stages del pipeline del boilerplate (Stage 0…6), no steps del IQL. El Stage 4 (/test-documentation) contiene los steps 4 y 5 del IQL; que el step 4 y el Stage 4 coincidan en la decisión de ROI es casualidad, no equivalencia.
La instancia de UPEX trabaja en Jira + Xray (jira-xray). jira-native es el default de fábrica: se cae ahí cuando no hay Xray configurado (`tms_cli: null`). No es una declaración del boilerplate — la modalidad se resuelve por sondeo.
Jira nativo
jira-nativePor defectoEn Stage 1 (planificación) solo salen outlines dentro del ATP. Un issue Test nativo YA ES documentación, así que espera al gate de 'regression-worthy' del Stage 4, que corre después de ejecutar y reportar.
Steps donde cambia el trabajo
- 4Priorización Risk-Based
- 5Documentación Asíncrona de Test Cases
Jira + Xray
jira-xrayLos casos se crean y se ejecutan en Stage 1, porque en Xray el issue Test es la unidad de ejecución. En Stage 4 los regression-worthy se promueven al Test Plan de regresión y el resto queda como artefacto de sprint.
Steps donde cambia el trabajo
- 3Pruebas Exploratorias Tempranas
- 4Priorización Risk-Based
- 5Documentación Asíncrona de Test Cases
La Trifuerza del Testing
La Trifuerza (antes llamada Tridente): el modelo de exploración del Stage 2 — las tres capas que se recorren para validar una feature, UI · API · DB. Es también el conocimiento mínimo esencial que UPEX exige a un QA.
ui
System Testing
Testing E2E / Frontend
Pruebas que validan el flujo completo desde la UI
api
Logic Layer Testing
API Testing / Backend
Pruebas a nivel de lógica de negocio
db
Data Layer Testing
Testing de Base de Datos
Pruebas de la capa de datos
Integración con el Modelo ATLAS
El Integrated Quality Lifecycle se implementa a través del Modelo ATLAS, el framework pedagógico de UPEX.
Cómo se conectan
El IQL define QUÉ hacer
Las fases, actividades y objetivos estratégicos de gestión de calidad.
ATLAS define CÓMO aprenderlo
La estructura pedagógica, las herramientas y la progresión de competencias.
Resultado: QA completo
Un profesional con metodología integral y competencias técnicas sólidas.
Modelo ATLAS
Framework pedagógico
Sistema de aprendizaje estructurado que combina teoría, práctica y mentoría para formar QAs que dominan el Integrated Quality Lifecycle completo.
Explorar el Modelo ATLASDónde se aprende el IQL
Leer el método alcanza para entenderlo. Para operarlo hace falta un Jira con historias de verdad, un TMS con casos que alguien va a ejecutar y un repositorio donde el pull request lo revisa otra persona.
- GRATIS
Testing al Grano 3.0
curso interactivo
Siete módulos con quizzes y un simulador de Jira donde se entrenan las dos primeras etapas del TMLC. Gratis y sin cuenta de pago.
Empezar el curso - PREMIUM
Dojo Saga 1 · Sprint Testing
IQL Steps 1-7
Shift-Left + Sprint Testing · Primer contacto con Automation (clase puente)
Ver Dojo Saga 1 - PREMIUM
Dojo Saga 2 · Automation
IQL Steps 7-15
Test Automation · Regression + Observability
Ver Dojo Saga 2 - PREMIUMRECOMENDADO
Dojo Agentic Quality Engineer
programa completo
Las dos sagas seguidas, sobre un proyecto real con Jira, el TMS y el repositorio de verdad.
Ver el programa
Clase a clase
El syllabus del DOJO, mapeado contra los quince steps
Cada clase declara qué steps del IQL trabaja, con qué rol y qué entrega. La tabla sale del mismo syllabus que usa la Dojoteca, así que no puede desalinearse del curso.
| Clase | Título | Modalidad | Fase IQL | Steps | Rol | Entregable | Detalle |
|---|---|---|---|---|---|---|---|
| 0 | Onboarding | Async | Pre-IQL | — | Setup | Workspace configurado | |
| 1 | Agentes e Ingeniería de Contexto | Live | Pre-IQL | — | Agentic QA Foundations | Tu primer agente CLI configurado + flow agentic end-to-end completo | |
| 2 | Shift-Left Testing | Live | Early-Game | 01Análisis de Requerimientos+1 | QA Analyst | ATP refinados con criterios de aceptación testeables | |
| 3 | Sprint Testing — Trifuerza | Live | Early-Game | 03Pruebas Exploratorias Tempranas | QA Analyst | Bugs reportados en Jira (input para Clase 4) | |
| 4 | Bugs & Test Management | Live | Mid-Game | 03Pruebas Exploratorias Tempranas+3 | QA Analyst | Dashboard de defectos + bugs retesteados con sign-off + TCs formales documentados en el TMS con veredicto ROI (Candidate/Manual/Deferred) | |
| 🎓 | Ceremonia de Certificación · Saga 1 | Hybrid | Cierre | — | Evaluación | Certificados Agentic Quality Analyst Engineer + Jira & Xray Expertise | |
| 5 | E2E Automation — Fundamentos | Live | Mid-Game | 07Automatización con Playwright + Patrón de Diseño KATA | QA Automation Engineer | 1 método KATA con @atc('KEY') funcional (la automatización de un ATC candidato) | |
| 6 | E2E Automation — Estructura y Patrones | Live | Mid-Game | 07Automatización con Playwright + Patrón de Diseño KATA | QA Automation Engineer | Suite E2E con POM + fixtures + paralelización | |
| 7 | API Automation | Live | Mid-Game | 07Automatización con Playwright + Patrón de Diseño KATA | QA Automation Engineer | Suite API automation integrada con E2E | |
| 8 | CI/CD & Agentic Routines | Live | Mid-Game | 08Verificación de ATCs en CI+1 | QA Automation Engineer | Pipeline GitHub Actions + Allure + Xray reporting + 1 rutina agéntica programada | |
| 9 | Test Architecture (SDET) | Live | Late-Game | 10Continuous Maintenance | SDET | Arquitectura KATA implementada con multi-project setup | |
| 10 | Regresión y Observabilidad | Live | Late-Game | 11Canary Release Monitoring+4 | QA + DevOps | Suite de regresión mantenida y actualizada + reporte del panorama de observabilidad de la industria | |
| 🎓 | Ceremonia de Certificación · Saga 2 | Hybrid | Cierre | — | Evaluación | Certificados Agentic Quality Automation Engineer + Playwright Expertise |
Cada fila abre el detalle completo de la clase: objetivo, bloques en vivo, trabajo asíncrono, herramientas y los steps del IQL con su nombre.
Early-Game: Prevención (QA Analyst)
Mid-Game: Detección (QA Automation)
Late-Game: Observación (QA + DevOps)
Domina la metodología IQL
Conviértete en el QA que las empresas necesitan: uno que entiende y aplica gestión integral de calidad durante todo el ciclo de vida del software.
El IQL se practica de punta a punta en el Programa DOJO, con Jira, el TMS y el repositorio reales.