Integral Methodology

Integrated Quality Lifecycle

The quality methodology at UPEX: a single line of work from the requirement to the operation, instead of the STLC as a separate phase at the end.

The three phases

Early-GamePreventionMid-GameDetectionLate-GameObservation
See the whole loop
8stages
what gets executed and gated
15steps
the breakdown of the stages
5cycles
TMLC · TALC · SDC · BLC · PLC
4altitudes
Product · Feature · Sprint · Story
~$

// In the ecosystem

IQL is the methodology behind the whole ecosystem

Galaxy teaches it, the services division implements it, and Satellite connects people trained in it.

  1. 01 · PreventionStages Shift-Left · Planning

    Stories with verifiable criteria and an acceptance plan per story before the sprint starts.

  2. 02 · Early DetectionStages Execution · Reporting · Documentation

    Feedback to the developer before the pull request, with real evidence and bugs prioritized by risk.

  3. 03 · Continuous DetectionStages Documentation · Automation · Regression

    Reliable regression in CI: only what proved its value gets documented and automated, and it runs on every pull request.

  4. 04 · Production ObservationStages Observation

    Production feeds the strategy: real metrics decide what to observe, what to test and what to improve in the next cycle.

What do you want to do with the IQL?

02Four blocks

The IQL in four blocks

Four blocks, each with the problem it tackles and the outcome it leaves. They are the same four maturity levels used later to decide how far to go.

  1. Block 01

    Prevention

    Problem
    The most expensive defects are born in ambiguous stories, before a single line of code exists.
    Outcome
    Stories with verifiable criteria and an acceptance plan per story before the sprint starts.

  2. Block 02

    Early Detection

    Problem
    A bug found after the merge costs the whole team rework.
    Outcome
    Feedback to the developer before the pull request, with real evidence and bugs prioritized by risk.

    ExecutionReportingDocumentation

    Covers: Steps 3, 4Early-Game

    See Early-Game

  3. Block 03

    Continuous Detection

    Problem
    Case repositories nobody maintains and automated suites nobody trusts.
    Outcome
    Reliable regression in CI: only what proved its value gets documented and automated, and it runs on every pull request.

    DocumentationAutomationRegression

    Covers: Steps 5-10Mid-GameLate-Game

    See Mid-Game

  4. Block 04

    Production Observation

    Problem
    What happens in production doesn't make it back to the backlog.
    Outcome
    Production feeds the strategy: real metrics decide what to observe, what to test and what to improve in the next cycle.

How far to go

The IQL defines what to observe and what to improve; the maturity level defines how far to implement Late Game; the concrete targets are defined by each product.

03The loop

The whole IQL, at a glance

The cycle is a loop, not a row. Production feeds the next cycle's analysis through a named mechanism, the error budget and the escape rate, not through good intentions: if no number loops back to step 1, the last step is an ending, not a return.

Integrated Quality Lifecycle

The IQL loop: 8 stages in 4 moments

The method's stages grouped by moment of the cycle, the SDLC events around them, and the three loop-back arrows a linear model can't draw: the defect, the NO-GO and production feeding the next analysis.

The Integrated Quality Lifecycle loop, stage by stageThe method's eight stages spread across four moments: before the sprint, inside the sprint, at the close and release, and in production. Around them, the four development-cycle events that produce artifacts without being stages. Three arrows loop back: the defect reopens execution, the regression NO-GO returns the release to automation, and the production signals feed the next cycle's analysis.BEFORE THE SPRINTINSIDE THE SPRINTCLOSE AND RELEASEPRODUCTIONdefect → fix → retestNO-GOchange failure rate · escape rate → Shift-LeftMTPSTPDevelopment andImplementationSTRShift-LeftL1 · shift-left-testingPlanningL1 · sprint-testingExecutionL2 · sprint-testingReportingL2 · sprint-testingDocumentationL3 · test-documentationAutomationL3 · test-automationRegressionL3 · regression-testingObservationL4LEGENDIQL stage (owning skill + gate)SDLC event (not a QA activity)loop within the cycleproduction feeds the next cycle
View full screen

  1. Before the sprint

    Shift-Left

    Early-Game

  2. Inside the sprint

    Planning · Execution · Reporting

    Early-Game

  3. Close and release

    Documentation · Automation · Regression

    Early-Game · Mid-Game · Late-Game

  4. Production

    Observation

    Late-Game

