Phase 2 of 3 in the IQLSteps 5-9 · Detection

Mid-Game

«Does the software meet the requirements?»

Detection phase: focused on catching defects before release through structured testing

Lead role
QA Automation Engineer
Focus
Detection
Approaches integrated
Continuous Testing · Agile Testing · AI-Driven
Tools
Playwright · GitHub Actions (or equivalent CI) · Docker · Xray
View the full IQLPractice in the Workspace
~$

Mid-Game: where you are inside the IQL

The Integrated Quality Lifecycle runs through the 15 steps in three phases. Each one has its question, its leading role and its own way of looking at quality.

  1. Early-Game

    «Let's build it right from the start»

    Prevention — QA Analyst

    COMPLETED
    Scope
    Steps 1-4
    Approaches
    Shift-Left, BDD, Risk-Based
    Main role
    QA Analyst
    Tools
    Jira (or equivalent tracker), Confluence (or team wiki), API client (Postman, Bruno, curl), Agentic harness (Claude Code, OpenCode, Codex)

  2. Mid-Game

    «Does the software meet the requirements?»

    Detection — QA Automation Engineer

    CURRENT PHASE
    Scope
    Steps 5-9
    Approaches
    Continuous Testing, Agile Testing, AI-Driven
    Main role
    QA Automation Engineer
    Tools
    Playwright, GitHub Actions (or equivalent CI), Docker, Xray

  3. Late-Game

    «How does it behave in the real world?»

    Observation — QA + DevOps

    NEXT
    Scope
    Steps 10-15
    Approaches
    Shift-Right, Chaos Engineering, Production Monitoring, AI Ops
    Main role
    QA + DevOps
    Tools
    Sentry / Grafana / Datadog, Progressive delivery / feature flags, k6, UptimeRobot (or equivalent uptime monitor)

Agentic contract

The stages of this phase

