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
Early-Game · PrevenciónMid-Game · DetecciónLate-Game · Observación

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.

El IQL completo, sus quince stepsLas tres fases del Integrated Quality Lifecycle con sus quince pasos: Early-Game de prevención a cargo del QA Analyst, Mid-Game de detección a cargo del QA Automation Engineer y Late-Game de observación a cargo de QA y DevOps. Marca en qué pasos caen las cuatro etapas del Test Manual Life Cycle y las cuatro del Test Automation Life Cycle, y cómo el último paso realimenta el primero.EARLY-GAMEQA AnalystPrevenciónSTEPS 1 A 4MID-GAMEQA Automation EngineerDetecciónSTEPS 5 A 9LATE-GAMEQA + DevOpsObservaciónSTEPS 10 A 15TMLC · ETAPA 1TMLC · ETAPAS 2 Y 3TMLC · ETAPA 4TALC · ETAPAS 1 A 4SIGUIENTE CICLO1Análisis deRequerimientosTMLC 1ST STAGE2Desarrollo eImplementaciónPARALLEL WORK3PruebasExploratoriasTempranasTMLC 2ND STAGE4PriorizaciónRisk-BasedTMLC 3RD STAGE5ASÍNCRONADocumentaciónAsíncrona deTest CasesTMLC 4TH STAGE6Evaluación de TCspara AutomatizaciónTALC 1ST STAGE7Automatización conPlaywright + Patrónde Diseño KATATALC 2ND STAGE8Verificación deATCs en CITALC 3RD STAGE9Pull Request ReviewTALC 4TH STAGE10ContinuousMaintenancePRODUCTION OPS11Canary ReleaseMonitoringSHIFT-RIGHT12A/B TestingEXPERIMENTATION13Real UserMonitoringOBSERVABILITY14Chaos EngineeringRESILIENCE15Feedback LoopCONTINUOUS LEARNINGLEYENDAFuera del alcance directo de QATMLC · Test Manual Life CycleTALC · Test Automation Life CycleRealimenta el siguiente ciclo
Ver a pantalla completa

  1. Steps 1-4

    Early-Game

    Prevención · QA Analyst

  2. Steps 5-9

    Mid-Game

    Detección · QA Automation Engineer

  3. Steps 10-15

    Late-Game

    Observación · QA + DevOps

Por qué esto no es el STLC

El STLC trata al testing como una etapa del proyecto: empieza cuando termina el desarrollo y termina cuando empieza el deploy. El IQL no mueve esa caja de lugar, la disuelve y reparte la responsabilidad de calidad a lo largo de todo el ciclo de vida.

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.

El STLC clásico contra el IQL sobre el eje del SDLCTres carriles sobre un mismo eje temporal del ciclo de vida del software: arriba las seis fases del SDLC, en el medio el STLC clásico, que no tiene ninguna actividad antes de la codificación, y abajo el Integrated Quality Lifecycle repartido por todo el ciclo. Dos conectores que se cruzan muestran la inversión: el IQL ejecuta de forma exploratoria en su paso 3 lo que el STLC ejecuta en su paso 5, y documenta los casos de prueba en su paso 5, después de ejecutar, en vez de escribirlos antes como hace el paso 3 del STLC. Debajo, la articulación Integrated une la capa de análisis con la capa de automatización y con los pasos de producción. Dos conectores rosados más finos cierran el arco por la derecha: la fase de despliegue del SDLC es donde nace el paso 10 del IQL, y la de mantenimiento es donde viven sus pasos 11 a 15.SDLCciclo de vidadel softwareSTLCtradicionalsteps 01-06IQLintegratedqualitylifecycleEARLYMIDTMLC · CAPA ANALISTA② SHIFT-LEFT③ SOPORTE EN LOCALHOST① EJECUTAR PRIMERO① DOCUMENTAR DESPUÉS→ STEP 10→ STEPS 11-15RequerimientosDiseñoCodificaciónTestingDespliegueMantenimientoEl STLC arrancacuando el códigoya existe. Antes, nada.01RequirementAnalysis02TestPlanning03①Test CaseDevelopment04TestEnvironmentSetup05①TestExecution06Test CycleClosure01②Análisis deRequerimientos02③Desarrollo eImplementación03④PruebasExploratoriasTempranas04PriorizaciónRisk-Based05①DocumentaciónAsíncrona deTest Cases④ plan + lo que aparezcaI · INTEGRATED⑥TMLC → TALC⑤ Con la ejecución ya hechase sabe qué merece regresióny qué merece automatizarse.TALC · STEPS 6-9capa de automatización⑤06 · Evaluación de TCs para Automatización07 · Automatización con Playwright + Patrón de Diseño KATA08 · Verificación de ATCs en CI09 · Pull Request ReviewLATE-GAME · STEPS 10-15producción como fase del método10 · Continuous Maintenance11 · Canary Release Monitoring12 · A/B Testing13 · Real User Monitoring14 · Chaos Engineering15 · Feedback LoopLEYENDASDLCSTLC clásicoEarly-Game · steps 1-4Mid-Game · steps 5-9Late-Game · steps 10-15opcional
Ver a pantalla completa

