Phase 1 of 3 in the IQLSteps 1-4 · Prevention

Early-Game

«Let's build it right from the start»

Prevention phase: focused on preventing defects through early collaboration and analysis

Lead role: QA Analyst
Focus: Prevention
Approaches integrated: Shift-Left · BDD · Risk-Based
Tools: Jira (or equivalent tracker) · Confluence (or team wiki) · API client (Postman, Bruno, curl) · Agentic harness (Claude Code, OpenCode, Codex)

View the full IQL Practice in the Workspace

Early-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.

Early-Game
«Let's build it right from the start»
Prevention — QA Analyst
CURRENT PHASE
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)
Mid-Game
«Does the software meet the requirements?»
Detection — QA Automation Engineer
NEXT
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
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.

Before the sprint
Shift-Left
Early-GameL1 · PreventionTMLC 1st
The story gets analyzed before a single line of code exists, in batch and without creating a single entity in the TMS. Out comes the ATP in the story's own field, and out come the questions the team can still answer cheaply.
The contract, the guardrails, the deliverables and the breakdown1 step
Agentic contract
The agent does
Rewrites the acceptance criteria in Given/When/Then with concrete data, detects the gaps and drafts them as questions to the PO or the dev, writes the ATP in the `acceptance_test_plan` field, applies the Test-Design Checklist and leaves the dated label and the review subtask.
The person signs
Approves the batch of candidate stories and the summary per story. Answers the gaps. The story never moves past `Estimation`: that's the stage's hard ceiling.
Evidence required
Rewritten criteria in the story, open gaps as questions with a named recipient, dated label, closed `[QA] Shift-Left Review` subtask and zero TMS entities created.
Autonomy
2 on a 0-5 scale
Separate verifier
not needed
Owning skill
shift-left-testing
Guardrails that govern it
ReadWriteApprovalValidationCheckpoints
Roles
QA AnalystExecutor
Comes out of here
ATP in the `acceptance_test_plan` field
Gaps as questions to the PO/Dev
Jira transitions
US: Backlog → Shift-Left QA (Analyze)
US: Shift-Left QA → Estimation (Estimate)
Subtarea [QA] Shift-Left Review: ACTIVE → Close (Complete)
Steps it is made of · 1Half of the step: pre-sprint
Step 1: Requirements Analysis
Early-GameTMLC 1st Stage
Understand the requirements: the Epic analysis and each Story's analysis happen BEFORE the sprint, and the story's ATP comes out of that, living pre-sprint ONLY in the `acceptance_test_plan` field (no Test Plan item yet). The FTP item is not born here: it is created or refined inside /sprint-testing, when the Epic context is loaded, already in sprint. The FTP is a living document: written once per epic and refined throughout it, because the team learns with every story it delivers. And a story is never analysed alone: its siblings in the same epic are analysed too (the ones already built, the ones in development and the ones merely defined), because that full picture of the feature is what makes the ATPs better.
Deliverable
ATP (Acceptance Test Plan) per Story, pre-sprint in the story's field + FTP (Feature Test Plan) per Epic, whose item gets created when the sprint opens
Tools
Agentic harness (Claude Code, OpenCode, Codex)Jira (or equivalent tracker)Confluence (or team wiki)
Boilerplate
Shift-Left QA + Planning/shift-left-testing + /sprint-testing
Inside the sprint
Planning
Early-GameL1 · PreventionTMLC 1st
Already in sprint, the story's plan becomes items: first the ATS, then the ATP, then the ATR. Coverage is built on two axes, and the ATR doesn't exist without a declared environment.
The contract, the guardrails, the deliverables and the breakdown1 step
Agentic contract
The agent does
Creates the ATS first and derives the ATP and the empty ATR from it; derives the cases (outlines in `jira-native`, detailed Test in `jira-xray`); decides by triage, veto and risk-score which UI/API/DB surfaces get in, without asking; creates or finds the epic's STP and FTP.
The person signs
Confirms the explanation of the story before the stage moves forward: the agent explains what it understood and waits for the OK.
Evidence required
ATP as a Test Plan item created from the field, Set-first order respected, ATR ALWAYS with a Test Environment (without it the stage fails its DoD) and coverage declared on two axes.
Autonomy
2 on a 0-5 scale
Separate verifier
not needed
Owning skill
sprint-testing
Guardrails that govern it
ReadWriteApprovalValidationTraceabilityCheckpoints
Roles
QA AnalystExecutor
Comes out of here
ATS
ATP (Test Plan item)
Empty ATR with Test Environment
FTP
STP
Steps it is made of · 1Half of the step: in-sprint
Step 1: Requirements Analysis
Early-GameTMLC 1st Stage
Understand the requirements: the Epic analysis and each Story's analysis happen BEFORE the sprint, and the story's ATP comes out of that, living pre-sprint ONLY in the `acceptance_test_plan` field (no Test Plan item yet). The FTP item is not born here: it is created or refined inside /sprint-testing, when the Epic context is loaded, already in sprint. The FTP is a living document: written once per epic and refined throughout it, because the team learns with every story it delivers. And a story is never analysed alone: its siblings in the same epic are analysed too (the ones already built, the ones in development and the ones merely defined), because that full picture of the feature is what makes the ATPs better.
Deliverable
ATP (Acceptance Test Plan) per Story, pre-sprint in the story's field + FTP (Feature Test Plan) per Epic, whose item gets created when the sprint opens
Tools
Agentic harness (Claude Code, OpenCode, Codex)Jira (or equivalent tracker)Confluence (or team wiki)
Boilerplate
Shift-Left QA + Planning/shift-left-testing + /sprint-testing
Inside the sprint
Execution
Early-GameL2 · Early DetectionTMLC 2nd
Two moves, in this order: the smoke validates the environment, the Trifuerza validates the feature. Whatever shows up outside the plan feeds back into the set, it doesn't get discarded.
The contract, the guardrails, the deliverables and the breakdown1 step
Agentic contract
The agent does
Runs the smoke test as Go/No-Go before anything else, executes what was planned and explores beyond it across UI, API and DB, feeds new partitions back into the set and proposes every finding already classified (Bug / Defect / Improvement) with its derived severity.
The person signs
Triages every finding and decides whether each one gets filed: no bug gets created without explicit human agreement that it's a real defect. Manually recalibrates any severity in the security or authentication class.
Evidence required
Smoke test run first and logged, screenshots and responses under the ticket's evidence folder, and every finding traced back to the story and to the acceptance criterion.
Autonomy
3 on a 0-5 scale
Separate verifier
not needed
Owning skill
sprint-testing
Guardrails that govern it
ReadWriteApprovalSecretsValidationCheckpoints
Roles
QA AnalystExecutor
Comes out of here
Evidence of the run
Bug / Defect / Improvement classified
Jira transitions
US: Ready For QA → In Test (Start Testing)
US: In Test → BLOCKED (defect reported)
Steps it is made of · 1Half of the step: ejecución
Step 3: Early Exploratory Testing
Early-GameTMLC 2nd Stage
Validate the US in two moves and in this order: first the Go/No-Go smoke test, which validates the ENVIRONMENT, and only then the Trifuerza exploration (UI · API · DB), which validates the FEATURE by running what the ATP and the FTP planned. Skipping the smoke test is the classic anti-pattern. Findings are reported on the spot: defect reporting is not a separate step, it lives inside the exploration. Before filing, the finding must be CLASSIFIED (Bug, Defect or Improvement), and the classification follows the life stage of the FEATURE, not the environment where it showed up. Every finding is documented with clear, reproducible information.
Deliverable
US approved or bugs reported in Jira, with the story's ATR (Acceptance Test Results) as the execution record. The Feature altitude has no execution of its own: the FTP gets consumed as context and produces no results.
Skills
Bug / Defect / Improvement classificationBug report writingSeverity/Priority classificationEvidence collection
Tools
Agentic harness (Claude Code, OpenCode, Codex)MCPs (OpenAPI, database, tracker, browser)API client (Postman, Bruno, curl)Jira (or equivalent tracker)
Boilerplate
Execution + Reporting/sprint-testing
Inside the sprint
Reporting
Early-GameL2 · Early DetectionTMLC 2nd
The run becomes a record: the ATR gets filled in, the QA comment tells what happened, and the links get verified in their own direction. Without that, the story doesn't get signed off.
The contract, the guardrails, the deliverables and the breakdown1 step
Agentic contract
The agent does
Fills in the ATR with the result per case, writes the QA comment, resolves the cascade's links and notes the regression follow-up.
The person signs
Signs the transition: the story's sign-off or the defect report. The signature is always the person's.
Evidence required
ATR as a Test Execution item, published QA comment and traceability verified in direction (it's not enough for the link to merely exist).
Autonomy
2 on a 0-5 scale
Separate verifier
not needed
Owning skill
sprint-testing
Guardrails that govern it
ReadWriteApprovalValidationTraceabilityCheckpoints
Roles
QA AnalystExecutor
Comes out of here
Filled ATR
QA comment
Jira transitions
US: In Test → QA Approved (QA Sign-Off)
Bug / Defect / Improvement: Ready For QA → Closed (ReTest Passed)
Steps it is made of · 1Half of the step: registro
Step 3: Early Exploratory Testing
Early-GameTMLC 2nd Stage
Validate the US in two moves and in this order: first the Go/No-Go smoke test, which validates the ENVIRONMENT, and only then the Trifuerza exploration (UI · API · DB), which validates the FEATURE by running what the ATP and the FTP planned. Skipping the smoke test is the classic anti-pattern. Findings are reported on the spot: defect reporting is not a separate step, it lives inside the exploration. Before filing, the finding must be CLASSIFIED (Bug, Defect or Improvement), and the classification follows the life stage of the FEATURE, not the environment where it showed up. Every finding is documented with clear, reproducible information.
Deliverable
US approved or bugs reported in Jira, with the story's ATR (Acceptance Test Results) as the execution record. The Feature altitude has no execution of its own: the FTP gets consumed as context and produces no results.
Skills
Bug / Defect / Improvement classificationBug report writingSeverity/Priority classificationEvidence collection
Tools
Agentic harness (Claude Code, OpenCode, Codex)MCPs (OpenAPI, database, tracker, browser)API client (Postman, Bruno, curl)Jira (or equivalent tracker)
Boilerplate
Execution + Reporting/sprint-testing
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
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
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
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

Steps 1-4

The 4 steps of Early-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

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

Step 1: Requirements Analysis
Early-GameTMLC 1st Stage
Understand the requirements: the Epic analysis and each Story's analysis happen BEFORE the sprint, and the story's ATP comes out of that, living pre-sprint ONLY in the `acceptance_test_plan` field (no Test Plan item yet). The FTP item is not born here: it is created or refined inside /sprint-testing, when the Epic context is loaded, already in sprint. The FTP is a living document: written once per epic and refined throughout it, because the team learns with every story it delivers. And a story is never analysed alone: its siblings in the same epic are analysed too (the ones already built, the ones in development and the ones merely defined), because that full picture of the feature is what makes the ATPs better.
Deliverable
ATP (Acceptance Test Plan) per Story, pre-sprint in the story's field + FTP (Feature Test Plan) per Epic, whose item gets created when the sprint opens
Boilerplate
Shift-Left QA + Planning/shift-left-testing + /sprint-testing
Tools
- 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.
- Confluence (or team wiki)CLIENT-CONTROLLEDThe environment brings it
  Wherever the client's documentation lives. QA artifacts live in the tracker, not in the wiki.
1. [1a] Epic analysis → FTP (macro context; living document, refined throughout the whole epic)
2. [1b] Analysis of the epic's sibling stories (delivered, in development and merely defined) → full picture of the feature
3. [1c] Story analysis → ATP (per Story, citing the FTP instead of re-deriving it)
Jira transition
USBacklogShift-Left QAAnalyzeEstimationEstimate
Subtask [QA] Shift-Left ReviewACTIVECloseComplete
Quality attributes by risk · 8
Each story's ATP declares which attributes apply and why, based on the story's risk: impact, probability, data it touches and exposed surface. What risk leaves out doesn't get tested in that story. The FTP can raise an attribute to the whole feature. Functionality always applies.
Functionality
Always (it is the AC).
Security
Touches authentication, roles, sensitive data, or receives external input.
Performance
Adds listings, queries, or heavy calculations, or touches a flow with an SLO.
Accessibility
Creates or changes public UI.
Resilience
Depends on external integrations, queues, or retries.
Data integrity
Writes, migrates, or transforms persisted data.
Compatibility
Runs across multiple browsers, devices, or API versions.
Privacy
Processes personal or regulated data.
Step 2: Development and Implementation
Early-GameParallel WorkSDLC event
Build and deploy the US to a staging environment while QA prepares the strategy
Deliverable
Functional environment for testing
Boilerplate
no stage: it's the development team's work
Tools
- 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.
Note
Not a direct QA task
Step 3: Early Exploratory Testing
Early-GameTMLC 2nd Stage
Validate the US in two moves and in this order: first the Go/No-Go smoke test, which validates the ENVIRONMENT, and only then the Trifuerza exploration (UI · API · DB), which validates the FEATURE by running what the ATP and the FTP planned. Skipping the smoke test is the classic anti-pattern. Findings are reported on the spot: defect reporting is not a separate step, it lives inside the exploration. Before filing, the finding must be CLASSIFIED (Bug, Defect or Improvement), and the classification follows the life stage of the FEATURE, not the environment where it showed up. Every finding is documented with clear, reproducible information.
Deliverable
US approved or bugs reported in Jira, with the story's ATR (Acceptance Test Results) as the execution record. The Feature altitude has no execution of its own: the FTP gets consumed as context and produces no results.
Skills
Bug / Defect / Improvement classificationBug report writingSeverity/Priority classificationEvidence collection
Boilerplate
Execution + Reporting/sprint-testing
Tools
- 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.
- MCPs (OpenAPI, database, tracker, browser)ADAPTABLEImplementation standard
  They're how the agent reads schema, data and tracker; which ones connect depends on the client's stack. Boilerplate rule: the MCP reads, it never executes (the API is exercised with curl and the CLI's token), and a configured MCP stays red until it actually responds.
- API client (Postman, Bruno, curl)ADAPTABLEImplementation standard
  Exploration of the API leg of the Trifuerza. The boilerplate uses OpenAPI MCP + curl; any equivalent client works.
- 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
USReady For QAIn TestStart TestingQA ApprovedQA Sign-Off
Bug / Defect / Improvement (share the UPEX BUG/DEFECT LIFE CYCLE workflow)OpenIn Progressstart fixingIn ReviewPull RequestReady For QAFixed & DeployedClosedReTest Passed
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
Boilerplate
Documentation, Prioritize phase (ROI)/test-documentation
Tools
- 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.
Candidate
Automated regression: moves to the TALC and gets implemented in code with Playwright
Manual
Manual regression: terminal, doesn't get automated
Deferred
Outside the regression: gets logged in the prioritization report, no TC gets created in the TMS
Note
Candidate, MANUAL and Deferred are ROI verdicts. All three also exist as Jira states (Candidate and MANUAL on the TC, Deferred on the Bug), but the verdict and the state are not the same even though they share a name (see iql.jiraStates).

Shift-Left

The plan exists before the sprint, and not as a ticket

The Early-Game starts before the sprint opens. There is already a plan per story at that point, but no item yet: the ATP lives only in a field on the story. It's a deliberate decision, and it has a direct consequence on how the board looks.

A story that dies in the backlog shouldn't leave orphaned artifacts

If the plan were born as an item at analysis time, every discarded story would leave a Test Plan hanging with nothing to test. That's why, before the sprint, the content goes into the {{jira.acceptance_test_plan}} field on the story and creates no ticket at all.

The item is only born in the first stage of the sprint, from that same field. There is no intermediate "ATP DRAFT" state: that identity does not exist. What marks the earlier step is labels, not a half-built artifact.

The FTP plays a different role: it belongs to the epic's altitude and is a living document, refined as the epic moves forward. The ATP cites it instead of re-deriving it, which is why a story's analysis starts by looking at its siblings.

How it shows up on the board

Labelshift-left-reviewed
Labelshift-left-{YYYY-MM-DD}
Subtask[QA] Shift-Left Review

ATP at a glance

Full name: Acceptance Test Plan
Where it lives: before the sprint, only the {{jira.acceptance_test_plan}} field on the story; during the sprint, a Test Plan item
How many: 1 per story
Title: ATP: {STORY-KEY}: {story title}

The order matters

You execute, then prioritize, and only then document

The intuitive order would be the opposite: write the cases first, then run them. The IQL inverts it because the persistent regression set is decided by return, and that return is only known after testing. The sequence crosses the phase boundary: it starts in the Early-Game and ends already inside the Mid-Game.

Step 3 · Early-Game
Early Exploratory Testing
Validate the US in two moves and in this order: first the Go/No-Go smoke test, which validates the ENVIRONMENT, and only then the Trifuerza exploration (UI · API · DB), which validates the FEATURE by running what the ATP and the FTP planned. Skipping the smoke test is the classic anti-pattern. Findings are reported on the spot: defect reporting is not a separate step, it lives inside the exploration. Before filing, the finding must be CLASSIFIED (Bug, Defect or Improvement), and the classification follows the life stage of the FEATURE, not the environment where it showed up. Every finding is documented with clear, reproducible information.
Step 4 · Early-Game
Risk-Based Prioritisation
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.
Step 5 · Mid-Game
Asynchronous Test Case Documentation
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.

Real workflow

The story cycle starts here

Early-Game takes the story from the backlog and leaves it either approved or with bugs reported. This is the full cycle in the real Jira instance, with the exact status names: the phase's four steps fall within its first stretch.

Jira · UPEX Feature (US) Workflow

User story lifecycle

The thirteen states of a story in Jira, grouped into the four stages it goes through: refinement, development, QA, and close. A defect found in testing blocks it and sends it back to development.

View full screen

Integrated approaches

What lens Early-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.

Shift-Left
Move quality activities earlier in the cycle, before there is code to break.
BDD
Collaborative specification in Given-When-Then scenarios, written with the team, not for the team.
Risk-Based
Prioritize by impact and likelihood of failure, instead of trying to cover everything equally.

Tools

What you work with in Early-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.

Jira (or equivalent tracker)
The board where the story lives, its QA subtasks, and the field where the ATP is stored.
Confluence (or team wiki)
The team's documentation: the epic context the analysis comes from.
API client (Postman, Bruno, curl)
Collections to walk through the API before there is a screen to test.
Agentic harness (Claude Code, OpenCode, Codex)
The agent that supports the analysis: reading the epic, cross-checking sibling stories, drafting scenarios.

Navigate the whole IQL

The three phases of the Integrated Quality Lifecycle, with their steps, their leading role and their underlying question.

IQL Methodology

Full view of the Integrated Quality Lifecycle

See the whole IQL

CURRENT

Early-Game

Phase 1 · Prevention · Steps 1-4

«Let's build it right from the start»

QA Analyst

You are here

Mid-Game

Phase 2 · Detection · Steps 5-9

«Does the software meet the requirements?»

QA Automation Engineer

Go to Mid-Game

Late-Game

Phase 3 · Observation · Steps 10-15

«How does it behave in the real world?»

QA + DevOps

Go to Late-Game

Early-Game

Mid-Game

Late-Game

Master the Early-Game

Become the QA Analyst that companies need: the one who works quality starting from prevention and knows how to answer «Let's build it right from the start».

See available courses

See the whole IQL Implement it with UPEX

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

Early-Game: where you are inside the IQL

Early-Game

Mid-Game

Late-Game

The stages of this phase

The 4 steps of Early-Game

Early-GameSteps 1-4 · Prevention · QA Analyst4 steps

The plan exists before the sprint, and not as a ticket

A story that dies in the backlog shouldn't leave orphaned artifacts

You execute, then prioritize, and only then document

Early Exploratory Testing

Risk-Based Prioritisation

Asynchronous Test Case Documentation

The story cycle starts here

User story lifecycle

What lens Early-Game works with

Shift-Left

BDD

Risk-Based

What you work with in Early-Game

Jira (or equivalent tracker)

Confluence (or team wiki)

API client (Postman, Bruno, curl)

Agentic harness (Claude Code, OpenCode, Codex)

Navigate the whole IQL

IQL Methodology

Early-Game

Mid-Game

Late-Game

Master the Early-Game