Fase 2 de 3 del IQLSteps 5-9 · Detección

Mid-Game

«¿El software cumple con los requerimientos?»

Fase de Detección - Enfoque en detectar defectos antes del release a través de testing estructurado

Rol protagonista
QA Automation Engineer
Enfoque
Detección
Enfoques integrados
Continuous Testing · Agile Testing · AI-Driven
Herramientas
Playwright · GitHub Actions · Docker · Xray
Ver el IQL completoPracticar en el Workspace

Mid-Game: dónde estás dentro del IQL

El Integrated Quality Lifecycle recorre los 15 steps en tres fases. Cada una tiene su pregunta, su rol protagonista y su forma de mirar la calidad.

  1. Early-Game

    «Construyámoslo bien desde el principio»

    Prevención — QA Analyst

    RECORRIDA
    Alcance
    Steps 1-4
    Enfoques
    Shift-Left, BDD, Risk-Based
    Rol principal
    QA Analyst
    Herramientas
    Jira, Confluence, Postman, Claude Code

  2. Mid-Game

    «¿El software cumple con los requerimientos?»

    Detección — QA Automation Engineer

    FASE ACTUAL
    Alcance
    Steps 5-9
    Enfoques
    Continuous Testing, Agile Testing, AI-Driven
    Rol principal
    QA Automation Engineer
    Herramientas
    Playwright, GitHub Actions, Docker, Xray

  3. Late-Game

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

    Observación — QA + DevOps

    SIGUIENTE
    Alcance
    Steps 10-15
    Enfoques
    Shift-Right, Chaos Engineering, Production Monitoring, AI Ops
    Rol principal
    QA + DevOps
    Herramientas
    Sentry, Grafana, k6, UptimeRobot

Steps 5-9

Los 5 steps del Mid-Game

Cada step con su etapa del ciclo, su entregable, su transición en Jira y la nota que evita el malentendido típico. Es el detalle completo del syllabus, sin resumir.

TMLCTest Manual Life Cycle

  1. 1st Stage: Análisis
  2. 2nd Stage: Exploración
  3. 3rd Stage: Priorización
  4. 4th Stage: Documentación

TALCTest Automation Life Cycle

  1. 1st Stage: Evaluación
  2. 2nd Stage: Automatización
  3. 3rd Stage: Verificación CI
  4. 4th Stage: PR Review

  1. Step 5: Documentación Asíncrona de Test Cases

    Mid-GameTMLC 4th Stage

    Formalizar en el TMS los Test Cases (TC) de cada escenario con veredicto Candidate o Manual. El verbo cambia con la modalidad: en `jira-native` acá se CREAN esos TC (un issue Test nativo ya es documentación, así que espera al gate de ROI); en `jira-xray` (la instancia de UPEX) los Test existen desde el Stage 1 y acá se ENRIQUECEN y PROMUEVEN: Gherkin rico, label `regression-candidate`, Test Set de la feature y Regression Test Plan. Es asíncrona a propósito: se documenta DESPUÉS de ejecutar y de reportar, nunca antes.

    Entregable

    Backlog de TCs de alto valor en el TMS (Jira nativo o Xray), agrupados en el ATS (Acceptance Test Set) de la historia y listos para automatizarse con Playwright

    Transición en Jira

    TCDraftIn Designstart designREADYready to run

  2. Step 6: Evaluación de TCs para Automatización

    Mid-GameTALC 1st Stage

    Revisar los TCs recién documentados para determinar cuáles se automatizan con Playwright y cuáles se quedan en regresión manual

    Entregable

    TCs aprobados para automatizar (veredicto Candidate) o marcados como Manual

    Transición en Jira

    TCREADYIn Reviewautomation reviewCandidateapprove to automate
    TCREADYMANUALfor manual

  3. Step 7: Automatización con Playwright + Patrón de Diseño KATA

    Mid-GameTALC 2nd Stage

    Implementar en código los TCs candidatos con Playwright, sobre la arquitectura KATA. Cada método lleva el decorador @atc('PROJ-101'), que lo ata a su caso en Jira: el decorador nombra la representación en código del mismo ATC, no un objeto distinto.

    Entregable

    Casos implementados en el repo de automatización, con PR creado

    Arquitectura
    KATA (Komponent Action Test Architecture)

    Transición en Jira

    TCCandidateIn Automationstart automation

  4. Step 8: Verificación de ATCs en CI

    Mid-GameTALC 3rd Stage

    Validar los ATCs automatizados con Playwright en la pipeline de Continuous Integration

    Entregable

    ATCs estables en CI sin flakiness, con reportes de trazabilidad

    Herramientas
    GitHub ActionsDocker

  5. Step 9: Pull Request Review

    Mid-GameTALC 4th Stage

    Crear un Pull Request para revisión y aprobación de los ATCs automatizados con Playwright

    Entregable

    PR merged, ATCs integrados en CI/CD

    Transición en Jira

    TCIn AutomationPull Requestcreate PRAUTOMATEDmerged