Las seis diferencias, mapeadas al dibujo

  • El caso de prueba se documenta después de ejecutar

    En el STLC 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 modelo tradicional 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 compite con el STLC: lo absorbe. Deja de ser un ciclo aparte y pasa a ser una capa del ciclo de desarrollo.»

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-Game

Mid-Game

Fase 2 · Detección · Steps 5-9

«¿El software cumple con los requerimientos?»

QA Automation Engineer

Ir a Mid-Game

Late-Game

Fase 3 · Observación · Steps 10-15

«¿Cómo se comporta en el mundo real?»

QA + DevOps

Ir a Late-Game
Early-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

  1. Step 1: Análisis de Requerimientos

    Early-GameTMLC 1st Stage

    Entender 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

  2. Step 2: Desarrollo e Implementación

    Early-GameParallel Work

    Construir y desplegar la US en un entorno de staging mientras QA prepara la estrategia

    Entregable

    Entorno funcional para testing

  3. Step 3: Pruebas Exploratorias Tempranas

    Early-GameTMLC 2nd Stage

    Validar 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

  4. Step 4: Priorización Risk-Based

    Early-GameTMLC 3rd Stage

    Decidir 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
Ver el Early-Game en detalle

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.

La cascada de cobertura de un Test CaseLos tres peldaños por los que un caso de prueba resuelve hasta su historia de usuario. El primero pasa por el Acceptance Test Set y es el único que llena el panel de cobertura. El segundo pasa por el Acceptance Test Plan y la historia se lee sin cobertura aunque el enlace exista. El tercero enlaza el caso directo a la historia y es un último recurso válido. Un caso sin ninguna de esas aristas queda huérfano. También distingue las dos capas en juego: la membresía interna de Xray y los enlaces de asunto de Jira.CASCADA DE RESOLUCIÓN · SE BAJA UN PELDAÑO SOLO CUANDO EL ANTERIOR NO EXISTEMEMBRESÍA XRAYISSUE LINK · TESTS1TCTest CaseATSAcceptance Test SetStoryis tested byCOBERTURALlena el panelMEMBRESÍA XRAYISSUE LINK · TESTS2TCTest CaseATPAcceptance Test PlanStoryis tested byTRAZABILIDAD ADMINISTRATIVAUNCOVERED · 0 testsISSUE LINK DIRECTO3TCTest CaseStoryis tested byCOBERTURAÚltimo recurso válidoSIN ARISTA—TCTest CaseStorysin cubrirHUÉRFANOFuera de trazabilidadMODALIDAD JIRA-NATIVESin capa de Xray no hay membresía por GraphQL: ahí la pertenencia sí se expresa como issue links TC a ATS.Y si la instancia no tiene el work type Test Set, no hay ATS: la cascada cae directo al tercer peldaño.LEYENDAMembresía de Xray (GraphQL), no es un issue linkIssue link de Jira, slug testLa historia es la parte inward: invertir la arista da cero cobertura
Ver a pantalla completa

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.

  1. 1st StageAnálisisstep 1 · Análisis de Requerimientos
  2. 2nd StageExploraciónstep 3 · Pruebas Exploratorias Tempranas
  3. 3rd StagePriorizaciónstep 4 · Priorización Risk-Based
  4. 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.

  1. 1st StageEvaluaciónstep 6 · Evaluación de TCs para Automatización
  2. 2nd StageAutomatizaciónstep 7 · Automatización con Playwright + Patrón de Diseño KATA
  3. 3rd StageVerificación CIstep 8 · Verificación de ATCs en CI
  4. 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.