The stage is what gets executed and gated: it has a name, never a number. Each one declares what the agent does, what the person signs, what evidence it demands and with how much autonomy. The steps stay inside, as its breakdown.

  1. Close and release

    Documentation

    Early-GameMid-GameL3 · Continuous DetectionTMLC 3rdTMLC 4thTALC 1st

    The ROI gate: over behavior already validated, each scenario gets exactly one verdict, and only the ones that proved regression value get persisted. Most have to fall into Deferred.

    The contract, the guardrails, the deliverables and the breakdown3 steps

    Agentic contract

    The agent does
    Derives the scenarios by technique, calculates the ROI, proposes Candidate, Manual or Deferred, exactly one per scenario, and persists only the regression-worthy ones in the TMS, with the link cascade built and the ATS linked to the story.
    The person signs
    Approves every ROI verdict, the regression epic and the feature's Test Set. The verdict doesn't get delegated: it's the decision that defines the suite for years to come.
    Evidence required
    ROI score per scenario with its justification, and the alarm triggered if more than half fall into Candidate or Manual (a sign the filter wasn't applied).

    Autonomy

    2 on a 0-5 scale

    Separate verifier

    recommendedVerified by:second-agent

    Owning skill
    test-documentation
    Guardrails that govern it
    ReadWriteApprovalValidationTraceabilityCheckpoints
    Roles
    QA AnalystQA LeadExecutorVerifier

    Comes out of here

    • TC / ATC persisted in the TMS
    • ROI verdict per scenario
    • Feature's TS (optional)

    Jira transitions

    • TC: Draft → In Design (start design)
    • TC: In Design → READY (ready to run)
    • TC: READY → In Review (automation review)
    • TC: In Review → Candidate (approve to automate)
    • TC: READY → MANUAL (for manual)
    Steps it is made of · 3

    1. Step 4: Risk-Based Prioritisation

      Early-GameTMLC 3rd Stage

      Decide which ATP scenarios deserve a persistent Test Case (TC) in the TMS and which stay exploratory. The decision runs AFTER executing and reporting: the persistent regression set is decided on ROI, never assumed at planning time.

      Deliverable

      Refined ATP, with an ROI verdict per scenario

      Criteria
      Potential impactDefect probabilityValue-Cost-Risk
      Tools
      Jira (or equivalent tracker)
      Boilerplate
      Documentation, Prioritize phase (ROI)/test-documentation

    2. Step 5: Asynchronous Test Case Documentation

      Mid-GameTMLC 4th Stage

      Formalise in the TMS the Test Cases (TC) of every scenario with a Candidate or Manual verdict. The verb changes with the modality: in `jira-native` those TCs are CREATED here (a native Test issue is already documentation, so it waits for the ROI gate); in `jira-xray` (UPEX's own instance) the Tests exist from Planning and here they are ENRICHED and PROMOTED: rich Gherkin, `regression-candidate` label, the feature's Test Set and the Regression Test Plan. It is asynchronous on purpose: documentation happens AFTER executing and reporting, never before.

      Deliverable

      Backlog of high-value TCs in the TMS (native Jira or Xray), grouped in the story's ATS (Acceptance Test Set) and ready to be automated with Playwright

      Tools
      XrayJira (or equivalent tracker)
      Boilerplate
      Documentation, Document phase/test-documentation

    3. Step 6: Assessing TCs for Automation

      Mid-GameTALC 1st Stage

      Review the freshly documented TCs to determine which ones are automated with Playwright and which stay in manual regression

      Deliverable

      TCs approved for automation (Candidate verdict) or marked as Manual

      Tools
      XrayJira (or equivalent tracker)
      Boilerplate
      Documentation/Automation border: the verdict gets stamped with "approve to automate" (In Review → Candidate)/test-documentation → /test-automation

  2. Close and release

    Automation

    Mid-GameL3 · Continuous DetectionTALC 2ndTALC 3rdTALC 4th

    Only Candidates get in. First the plan, then the code, and three verifiers green before the pull request. It's the only stage with mandatory separate verification.

    The contract, the guardrails, the deliverables and the breakdown3 steps

    Agentic contract

    The agent does
    Writes the plan (specification and automation plan), implements it on the Implementation Standard's architecture with the decorator that ties each method to its case, runs the three verifiers and opens the pull request.
    The person signs
    Approves the plan BEFORE a single line of code gets written, approves the merge, and on the third failed attempt decides whether to keep going or stop.
    Evidence required
    Tests green, types and lint clean, every decorator resolving to a real ticket and a fresh manifest.

    Autonomy

    2 → 3 ceiling within the approved plan

    Separate verifier

    requiredVerified by:pr-review-leadjudgment-day

    Owning skill
    test-automation
    Guardrails that govern it
    ReadWriteApprovalSecretsValidationTraceabilityCheckpoints
    Roles
    QA Automation EngineerQA LeadExecutorVerifier

    Comes out of here

    • Methods automated with their traceability decorator
    • Reviewed pull request

    Jira transitions

    • TC: Candidate → In Automation (start automation)
    • TC: In Automation → Pull Request (create PR)
    • TC: Pull Request → AUTOMATED (merged)
    Steps it is made of · 3

    1. Step 7: Automating the Candidates

      Mid-GameTALC 2nd Stage

      Implement the candidate TCs in code with Playwright, on the KATA architecture. Every method carries the @atc('PROJ-101') decorator, which ties it to its case in Jira: the decorator names the code representation of that same ATC, not a different object.

      Deliverable

      Cases implemented in the automation repo, with a PR created

      Tools
      KATAPlaywrightAgentic harness (Claude Code, OpenCode, Codex)Jira (or equivalent tracker)
      Boilerplate
      Automation (Plan → Code)/test-automation

    2. Step 8: Verifying the Suite in CI

      Mid-GameTALC 3rd Stage

      Validate the automated ATCs with Playwright in the Continuous Integration pipeline

      Deliverable

      Stable ATCs in CI with no flakiness, with traceability reports

      Tools
      PlaywrightDockerGitHub / GitLab (repository and pull requests)GitHub Actions (or equivalent CI)Slack / Teams
      Boilerplate
      Automation (Review) + CI/test-automation

    3. Step 9: Pull Request Review

      Mid-GameTALC 4th Stage

      Open a Pull Request for review and approval of the ATCs automated with Playwright

      Deliverable

      PR merged, ATCs integrated into CI/CD

      Tools
      PlaywrightAgentic harness (Claude Code, OpenCode, Codex)GitHub / GitLab (repository and pull requests)
      Boilerplate
      Automation (Review)/test-automation (opcional /pr-review-lead)

Steps 5-9

The 5 steps of Mid-Game

Every step with its lifecycle stage, its deliverable, its Jira transition, and the note that prevents the typical misunderstanding. It is the full detail of the syllabus, without summarizing.

TMLCTest Manual Life Cycle

  1. 1st Stage: Analysis
  2. 2nd Stage: Exploration
  3. 3rd Stage: Prioritization
  4. 4th Stage: Documentation

TALCTest Automation Life Cycle

  1. 1st Stage: Assessment
  2. 2nd Stage: Automation
  3. 3rd Stage: CI Verification
  4. 4th Stage: PR Review

  1. Step 5: Asynchronous Test Case Documentation

    Mid-GameTMLC 4th Stage

    Formalise in the TMS the Test Cases (TC) of every scenario with a Candidate or Manual verdict. The verb changes with the modality: in `jira-native` those TCs are CREATED here (a native Test issue is already documentation, so it waits for the ROI gate); in `jira-xray` (UPEX's own instance) the Tests exist from Planning and here they are ENRICHED and PROMOTED: rich Gherkin, `regression-candidate` label, the feature's Test Set and the Regression Test Plan. It is asynchronous on purpose: documentation happens AFTER executing and reporting, never before.

    Deliverable

    Backlog of high-value TCs in the TMS (native Jira or Xray), grouped in the story's ATS (Acceptance Test Set) and ready to be automated with Playwright

    Boilerplate
    Documentation, Document phase/test-documentation

    Tools

    • XrayADAPTABLEImplementation standard

      The TMS mode UPEX operates with (`jira-xray`): the story's coverage comes natively from the ATS. The boilerplate starts in `jira-native` (`tms_cli: null`) and that mode is supported; another TMS (TestRail, Zephyr) gets evaluated as an adaptation. The initial assessment decides the mode, not the method.

    • Jira (or equivalent tracker)CLIENT-CONTROLLEDThe environment brings it

      The tracker belongs to the client. The IQL requires a workflow with the states and transitions of `iql.jiraStates`; today the Implementation Standard only has Jira implemented (`.agents/jira-workflows.json`), so Azure DevOps or another tracker is adaptation work evaluated at the start.

    Jira transition

    TCDraftIn Designstart designREADYready to run

  2. Step 6: Assessing TCs for Automation

    Mid-GameTALC 1st Stage

    Review the freshly documented TCs to determine which ones are automated with Playwright and which stay in manual regression

    Deliverable

    TCs approved for automation (Candidate verdict) or marked as Manual

    Boilerplate
    Documentation/Automation border: the verdict gets stamped with "approve to automate" (In Review → Candidate)/test-documentation → /test-automation

    Tools

    • XrayADAPTABLEImplementation standard

      The TMS mode UPEX operates with (`jira-xray`): the story's coverage comes natively from the ATS. The boilerplate starts in `jira-native` (`tms_cli: null`) and that mode is supported; another TMS (TestRail, Zephyr) gets evaluated as an adaptation. The initial assessment decides the mode, not the method.

    • Jira (or equivalent tracker)CLIENT-CONTROLLEDThe environment brings it

      The tracker belongs to the client. The IQL requires a workflow with the states and transitions of `iql.jiraStates`; today the Implementation Standard only has Jira implemented (`.agents/jira-workflows.json`), so Azure DevOps or another tracker is adaptation work evaluated at the start.

    Jira transition

    TCREADYIn Reviewautomation reviewCandidateapprove to automate
    TCREADYMANUALfor manual

  3. Step 7: Automating the Candidates

    Mid-GameTALC 2nd Stage

    Implement the candidate TCs in code with Playwright, on the KATA architecture. Every method carries the @atc('PROJ-101') decorator, which ties it to its case in Jira: the decorator names the code representation of that same ATC, not a different object.

    Deliverable

    Cases implemented in the automation repo, with a PR created

    Boilerplate
    Automation (Plan → Code)/test-automation

    Tools

    • KATARECOMMENDEDImplementation standard

      It's the architecture that makes every ATC traceable to its story (`@atc('KEY')`), and the one the boilerplate's skills know how to operate. When UPEX builds the automation from scratch it's used as is; on a framework the client keeps, its invariants (layers, dependency injection, decorators) are applied via `/adapt-framework`, without rewriting it.

    • PlaywrightRECOMMENDEDImplementation standard

      Default when UPEX automates from scratch: the boilerplate and KATA's layer 2 assume it. It isn't mandatory, because the IQL doesn't require migrations without technical justification: an existing mature stack (Cypress, WebdriverIO) gets evaluated at the start and is kept, adapted, or migrated in stages.

    • Agentic harness (Claude Code, OpenCode, Codex)ADAPTABLEImplementation standard

      The boilerplate's skills, commands and MCPs run on Claude Code, OpenCode (any LLM) or Codex, and adapt to any other harness. The method lives in the skills (markdown), not in the agent: changing harness changes speed and ergonomics, not the flow.

    • Jira (or equivalent tracker)CLIENT-CONTROLLEDThe environment brings it

      The tracker belongs to the client. The IQL requires a workflow with the states and transitions of `iql.jiraStates`; today the Implementation Standard only has Jira implemented (`.agents/jira-workflows.json`), so Azure DevOps or another tracker is adaptation work evaluated at the start.

    Jira transition

    TCCandidateIn Automationstart automation

  4. Step 8: Verifying the Suite in CI

    Mid-GameTALC 3rd Stage

    Validate the automated ATCs with Playwright in the Continuous Integration pipeline

    Deliverable

    Stable ATCs in CI with no flakiness, with traceability reports

    Boilerplate
    Automation (Review) + CI/test-automation

    Tools

    • PlaywrightRECOMMENDEDImplementation standard

      Default when UPEX automates from scratch: the boilerplate and KATA's layer 2 assume it. It isn't mandatory, because the IQL doesn't require migrations without technical justification: an existing mature stack (Cypress, WebdriverIO) gets evaluated at the start and is kept, adapted, or migrated in stages.

    • DockerRECOMMENDEDImplementation standard

      Reproducibility of the Playwright run in CI with the official image. If the client's CI already provides runners with browsers, it gets adapted.

    • GitHub / GitLab (repository and pull requests)CLIENT-CONTROLLEDThe environment brings it

      The repository and the pull request flow come from the client. The standard requires one branch per story and a reviewed PR.

    • GitHub Actions (or equivalent CI)CLIENT-CONTROLLEDThe environment brings it

      The CI comes from the client (GitHub Actions, GitLab CI, Jenkins). The standard requires the ATCs to run on every PR; the boilerplate's reference pipeline is written for GitHub Actions.

    • Slack / TeamsCLIENT-CONTROLLEDThe environment brings it

      CI notification and alert channel. The IQL doesn't depend on which one.

  5. Step 9: Pull Request Review

    Mid-GameTALC 4th Stage

    Open a Pull Request for review and approval of the ATCs automated with Playwright

    Deliverable

    PR merged, ATCs integrated into CI/CD

    Boilerplate
    Automation (Review)/test-automation (opcional /pr-review-lead)

    Tools

    • PlaywrightRECOMMENDEDImplementation standard

      Default when UPEX automates from scratch: the boilerplate and KATA's layer 2 assume it. It isn't mandatory, because the IQL doesn't require migrations without technical justification: an existing mature stack (Cypress, WebdriverIO) gets evaluated at the start and is kept, adapted, or migrated in stages.

    • Agentic harness (Claude Code, OpenCode, Codex)ADAPTABLEImplementation standard

      The boilerplate's skills, commands and MCPs run on Claude Code, OpenCode (any LLM) or Codex, and adapt to any other harness. The method lives in the skills (markdown), not in the agent: changing harness changes speed and ergonomics, not the flow.

    • GitHub / GitLab (repository and pull requests)CLIENT-CONTROLLEDThe environment brings it

      The repository and the pull request flow come from the client. The standard requires one branch per story and a reviewed PR.

    Jira transition

    TCIn AutomationPull Requestcreate PRAUTOMATEDmerged

Planning

The cases first, the plan after

Mid-Game opens by documenting, and the order of that documentation isn't the intuitive one: the story's test case set gets created before its plan and its execution, because both derive their list from it. And it's the set's link to the story —not the plan's— the only one that fills Jira's coverage panel.

Sprint Testing

The QA Analyst's steps in the sprint

The three stages of /sprint-testing and the exact planning order, where the ATS gets created before the plan and before the run.

The QA Analyst's steps in the sprintThe three stages of the sprint testing flow. Planning first creates the test cases, then the Acceptance Test Set that groups them, then the link from the set to the story — the only one that gives coverage —, then the acceptance plan from the story's field, and finally the run, which without a Test Environment doesn't pass the Definition of Done. The plan's and the run's lists derive from the set's membership. Then comes execution, which starts with the smoke test and continues with exploration, and reporting.01PlanningThe order mattersJIRA + XRAY MODALITY02ExecutionSmoke first, then explore03ReportingClose and communicateDERIVED LIST1Create the story'sTest Cases (TC)DOWN TO EXECUTABLE DETAIL2Create the ATS withall of themATS: {STORY-KEY}: {TITLE}3Link the ATS tothe storySLUG TEST · IS TESTED BY4Only then, the ATPFROM THE CUSTOM FIELD5The ATR, with its TestEnvironmentNO ENV, NO DoD6Smoke test firstGO / NO-GO7Trifuerza explorationUI · API · DBBEYOND WHAT WAS PLANNED8Fill in the ATRRESULT PER CASE9QA comment andticket transitionDEFECTS, IF ANYLEGENDThe list derives from the ATS, it isn't re-listedThe only edge that gives coverageDoD · Definition of Done
View full screen

Architecture

KATA (Komponent Action Test Architecture)

Step 7 implements the candidate TCs in code, and it does so on a layered architecture: four named layers, plus optional Steps, with a single dependency direction. Two warnings that carry the whole section: the acronym letters are not the layers, and the @atc decorator doesn't create a new artifact — it names the code representation of the same case that already existed in the test manager.

Test Automation

The QA Automation steps and KATA's layers

The IQL steps that the QA Automation Engineer drives, and the layers of the KATA architecture they get implemented on, with the optional middle layer in its place and the test file where it belongs: consuming, not as one more layer.

The QA Automation steps and KATA's layersThe steps of the Integrated Quality Lifecycle that the QA Automation Engineer drives, which are the stages of the Test Automation Life Cycle, and below them the KATA architecture they get implemented on: the test context, the base components, the domain components where the traceability decorator lives, the optional layer of reusable steps, and the injection fixtures. Above the stack, the test files, which consume the fixtures without being a layer. A layer can use the ones below, never the other way around.IQL · MID-GAME · THE QA AUTOMATION ENGINEER'S STEPSIMPLEMENTS IN CODE6Assessing TCsfor AutomationTALC 1ST STAGE7Automating the CandidatesTALC 2ND STAGE8Verifying the Suite in CITALC 3RD STAGE9Pull Request ReviewTALC 4TH STAGEKOMPONENT ACTION TEST ARCHITECTURETest filesOrchestrate ATCs into scenarios. They don't implement any layer.Consumes the layer above, without being oneL4Fixtures*Fixture.tsDependency injection point into the test file.L3.5StepsloginAndSeedCart.step.tsReusable precondition chains. They don't carry @atc.L3Domain componentsUsersApi, LoginPage@atc('KEY')Here, and only here, live the methods with the @atc decorator.L2BaseApiBase.ts · UiBase.tsHTTP helpers and Playwright helpers.L1TestContextTestContext.tsConfig, logger, faker and environment. Agnostic of API and UI.WHAT THIS DIAGRAM EXISTS TO FIXTest files consume the Fixtures. They're consumers, not a layer: counting them as a layer is where the five- and six-layer counts came from.The ATC isn't a TC implemented in code: it's what a TC IS when it's born from an acceptance criterion, and @atc('KEY') names its representation in code, not a separate entity.LEGENDA layer can use the ones below, never the other way aroundOptional layerTALC · Test Automation Life Cycle
View full screen

Automation pyramid

Where the effort is worth putting

Automating everything at the interface level is the most expensive way to end up with a fragile suite. The pyramid spreads the effort out: lots of cheap tests at the bottom, few expensive ones at the top, and in the middle whatever checks that the pieces talk to each other.

  1. E2E UI Tests

    10%

    Run through the whole flow from the interface, the way a person would. They're the closest to real usage and the most expensive to maintain.

    The slowest, the most comprehensive

    • Login flow
    • End-to-end purchase
    • User registration

  2. Integration / Service Tests

    20%

    Verify how components and services talk to each other, without going through the interface.

    Medium speed, good coverage

    • API integration
    • Database operations
    • Communication between services

  3. Unit Tests

    70%

    Written by whoever develops, over isolated functions and components. They run in seconds and are the base of the pyramid.

    Extremely fast

    • Function validation
    • Isolated components
    • Business logic

Integrated approaches

What lens Mid-Game works with

The IQL does not apply the same approaches across the whole cycle. These are the ones the syllabus assigns to this phase, and they explain why the work here does not look like the other two.

  • Continuous Testing

    Automated testing built into the pipeline, running on every change.

  • Agile Testing

    Test cycles that fit inside the sprint instead of pushing it forward.

  • AI-Driven

    Artificial intelligence applied to speed up analysis, documentation, and coverage.

Tools

What you work with in Mid-Game

The same pieces the syllabus assigns to the phase. They change from one phase to another because the work changes: analyzing does not need the same as automating, nor the same as monitoring production.
  • Playwright logo

    Playwright

    The runner for the automated cases. It is the base the KATA architecture is built on.

  • GitHub Actions (or equivalent CI) logo

    GitHub Actions (or equivalent CI)

    The pipeline where the suite runs on every change and gets checked for flakiness.

  • Docker logo

    Docker

    The reproducible environment: the suite runs the same on the QA machine as in CI.

  • Xray logo

    Xray

    The TMS: where the case lives, changes state, and gets grouped into its story ATS.

Master the Mid-Game

Become the QA Automation Engineer that companies need: the one who works quality starting from detection and knows how to answer «Does the software meet the requirements?».

See available courses
See the whole IQLImplement it with UPEX

The IQL is practiced end to end in the DOJO Program, with Jira, the TMS and the real repository.