04Principles

Principles and invariants

Principles and invariants of the IQL: what doesn't change even when the stack, the tracker or the client changes. Each one points to the steps that carry it out.

  1. The choreography is the contributionchoreography

    What the IQL contributes isn't inventing Shift-Left, Risk-Based, CI or observability: it's the choreography. Understand → plan → explore → learn → prioritize by risk and ROI → document only what deserves to live → automate what deserves automation → integrate it into CI → observe production → feed the next cycle.

  2. Execute first, document laterexecute-first-document-later

    Execute first, document later doesn't mean testing without a plan: before the sprint, the analysis, the FTP and the ATP already exist. Testing happens against that plan, and only with real evidence does the team decide which scenarios deserve to become persistent regression cases. That way, case repositories written in advance that nobody maintains never get born.

  3. Everything gets prioritized by riskrisk-based

    Everything gets prioritized by risk: which stories get explored first, which quality attributes apply to each one, and which cases get documented. Nothing enters the suite out of habit.

  4. A case gets persisted for its ROIroi-regression

    A case gets persisted and automated only if its regression value was demonstrated; the ROI verdict (Candidate, MANUAL, Deferred) gets decided in step 4 and stamped in step 6. The suite gets maintained under the same criterion.

  5. Manual feeds automatedtmlc-talc-seam

    The QA Analyst's work doesn't end in a folder of cases: it produces candidates that feed directly into the QA Automation Engineer's cycle. That seam between the TMLC and the TALC is the I in Integrated.

  6. Every step leaves an artifact and a gategates-and-artifacts

    Every step leaves a named artifact and a transition in the tracker: MTP, FTP, STP/STR, ATP/ATS/ATR and the ATC. The gates are the transitions; without an artifact there is no next step.

  7. Step 2 syncs with the SDLCsdlc-sync-point

    Step 2 isn't a QA activity: it's the sync point with the SDLC, the period when development builds while QA works in parallel. It's counted among the 15 so the cycle stays readable, and it gets drawn differently.

  8. The IQL doesn't replace the STLC: it absorbs itstlc-absorbed

    The IQL doesn't replace the STLC: it absorbs it. It's a Software Quality Engineering operating model that integrates the STLC's activities within the SDLC and extends them all the way to production.

  9. Maturity sets how farmaturity-bounded

    The IQL defines what to observe and what to improve; the maturity level defines how far to implement Late Game; the concrete targets are defined by each product.

  10. The agent executes, the person decidesagent-executes

    Agent executes. Evidence proves. Human owns the decision.

    The agent executes the skills, the evidence proves every conclusion, and the person decides: what gets prioritized, what gets automated, what gets approved.

  11. Whoever verifies is not whoever executedverifier-not-executor

    Whoever verifies is not whoever executed. The work an agent produces gets reviewed by another, in a clean context and against the original artifact: the ROI verdicts against the ATR, the code against the approved plan. An executor that audits itself only confirms its own reading.

  12. The agent gets measured tooagent-is-measured

    The agent gets measured too. Every stage has its golden set (a reference ATP, a reference ROI verdict, a reference failure classification) and its evals: without that, "Evidence proves" proves the product and not the executor, and there is no way to justify raising its autonomy.

  13. It's a loop, not a rowloop-not-sequence

    The cycle is a loop, not a row. Production feeds the next cycle's analysis through a named mechanism, the error budget and the escape rate, not through good intentions: if no number loops back to step 1, the last step is an ending, not a return.

The three seams of the I

The I in Integrated is three seams, in this order: the one that makes the method agentic, the one that stitches the two cycles together, and the one that fits the STLC inside the SDLC.

  1. 01

    Human ↔ agent ↔ evidence

    The agent executes, the evidence proves, and the person decides. The three pieces are stitched together in every stage by its contract: what the agent does, what the person signs, and what evidence the gate demands. Without this seam the method would have agents, but it wouldn't be agentic.

  2. 02

    TMLC ↔ TALC

    The QA Analyst's work doesn't end in a folder of cases: it produces candidates that feed directly into the QA Automation Engineer's cycle, and the ROI gate decides which ones make it through. It's the method's original seam.

  3. 03

    STLC inside the SDLC

    The IQL doesn't replace the STLC: it absorbs it, integrates its activities within the SDLC and extends them all the way to production. Step 2 is where the two lines sync up.