Los pasos del QA Analyst en el sprintLas tres stages del flujo de sprint testing. La planificación crea primero los casos de prueba, después el Acceptance Test Set que los agrupa, después el enlace del set a la historia —el único que da cobertura—, después el plan de aceptación desde el campo de la historia y por último la corrida, que sin Test Environment no pasa el Definition of Done. Las listas del plan y de la corrida derivan de la membresía del set. Siguen la ejecución, que empieza por el smoke y sigue con la exploración, y el reporte.STAGE 1PlanningEl orden importaMODALIDAD JIRA-XRAYSTAGE 2ExecutionSmoke, luego explorarSTAGE 3ReportingCerrar y comunicarLISTA DERIVADA1Crear los Test (TC)de la historiaAL DETALLE EJECUTABLE2Crear el ATS contodos ellosATS: {STORY-KEY}: {TITLE}3Linkear ATS a lahistoriaSLUG TEST · IS TESTED BY4Recién ahí, el ATPDESDE EL CUSTOM FIELD5El ATR, con su TestEnvironmentSIN ENV NO PASA EL DoD6Smoke test primeroGO / NO-GO7Exploración de latrifuerza UI · API · DBMÁS ALLÁ DE LO PLANIFICADO8Completar el ATRRESULTADO POR CASO9Comentario de QA ytransición del ticketDEFECTOS, SI LOS HUBOLEYENDALa lista deriva del ATS, no se re-listaÚnica arista que da coberturaDoD · Definition of Done
Ver a pantalla completa

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.

Los pasos del QA Automation y las capas de KATALos cuatro pasos del Integrated Quality Lifecycle que conduce el QA Automation Engineer, que son las cuatro etapas del Test Automation Life Cycle, y debajo las capas de la arquitectura KATA sobre las que se implementan: contexto de pruebas, componentes base, componentes de dominio donde vive el decorador de trazabilidad, la capa opcional de pasos reutilizables y los fixtures de inyección. Una capa puede usar las de abajo, nunca al revés.IQL · MID-GAME · LOS STEPS DEL QA AUTOMATION ENGINEERIMPLEMENTA EN CÓDIGO6Evaluación de TCspara AutomatizaciónTALC 1ST STAGE7Automatización con Playwright+ Patrón de Diseño KATATALC 2ND STAGE8Verificación de ATCsen CITALC 3RD STAGE9Pull Request ReviewTALC 4TH STAGEKATA · KOMPONENT ACTION TEST ARCHITECTUREL4Fixtures (DI)TestFixture.ts · ApiFixture.ts · UiFixture.tsEl punto de entrada de la inyecciónL3.5StepsAuthSteps.ts · CheckoutSteps.tsOpcional · sin fixture: se instancian directoL3Domain ComponentsUsersApi.ts · LoginPage.ts@atc('KEY')Aquí vive el decoradorL2Base ComponentsApiBase.ts · UiBase.tsHelpers de HTTP y de PlaywrightL1TestContextTestContext.tsConfig, logger, faker y entornoDOS CORRECCIONES QUE IMPORTANLas cuatro letras de KATA no son las capas: son Komponent Action Test Architecture, y las capas son las cinco de arriba.El ATC tampoco es un TC implementado en código: es lo que un TC ES cuando nace de un criterio de aceptación.El decorador @atc('KEY') nombra su representación en código, no una entidad distinta.LEYENDAUna capa puede usar las de abajo, nunca al revésCapa opcionalTALC · Test Automation Life Cycle
Ver a pantalla completa

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
  1. Backlog
  2. Shift-Left QAAnalyze
  3. EstimationEstimate
  4. Ready For DevEstimated and Ready to work
  5. In ProgressStart working
  6. In ReviewPull Request
  7. Ready For QADeployed
  8. In TestStart Testing
  9. QA ApprovedQA Sign-Off
  10. Ready For Releaseinclude in release
  11. Deployed to Productionreleased

Desvíos

  • In Test → BLOCKED (defect reported)
  • BLOCKED → In Progress (Fix defect)
  • ABORTED → Ready For Dev (Recover)