Planificación

Los casos primero, el plan después

El Mid-Game abre documentando, y el orden de esa documentación no es el intuitivo: el set de casos de la historia se crea antes que su plan y que su ejecución, porque los dos derivan su lista de él. Y es el enlace del set a la historia —no el del plan— el único que llena el panel de cobertura de Jira.

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

Arquitectura

KATA (Komponent Action Test Architecture)

El step 7 implementa en código los casos candidatos, y lo hace sobre una arquitectura por capas: cuatro capas más una intermedia opcional, con una sola dirección de dependencia. Dos advertencias que valen la sección entera: las cuatro letras del acrónimo no son las capas, y el decorador @atc no crea un artefacto nuevo — nombra la representación en código del mismo caso que ya existía en el gestor de pruebas.

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

Pirámide de automatización

Dónde conviene poner el esfuerzo

Automatizar todo al nivel de interfaz es la forma más cara de tener una suite frágil. La pirámide reparte el esfuerzo: mucha prueba barata abajo, poca prueba cara arriba, y en el medio lo que verifica que las piezas se hablen.

  1. E2E UI Tests

    10%

    Recorren el flujo completo desde la interfaz, como lo haría una persona. Son los que más se parecen al uso real y los que más cuestan mantener.

    Los más lentos, los más abarcativos

    • Flujo de login
    • Compra de punta a punta
    • Registro de usuario

  2. Integration / Service Tests

    20%

    Verifican cómo hablan entre sí los componentes y los servicios, sin pasar por la interfaz.

    Velocidad media, buena cobertura

    • Integración de APIs
    • Operaciones contra la base
    • Comunicación entre servicios

  3. Unit Tests

    70%

    Los escribe quien desarrolla, sobre funciones y componentes aislados. Corren en segundos y son la base de la pirámide.

    Extremadamente rápidos

    • Validación de funciones
    • Componentes aislados
    • Lógica de negocio

Enfoques integrados

Con qué mirada se trabaja el Mid-Game

El IQL no aplica los mismos enfoques en todo el ciclo. Estos son los que el syllabus asigna a esta fase, y explican por qué el trabajo de acá no se parece al de las otras dos.

  • Continuous Testing

    Testing automatizado integrado en la pipeline, ejecutándose con cada cambio.

  • Agile Testing

    Ciclos de prueba que caben dentro del sprint y no lo empujan hacia adelante.

  • AI-Driven

    Inteligencia artificial aplicada a acelerar el análisis, la documentación y la cobertura.

Herramientas

Con qué se trabaja en el Mid-Game

Las mismas piezas que el syllabus le asigna a la fase. Cambian de una fase a otra porque cambia el trabajo: analizar no necesita lo mismo que automatizar, ni que observar producción.
  • Playwright logo

    Playwright

    El runner de los casos automatizados. Es la base sobre la que se monta la arquitectura KATA.

  • GitHub Actions logo

    GitHub Actions

    La pipeline donde los ATCs corren en cada cambio y se comprueba que no sean flaky.

  • Docker logo

    Docker

    El entorno reproducible: la suite corre igual en la máquina del QA que en CI.

  • Xray logo

    Xray

    El TMS: donde el caso vive, cambia de estado y se agrupa en el ATS de su historia.

Domina el Mid-Game

Conviértete en el QA Automation Engineer que las empresas necesitan: el que trabaja la calidad desde la detección y sabe responder «¿El software cumple con los requerimientos?».

Ver cursos disponiblesVer IQL completo

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