05The stages

The 8 stages of the IQL

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. Before the sprint

    • Shift-Left

  2. Inside the sprint

    • Planning
    • Execution
    • Reporting

  3. Close and release

    • Documentation
    • Automation
    • Regression

  4. Production

    • Observation

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

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

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

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

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

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

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

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

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

  6. 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)

  7. Close and release

    Regression

    Late-GameL3 · Continuous Detection

    The suite runs and every failure gets classified: none stays as "it broke". From there comes the release verdict and the sprint's STR.

    The contract, the guardrails, the deliverables and the breakdown1 step

    Agentic contract

    The agent does
    Runs the suite, classifies every failure (REGRESSION, FLAKY, KNOWN, ENVIRONMENT or NEW TEST), calculates pass-rate and trend without truncating, proposes GO, CAUTION or NO-GO and builds the STR.
    The person signs
    Decides every CAUTION. And never lets the sprint number get invented: if it's missing, it gets asked.
    Evidence required
    Run report with the classification of every failure, a history of at least five runs to be able to call something FLAKY (with fewer, it's declared insufficient history) and the STR linked to the STP.

    Autonomy

    3 on a 0-5 scale

    Separate verifier

    not needed

    Owning skill
    regression-testing
    Guardrails that govern it
    ReadApprovalSecretsValidationTraceabilityCheckpoints
    Roles
    QA Automation EngineerQA LeadExecutorGuardian

    Comes out of here

    • STR
    • Regression report with each failure classified
    • GO / CAUTION / NO-GO verdict
    Steps it is made of · 1

    1. Step 10: Continuous Maintenance

      Late-GameProduction Ops

      Keep the application stable for release and keep it that way after deployment. The sprint's regression is planned in the STP and its execution is recorded in the STR.

      Deliverable

      US deployed to production with confidence + the sprint's STR (Sprint Test Results)

      Activities
      Regression suiteSmoke testingTest maintenance
      Tools
      PlaywrightXrayGitHub Actions (or equivalent CI)
      Boilerplate
      Regression/regression-testing

  8. Production

    Observation

    Late-GameL4 · Production ObservationPanorama

    Production as the source of the strategy. It doesn't have a skill yet: its operating unit is the agentic routine, and that's why the stage is declared panorama until one exists.

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

    Agentic contract

    The agent does
    Watches the signals the product already emits (service objectives, error budget, real user monitoring, canary cohorts), opens backlog items when a signal falls out of range and feeds what it learned back into the next cycle's analysis.
    The person signs
    Defines the service objectives and the error budget policy, and decides when a release gets stopped. No threshold gets inherited from someone else's benchmark.
    Evidence required
    The product's own metrics against the targets that product declared; industry benchmarks count as a reference, never as a target.

    Autonomy

    3 on a 0-5 scale

    Separate verifier

    not applicable yet

    Owning skill
    no skill yet: the operating unit is the agentic routine
    Guardrails that govern it
    ReadApprovalSecretsValidationCheckpoints
    Roles
    QA LeadGuardian

    Comes out of here

    • Backlog items opened from production
    • Product metrics against its own targets
    Steps it is made of · 5

    1. Step 11: Canary Release Monitoring

      Late-GameShift-RightPanorama

      Roll new functionality out to a small percentage of users to monitor behaviour

      Deliverable

      Safe validation with minimal risk

      Tools
      Sentry / Grafana / DatadogProgressive delivery / feature flags
      Boilerplate
      no stage: the boilerplate doesn't cover Shift-Right

    2. Step 12: A/B Testing

      Late-GameExperimentationPanorama

      Test different versions of a feature to optimise the user experience

      Deliverable

      Decisions based on real user data

      Tools
      Progressive delivery / feature flags
      Boilerplate
      no stage: the boilerplate doesn't cover Shift-Right

    3. Step 13: Real User Monitoring (RUM)

      Late-GameObservabilityPanorama

      Monitor the real experience of users in production to spot performance problems

      Deliverable

      Full visibility into real UX

      Metrics
      Core Web VitalsMTTDMTTR
      Tools
      k6Sentry / Grafana / DatadogUptimeRobot (or equivalent uptime monitor)
      Boilerplate
      no stage: the boilerplate doesn't cover Shift-Right

    4. Step 14: Chaos Engineering

      Late-GameResiliencePanorama

      Introduce controlled failures in production to validate the resilience of the system

      Deliverable

      Resilient system with validated recovery

      Tools
      Chaos tools (Gremlin, Litmus, custom scripts)
      Boilerplate
      no stage: the boilerplate doesn't cover Shift-Right

    5. Step 15: Feedback Loop

      Late-GameContinuous LearningPanorama

      Analyse user feedback and production metrics to feed the next Early-Game cycle

      Deliverable

      Continuous product improvement

      Tools
      Jira (or equivalent tracker)Slack / TeamsSentry / Grafana / Datadog
      Boilerplate
      no stage: the boilerplate doesn't cover Shift-Right

See Early-Game in detailSee Mid-Game in detailSee Late-Game in detail

06Jira

The IQL in Jira, no metaphors

The real states of the workflow. Bug, Defect and Improvement are three different work types that SHARE the UPEX BUG/DEFECT LIFE CYCLE workflow: Bug if the feature is already live above Staging, Defect if it is still pre-release (the normal outcome of sprint testing), and Improvement if the behavior does not violate any acceptance criterion. Classifying before filing is mandatory. Watch for three names that are ambiguous by design: Candidate and MANUAL are both TC states and step 4 ROI verdicts; Deferred is both an ROI verdict and a terminal Bug state. The verdict and the state are not the same thing even though they share a name.

User Story

13 states
  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

Branches

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

Bug

11 states
  1. Open
  2. In Progressstart fixing
  3. In ReviewPull Request
  4. Ready For QAFixed & Deployed
  5. ClosedReTest Passed

Branches

  • 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 states
  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

Branches

  • READY → MANUAL (for manual)
  • Candidate → MANUAL (manual execution)
  • MANUAL → Candidate (for automation)
  • AUTOMATED → Pull Request (Fix)
  • DEPRECATED → Draft (recover)

Source: `.agents/jira-workflows.json` from the `agentic-qa-boilerplate` boilerplate (the instance's real configuration, with state and transition ids). Where a SKILL.md contradicts that JSON, the JSON wins.

Where each artifact lives

The plan, the set and the run aren't loose documents in a folder: they're linked issues on the story itself, and they show up where Jira really puts them, in the linked issues block, below the acceptance criteria. This is what a story in test looks like, with its ATP, its ATS and its ATR named with the ladder's grammar.

The seven tabs are navigable: the two boards with their grouped columns, the story with its Xray coverage panel, and the four cards for the plan, the run, the case and the defect, seen from the inside. The coverage panel's toggle switches off the ATS link and shows what happens then.

JJira · UPEX Coin Sandbox

Sprint#7 · UPEX Coin Sandbox: stories and defects

To start 2

Backlog · Open

Notify the deposit by email

GX-16
Backlog

The balance doesn't update when the deposit has decimals

GX-58
Open

Refinement 2

Shift-Left QA · Estimation

Export movements to CSV

GX-15
Shift-Left QA

Define daily withdrawal limits

GX-19
Estimation

Development 3

Ready For Dev · In Progress · In Review

Edit the wallet alias

GX-17
Ready For Dev

Withdraw balance to a bank account

GX-14
In Progress

The history loses the filter when paginating

GX-20
In Review

Testing 2

Ready For QA · In Test

Confirm the deposit with two-factor

GX-13
Ready For QA

Register a deposit in my wallet

GX-12
In Test

Close 2

QA Approved · Ready For Release · Deployed to Production · Closed

View the movement history

GX-9
QA Approved

Sign in with email

GX-11
Deployed to Production

Diverted 2

BLOCKED · ABORTED · Deferred · Duplicated · Enhancement · Cannot Reproduce · REJECTED

Lock the wallet after failed attempts

GX-18
BLOCKED

The amount accepts more than two decimals

GX-21
Deferred

07Modalities

Two modalities, the same method

When a Test Case becomes a TMS work item. It changes with the tool, not with the methodology. The stages named here, Planning and Documentation, are stages of the method, not IQL steps: Documentation contains steps 4 and 5. Since stages are named instead of numbered, the collision that used to require this clarification no longer exists.

UPEX's instance works in Jira + Xray (jira-xray). jira-native is the factory default: it's the fallback when Xray isn't configured (`tms_cli: null`). It isn't a declaration from the boilerplate: the modality gets resolved by probing.

Native Jira

jira-nativeDefault

In Planning only outlines come out inside the ATP. A native Test issue already IS documentation, so it waits for the 'regression-worthy' gate in Documentation, which runs after executing and reporting.

Steps where the work changes

  • 4Risk-Based Prioritisation
  • 5Asynchronous Test Case Documentation

Jira + Xray

jira-xray

Cases get created and run in Planning, because in Xray the Test issue is the unit of execution. In Documentation the regression-worthy ones get promoted to the regression Test Plan and the rest stays as a sprint artifact.

Steps where the work changes

  • 3Early Exploratory Testing
  • 4Risk-Based Prioritisation
  • 5Asynchronous Test Case Documentation

08Artifacts

The artifact ladder

UPEX's planning ladder: product → feature → sprint → story. The first token of the name encodes the altitude.

The axiom

Plan and results are distinguished by the first token: P = Plan, R = Results

P = PlanMTP · FTP · STP · ATPR = ResultsSTR · ATR

The grammar of the name

{ACRONYM}: {scope-id}: {descriptor}

A name that follows the grammar reads without opening the issue: the acronym says the altitude and whether it is a plan or a run, the scope says what it refers to, and the descriptor says what it is about.

Test Management

The coverage cascade of a Test Case

The three paths by which a test case resolves up to its story, which one fills the coverage panel and which one reads as uncovered even though the link exists.

The coverage cascade of a Test CaseThe three rungs by which a test case resolves up to its user story. The first one goes through the Acceptance Test Set and is the only one that fills the coverage panel. The second one goes through the Acceptance Test Plan and the story reads as uncovered even though the link exists. The third one links the case directly to the story and is a valid last resort. A case with none of those edges is left orphaned. It also distinguishes the two layers at play: Xray's internal membership and Jira's issue links.RESOLUTION CASCADE · IT DROPS ONE RUNG ONLY WHEN THE PREVIOUS ONE DOESN'T EXISTXRAY MEMBERSHIPISSUE LINK · TESTS1TCTest CaseATSAcceptance Test SetStoryis tested byCOVERAGEFills the panelXRAY MEMBERSHIPISSUE LINK · TESTS2TCTest CaseATPAcceptance Test PlanStoryis tested byADMINISTRATIVE TRACEABILITYUNCOVERED · 0 testsDIRECT ISSUE LINK3TCTest CaseStoryis tested byCOVERAGEValid last resortNO EDGE—TCTest CaseStoryuncoveredORPHANOutside traceabilityJIRA-NATIVE MODALITYWithout an Xray layer there's no GraphQL membership: there, membership is expressed instead as TC-to-ATS issue links.And if the instance has no Test Set work type, there's no ATS: the cascade falls straight to the third rung.LEGENDXray membership (GraphQL), not an issue linkJira issue link, test slugThe story is the inward side: reversing the edge gives zero coverage
View full screen

09Architecture

Komponent Action Test Architecture

The agentic architecture of the IQL, isomorphic to KATA

The IQL's agentic architecture, isomorphic to KATA. The Agentic Quality Engineer operates two architectures with the same shape: one over the product under test and another over its own agent system, and audits both with the same rigor. The isomorphism wasn't designed: it was verified on disk, correspondence by correspondence.

The formula

KATA (Komponent Action Test Architecture) is the name of the architecture, not the inventory of its layers. The real layers are four — TestContext, Base (ApiBase / UiBase), Domain components and Fixtures — plus an optional intermediate layer, Steps, for reusable precondition chains. The dependency goes in one direction only: each layer uses only the ones below it, never the other way around. Test files consume the Fixtures: they aren't a layer.

Decision level: RECOMMENDEDThe traceability decorator: REQUIRED

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

10The cycles

The cycles that run inside

TMLC and TALC are UPEX's pedagogical names, not the boilerplate's live pipeline: there the work is organized into the method's stages, each with its own owning skill. Map: TMLC 1st ↔ Shift-Left and Planning · TMLC 2nd ↔ Execution and Reporting · TMLC 3rd and 4th ↔ Documentation (Prioritize and Document phases) · TALC 1st ↔ the Documentation/Automation boundary · TALC 2nd, 3rd and 4th ↔ Automation. Added to those two pedagogical names are the cycles that ARE real state machines of the instance: the SDC (the story's journey) and the BLC (the finding's), read from .agents/jira-workflows.json of the agentic-qa-boilerplate boilerplate (the instance's real configuration, synced from Jira Cloud); and the PLC, the production cycle, declared empty until the skill that runs it exists.

TMLC

Test Manual Life Cycle

The cycle stages, and which step they correspond to4
  1. 1st StageAnalysisstep 1 · Requirements Analysis
  2. 2nd StageExplorationstep 3 · Early Exploratory Testing
  3. 3rd StagePrioritizationstep 4 · Risk-Based Prioritisation
  4. 4th StageDocumentationstep 5 · Asynchronous Test Case Documentation

TALC

Test Automation Life Cycle

The cycle stages, and which step they correspond to4
  1. 1st StageAssessmentstep 6 · Assessing TCs for Automation
  2. 2nd StageAutomationstep 7 · Automating the Candidates
  3. 3rd StageCI Verificationstep 8 · Verifying the Suite in CI
  4. 4th StagePR Reviewstep 9 · Pull Request Review

SDC

Story Development Cycle · UPEX Feature (US) Workflow

The story's journey end to end. The IQL doesn't invent it: it follows it. The Shift-Left stage lives between Backlog and Estimation, Execution and Reporting between In Test and QA Approved, and the BLOCKED branch is the return path the linear model doesn't express.

States, transitions and where they were read from13 / 27
States
13
Transitions
27

Applies tostory

Read fromagentic-qa-boilerplate boilerplate's .agents/jira-workflows.json (the instance's real configuration, synced from Jira Cloud)