Bug

11 estados
  1. Open
  2. In Progressstart fixing
  3. In ReviewPull Request
  4. Ready For QAFixed & Deployed
  5. 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
  1. Draft
  2. In Designstart design
  3. READYready to run
  4. In Reviewautomation review
  5. Candidateapprove to automate
  6. In Automationstart automation
  7. Pull Requestcreate PR
  8. 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.

Ciclo de vida de una historia de usuario en JiraMáquina de estados del ciclo de vida de una historia de usuario en Jira, del backlog a producción. Recorre cuatro etapas: refinamiento (backlog, análisis Shift-Left QA y estimación), desarrollo (listo para desarrollar, en curso y en revisión de código), QA (listo para probar, en prueba, bloqueado por defecto y aprobado) y cierre (listo para release y desplegado a producción). Un defecto reportado durante la prueba bloquea la historia y la devuelve a desarrollo, y desde cualquier estado la historia puede pasar a ABORTED.1 · REFINAMIENTO2 · DESARROLLO3 · QA4 · CIERRECreateAnalyzeEstimateEstimated & readyStart workingPull RequestDeployedStart Testingdefect reportedFix defectQA Sign-Offinclude in releasereleasedABORTED* desde cualquier estadoBacklog10035 · newShift-Left QA10037 · indeterminateEstimation10019 · indeterminateReady For Dev10009 · newIn Progress3 · indeterminateIn Review10030 · indeterminateReady For QA10004 · newIn Test10038 · indeterminateBLOCKED10023 · newQA Approved10017 · doneReady For Release10039 · doneDeployed to Production10040 · doneABORTED10022 · doneLEYENDAFocal: el desvío que cuesta caro (BLOCKED) y el final del camino (Deployed to Production).* Transición global: se dispara desde cualquier estado, no solo al crear la historia.Bajo cada estado: su id en Jira y su categoría. La categoría NO define el color.`Estimated & ready` abrevia `Estimated and Ready to work`, su nombre real en Jira.TRANSICIONES OMITIDAS · 13 DE 27Casi toda etapa vuelve a la anterior con `back` (6 transiciones).`Ready to Estimate`: Backlog salta a Estimation sin pasar por Shift-Left QA.`needs quality`: Estimation vuelve a Shift-Left QA. `Pushed`: In Progress salta a Ready For QA.`back to dev`: BLOCKED vuelve a Ready For Dev. `Recover`: una historia ABORTED vuelve a Ready For Dev.`Ready For Dev` y `Ready For QA` también son globales: se salta ahí desde cualquier estado.
Ver a pantalla completa

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.

Ciclo de vida de un bug en JiraMáquina de estados del ciclo de vida de un bug en Jira. Desde Open, el bug se reparte en seis caminos: cuatro lo descartan 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, que va de In Progress a Closed pasando por Pull Request y Ready For QA. Un bug aplazado se retoma hacia In Progress, y desde cualquier estado puede pasar a ABORTED.CLASIFICACIÓNDESCARTE · NADIE ESCRIBE CÓDIGOCICLO DE ARREGLOCreatedeferis CNRis duplicatedis WADis not a Bugstart fixingresume fixPull RequestFixed & DeployedReTest PassedABORTED* desde cualquier estadoOpen1 · newDeferred10012 · indeterminateCannot Reproduce10041 · doneDuplicated10013 · doneREJECTED10016 · doneEnhancement10020 · doneABORTED10022 · doneIn Progress3 · indeterminateIn Review10030 · indeterminateReady For QA10004 · newClosed6 · doneLEYENDAFocal: el repartidor (Open) y el cierre limpio (Closed).* Transición global: se dispara desde cualquier estado, no solo al crear el bug.Bajo cada estado: su id en Jira y su categoría. La categoría NO define el color.El color lo define la posición en el flujo: triage, descarte, ciclo de arreglo.TRANSICIONES OMITIDAS · 3 DE 15`Hard pushed`: In Progress salta a Ready For QA sin pasar por In Review.`back`: un bug Closed vuelve a Ready For QA para volver a probarse.`Re-Open`: transición global que devuelve cualquier bug a Open.
Ver a pantalla completa

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.