BLC

Bug Life Cycle · UPEX BUG/DEFECT LIFE CYCLE

The finding's journey, shared by the three work types: Bug if the feature is already live above Staging, Defect if it's still pre-release, and Improvement if it doesn't violate any acceptance criterion. Classifying before filing is mandatory.

States, transitions and where they were read from11 / 15
States
11
Transitions
15

Applies tobugdefectimprovement

Read fromagentic-qa-boilerplate boilerplate's .agents/jira-workflows.json (the instance's real configuration, synced from Jira Cloud)

PLC

Production Lifecycle

The cycle of what happens after release: signal, item, decision, return to analysis. It's declared here so the model doesn't pretend it doesn't exist, and it's declared empty so nobody sells it before the skill that runs it exists. Its stage is Observation.

Declared and still empty

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

The collaboration model: Analyst + Automation Engineer

The IQL defines a symbiosis between two specialized roles that work asynchronously and in parallel.

11The STLC inside

What happens to the STLC inside the IQL

The classic linear STLC treats testing as a stage with a start and an end: you plan, design the cases, execute them and close the cycle. The IQL doesn't erase those activities, it absorbs them: it spreads them across the whole development cycle and extends them all the way to production.

Classic STLC · IQL

The inversion: execute first, document after

Three lanes over the same SDLC timeline. The classic STLC starts once the code already exists; the IQL starts at the requirement and inverts the order of the two steps that define the method.

The classic STLC against the IQL over the SDLC axisThree lanes over the same software life cycle timeline: on top the six SDLC phases, in the middle the classic STLC, which has no activity before coding, and below the Integrated Quality Lifecycle spread across the whole cycle. Two connectors that cross show the inversion: the IQL runs exploratory testing in its step 3 where the STLC runs its step 5, and documents the test cases in its step 5, after execution, instead of writing them beforehand the way the STLC's step 3 does. Below, the Integrated seam joins the analysis layer with the automation layer and with the production steps. Two thinner pink connectors close the arc on the right: the SDLC's deployment phase is where the IQL's step 10 is born, and maintenance is where its steps 11 to 15 live.SDLCsoftwarelife cycleSTLCtraditionalsteps 01-06IQLintegratedqualitylifecycleEARLYMIDTMLC · ANALYST LAYER② SHIFT-LEFT③ LOCALHOST SUPPORT① EXECUTE FIRST① DOCUMENT AFTER→ STEP 10→ STEPS 11-15RequirementsDesignCodingTestingDeploymentMaintenanceThe STLC startsonce the codealready exists. Before that, nothing.01RequirementAnalysis02TestPlanning03①Test CaseDevelopment04TestEnvironmentSetup05①TestExecution06Test CycleClosure01②RequirementsAnalysis02③Development andImplementation03④EarlyExploratoryTesting04Risk-BasedPrioritisation05①AsynchronousTest CaseDocumentation④ plan + whatever comes upI · INTEGRATED⑥TMLC → TALC⑤ With the execution already doneit's known what deserves regressionand what deserves automation.TALC · STEPS 6-9automation layer⑤06 · Assessment of TCs for Automation07 · Automation with Playwright + KATA Design Pattern08 · Verification of ATCs in CI09 · Pull Request ReviewLATE-GAME · STEPS 10-15production as a phase of the method10 · Continuous Maintenance11 · Canary Release Monitoring12 · A/B Testing13 · Real User Monitoring14 · Chaos Engineering15 · Feedback LoopLEGENDSDLCClassic STLCEarly-Game · steps 1-4Mid-Game · steps 5-9Late-Game · steps 10-15optional
View full screen