Ciclo de vida de un caso de prueba en JiraMáquina de estados del ciclo de vida de un caso de prueba en Jira, del borrador a automatizado. Agrupa los diez estados en tres zonas: diseño, automatización y desenlace. Desde READY el caso se bifurca: entra a revisión de automatización o se declara MANUAL. Un caso automatizado vuelve a Pull Request cuando se arregla, y desde cualquier estado puede pasar a DEPRECATED.DISEÑOAUTOMATIZACIÓNDESENLACECreatestart designready to runfor manualautomation reviewapprove to automatestart automationcreate PRmergedautomatedFixDeprecateddesde cualquier estadoDraft10029 · newIn Design10014 · indeterminateREADY10010 · doneIn Review10030 · indeterminateCandidate10027 · newIn Automation10031 · indeterminatePull Request10032 · indeterminateMANUAL10033 · doneAUTOMATED10026 · doneDEPRECATED10034 · doneLEYENDAFocal: la bifurcación (READY) y el desenlace automatizado (AUTOMATED).Transición global: se dispara desde cualquier estado, no solo al crear el caso.Bajo cada estado: su id en Jira y su categoría. La categoría NO define el color.El color lo define la posición en el flujo: diseño, automatización, desenlace.TRANSICIONES OMITIDAS · 12 DE 24Toda etapa vuelve a la anterior con `back` (6 transiciones).MANUAL vuelve a In Review con `automation review` y baja a Candidate con `for automation`.Candidate y AUTOMATED también pasan a MANUAL con `manual execution`.Draft salta directo a In Review con `automation review`, sin pasar por READY.DEPRECATED vuelve a Draft con `recover`: un caso archivado se puede revivir.
Ver a pantalla completa

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 defecto

En 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-xray

Los 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

  1. El 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, las herramientas y la progresión de competencias.

  3. 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 ATLAS

Dó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

    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.

ClaseTítuloModalidadFase IQLStepsRolEntregableDetalle
0OnboardingAsyncPre-IQL—SetupWorkspace configurado
1Agentes e Ingeniería de ContextoLivePre-IQL—Agentic QA FoundationsTu primer agente CLI configurado + flow agentic end-to-end completo
2Shift-Left TestingLiveEarly-Game01Análisis de Requerimientos+1QA AnalystATP refinados con criterios de aceptación testeables
3Sprint Testing — TrifuerzaLiveEarly-Game03Pruebas Exploratorias TempranasQA AnalystBugs reportados en Jira (input para Clase 4)
4Bugs & Test ManagementLiveMid-Game03Pruebas Exploratorias Tempranas+3QA AnalystDashboard de defectos + bugs retesteados con sign-off + TCs formales documentados en el TMS con veredicto ROI (Candidate/Manual/Deferred)
🎓Ceremonia de Certificación · Saga 1HybridCierre—EvaluaciónCertificados Agentic Quality Analyst Engineer + Jira & Xray Expertise
5E2E Automation — FundamentosLiveMid-Game07Automatización con Playwright + Patrón de Diseño KATAQA Automation Engineer1 método KATA con @atc('KEY') funcional (la automatización de un ATC candidato)
6E2E Automation — Estructura y PatronesLiveMid-Game07Automatización con Playwright + Patrón de Diseño KATAQA Automation EngineerSuite E2E con POM + fixtures + paralelización
7API AutomationLiveMid-Game07Automatización con Playwright + Patrón de Diseño KATAQA Automation EngineerSuite API automation integrada con E2E
8CI/CD & Agentic RoutinesLiveMid-Game08Verificación de ATCs en CI+1QA Automation EngineerPipeline GitHub Actions + Allure + Xray reporting + 1 rutina agéntica programada
9Test Architecture (SDET)LiveLate-Game10Continuous MaintenanceSDETArquitectura KATA implementada con multi-project setup
10Regresión y ObservabilidadLiveLate-Game11Canary Release Monitoring+4QA + DevOpsSuite de regresión mantenida y actualizada + reporte del panorama de observabilidad de la industria
🎓Ceremonia de Certificación · Saga 2HybridCierre—EvaluaciónCertificados 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.

Ver cursos disponiblesVer el Programa DOJO

El IQL se practica de punta a punta en el Programa DOJO, con Jira, el TMS y el repositorio reales.