«The IQL doesn't replace the STLC: it absorbs it. It's a Software Quality Engineering operating model that integrates the STLC's activities within the SDLC and extends them all the way to production.»

UPEX's IQL methodology

The 8 approaches the IQL integrates

None of these is a UPEX invention. What the IQL contributes is the order: which one applies at which phase, with what deliverable and who runs it.

Shift-Left Testing

Move quality activities earlier in the development cycle

Involve QA from the start to catch defects sooner and cut rework, before a single line of code exists to break. In the IQL this is not left to intention: the story carries the «[QA] Shift-Left Review» subtask, opened when refinement starts and closed when it is delivered, and QA writes the story's Acceptance Test Plan.

  • Early-GamePrevention · Steps 1-4 · QA Analyst

12The three phases

Navigate the whole IQL

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

Early-Game

Phase 1 · Prevention · Steps 1-4

«Let's build it right from the start»

QA Analyst

Go to Early-Game

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

13The Trifuerza

The Testing Trifuerza

The Trifuerza (formerly called Tridente): the exploration model of the Execution stage, the three layers walked to validate a feature, UI · API · DB. It is also the minimum knowledge UPEX requires of a QA.

  • ui

    System Testing

    E2E / Frontend Testing

    Tests that validate the full flow starting from the UI

  • api

    Logic Layer Testing

    API Testing / Backend

    Tests at the business logic level

  • db

    Data Layer Testing

    Database Testing

    Tests of the data layer

14Where to learn

Integration with the ATLAS Model

The Integrated Quality Lifecycle gets implemented through the ATLAS Model, UPEX's pedagogical framework.

How they connect

  1. The IQL defines WHAT to do

    The phases, activities and strategic quality management goals.

  2. ATLAS defines HOW to learn it

    The pedagogical structure, the tools and the progression of competencies.

  3. Result: a complete QA

    A professional with an integral methodology and solid technical competencies.

ATLAS Model

Pedagogical framework

A structured learning system that combines theory, practice and mentoring to train QAs who master the full Integrated Quality Lifecycle.

Explore the ATLAS Model

Where the IQL is learned

Reading the method is enough to understand it. Operating it takes a Jira with real stories, a TMS with cases someone actually runs, and a repository where the pull request gets reviewed by someone else.

  • FREE

    Testing al Grano 3.0

    interactive course

    Seven modules with quizzes and a Jira simulator where you train the first two TMLC stages. Free, no paid account needed.

    Start the course
  • PREMIUM

    Dojo Saga 1 · Sprint Testing

    IQL Steps 1-7

    Shift-Left + Sprint Testing · Primer contacto con Automation (clase puente)

    See Dojo Saga 1
  • PREMIUM

    Dojo Saga 2 · Automation

    IQL Steps 7-15

    Test Automation · Regression + Observability

    See Dojo Saga 2
  • PREMIUMRECOMMENDED

    Dojo Agentic Quality Engineer

    full program

    Both sagas back to back, on a real project with Jira, the TMS and the real repository.

    See the program

For reading offline, printing, or reference without a connection

Master the IQL methodology

Become the QA that companies need: one who understands and applies quality management across the whole life cycle of the software.

See available courses
See the DOJO ProgramImplement it with UPEX

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