UPEX Galaxy · Corporate training

Quality engineeringyou put to workthe following Monday

Your team operates AI agents on a real product, with its technical debt and its regressions. Each person delivers a portfolio evaluated against a published 100-point rubric.

Allure report of the Agentic QA Boilerplate: 88.88% of tests passed, 1 failed and 8 passed out of a total of 9, with BaseURL dojo.upexgalaxy.com.
Agentic QA Boilerplate: 8 of 9 passed, 1 failed (88.88%).Generated on 7/6/2026 on dojo.upexgalaxy.com.
~$

// Contact

Before you decide, measure your team's level. Free.

The full fundamentals course is published on the site, with the theory and practice of the methodology, and the level assessment is open. Ask your team to do it this week and send you the result: in two hours you know who's ready to go straight in, who needs prior leveling, and who isn't ready yet.

// The differentiator

What Agentic Quality Engineering is

A practice with a name of its own: the QA operates AI agents on a real product and signs off on every decision.

  • Agent executes. Evidence proves. Human owns the decision.

    Agents don't run solo end to end: every subagent reports what it did and a person approves or corrects it. The machine does the mechanical work; the engineer decides.

  • Judgment first, agent second

    The second class is the last one without AI tools: first you learn to read code and refine criteria; only after that does the agent come in.

  • The framework, installed and yours to keep

    agentic-qa-boilerplate: a public repository under an MIT license, 15 skills, 6 MCPs, four pipelines, and the KATA architecture (Komponent Action Test Architecture) with dependency injection and a single dependency direction between its layers. Installs with one command.

  • On a product that has an owner

    The system under test is deployed, with a public repository, a Jira backlog, Gherkin criteria, and technical debt. The sensei (the instructor who runs the program) is its Product Owner: he answers the bugs your team reports.

Ten live weeks on that product

  • Refining acceptance criteria until they're testable
  • A story tested end to end: interface, database, and API
  • Automation in Playwright
  • Regression running in continuous integration
  • AI agents operated with controlled context

Those ten weeks are split into two Sagas, and that's how they're named throughout the page: each Saga has its own weeks, its rubric-based evaluation, and its own certificates.

// The method

What the IQL installs in your team

The Integrated Quality Lifecycle is the cycle your team learns to operate during the program: eight stages, from refining the story to what comes back from production, each one with what the agent executes and what the person signs off on. Read in outcomes, it's four blocks. Each one says what changes in your process and what your team gets when it operates it.

  1. 01 · Prevention

    QA joins refinement: your stories reach the sprint with verifiable criteria and an acceptance plan.

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

    Covers the stages Shift-Left · Planning

  2. 02 · Early Detection

    Early detection: your team gets the bugs before the PR, not after the release.

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

    Covers the stages Execution · Reporting · Documentation

  3. 03 · Continuous Detection

    Regression in CI your team can believe in: only what proved its value gets automated.

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

    Covers the stages Documentation · Automation · Regression

  4. 04 · Production Observation

    Production as the source of the quality strategy, as far as your infrastructure allows.

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

    Covers the stages Observation

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.

How far your team gets isn't defined by the method: it's defined by your product, its architecture, the risk it carries, and the maturity it already operates with. That's determined in an initial assessment, and it's what sets which block is your team's target and in what order each one gets adopted.

See the method's executive view the four blocks, with their phases and their stages

// Investment

The options, with the price per person up front

  • Dojo Agentic Quality Engineer

    Both Sagas from day 1, with the Jira access sprints the program already includes. In the purchase builder it shows up as "Dojo Completo".

    List, per person
    $497
    Paid per person
    $422.45

    What it includes

    • 🚀 Onboarding · Week 0
    • 📚 Foundations · Weeks 1-2
    • ⚔️ Sprint Testing · Weeks 3-4
    • 🎓 Ceremony: Saga 1 · Saga 1 closing
    • 🎬 E2E Automation · Weeks 5-6
    • 🔌 API Automation · Week 7
    • 🚀 DevOps for QA · Weeks 8-9
    • 🌌 Regression & Observability · Week 10
    • 🎓 Ceremony: Saga 2 · Week 11

    Certificates

    • Agentic Quality Analyst Engineer
    • Jira & Xray — Test Management Expertise
    • Agentic Quality Automation Engineer
    • Playwright — Test Automation Expertise
    See this option in the builder
  • Dojo Saga 1 · Sprint Testing

    Paid per person
    $297

    What it includes

    • 🚀 Onboarding · Week 0
    • 📚 Foundations · Weeks 1-2
    • ⚔️ Sprint Testing · Weeks 3-4
    • 🎬 E2E Automation · Class 5 (1 of 2 classes)
    • 🎓 Ceremony: Saga 1 · Saga 1 closing

    Certificates

    • Agentic Quality Analyst Engineer
    • Jira & Xray — Test Management Expertise
    See this option in the builder
  • Dojo Saga 2 · Automation

    Paid per person
    $297

    What it includes

    • 🎬 E2E Automation · Weeks 5-6
    • 🔌 API Automation · Week 7
    • 🚀 DevOps for QA · Weeks 8-9
    • 🌌 Regression & Observability · Week 10
    • 🎓 Ceremony: Saga 2 · Week 11

    Certificates

    • Agentic Quality Automation Engineer
    • Playwright — Test Automation Expertise
    See this option in the builder
  • Upgrade to both sagas

    For whoever already took Dojo Saga 1 and wants to complete both.

    Paid per person
    $227
    See this option in the builder
  • Dojo Saga Zero

    Prior leveling, optional. For whoever doesn't reach the entry level.

    Paid per person
    $175
    See this option in the builder

The amounts above are the price per person: each seat costs that. If you're going to enroll a team, message us before buying and we'll put together the configuration you need, with the amount agreed in writing.

// How a team enrolls

How you enroll your team

Each person has their own account, their own repository, and their own evaluation, so enrollment is per person. For a team, the procedure is this:

  1. 1

    You message us with the number of people and we agree on the package: the amount per person and the edition they'll join.

  2. 2

    Each person on your team creates their account on UPEX Galaxy.

  3. 3

    We confirm the enrollments together, everyone joins the same edition, and you get read access to the program's Jira.

  • What you have from day 1: everyone shares the edition's Slack channel, the sprints, and the closing ceremonies, and their deliverables stay in the program's GitHub organization, where you can open and review them.
  • On invoicing: message us with your company's tax details and we'll issue the invoice. If you need it settled before you pay, say so in the same message and we'll coordinate it.

// Before you decide

How much time it costs your team, and what it takes to enroll

Duration
10 weeks
Live sessions
10 classes of 2h + 2 closing ceremonies of 2h
Asynchronous session
1 onboarding session of 3h before week 1
Day and time
Tuesdays 7:30 PM Argentina time · 🇨🇴 5:30 PM · 🇲🇽 4:30 PM · 🇺🇸 EST 6:30 PM · 🇪🇸 12:30 AM
Total time per person
8 to 10 hours a week, including practice between classes
Class language
Spanish. The project's technical documentation is in English
Recordings
Every live class is recorded in the Dojoteca (the platform's library of classes and materials), with permanent access. If someone misses a day, they don't lose the content
Entry level
Manual testing fundamentals. This isn't a course from scratch. Whoever comes in without a base enters through Dojo Saga Zero
English
Technical reading level
Machine
16 GB of RAM for the full experience (several agents and Playwright workers in parallel). With 8 GB it works in a limited way: one agent at a time. With less than 8 GB it isn't viable
Operating system
macOS, Linux, or Windows with WSL2
External tool cost
$10 USD/month per person at minimum, on whichever AI tool they choose. Valid options: OpenCode ($5-10), DeepSeek API (from $2), Claude Pro ($20), or ChatGPT Pro ($20). You pay it or the person pays it, but it isn't included in the price and it isn't optional
If someone falls behind
Classes are recorded and the material doesn't expire. Deliverables have a resubmission window
Current edition
Edition #4 · Aug-Oct 2026

// It's not a diploma

What you can open and review for each person

This program doesn't end with an attendance certificate. It ends with five artifacts that exist, that can be cloned, and that a manager can audit without knowing QA.

  1. 1 ·

    A repository with the suite running. E2E tests with Page Object Model and fixtures, API tests, multi-project configuration, and a GitHub Actions pipeline with smoke, sanity, and regression kept separate. It lives as .github/workflows/tests.yml and reports/allure-report/.

  2. 2 ·

    A defect board with metrics. Bugs with severity, priority, reproduction steps and evidence; retesting with formal sign-off; escape rate and reopen rate.

  3. 3 ·

    Formal test cases documented in the TMS (native Jira or Xray, depending on the instance), each with its return verdict: gets automated, stays manual, or gets deferred, justified in writing.

  4. 4 ·

    Refined acceptance criteria in testable format, from the real sprint your team worked.

  5. 5 ·

    The complete framework. agentic-qa-boilerplate, MIT license, which the person keeps installed with one command and can replicate in your company's repository.

How it's evaluated

Each Saga closes with an evaluation out of 100 points, with published dimensions and weights:

Dojo Saga 1 · Sprint Testing

Context and agent
15
Shift-Left
20
Trifuerza UI+API+DB
25
Defect management
30
Presentation
10

Dojo Saga 2 · Automation

E2E
25
API
15
CI/CD and regression
25
Test architecture
20
Observability
10
Presentation
5

You pass with 70. With 90 or more, with distinction. Below 70 you get a Certificate of Participation and there are two weeks to resubmit at no extra cost. The method is Problem-Driven Learning: there are no theory exams, you certify by delivering work.

Provisional access to the program's Jira for the team lead. If you enroll your team, we give you read access to the Jira where they work, and you see firsthand the stories each person picks up, how they develop them, how they test them, and the traceability between acceptance criteria, test case, the story's test set, execution and defect. You also see how we've set up our own Jira, which is that of a working product team. Progress and evaluation are still per person: what you get is the work in progress in view, not a board with the team's aggregate.

// Skills map by profile

Who on your team benefits from what?

The profiles, classes, and deliverables come straight from the syllabus, in its own vocabulary. The acronyms, in one line: US is a user story; FTP (Feature Test Plan) is the test plan for a whole epic, refined as the epic moves forward: the Feature altitude has a plan but no execution of its own; ATP (Acceptance Test Plan) is the test plan for a single user story, living only in a field on the story before the sprint starts, with the item born once the sprint opens; ATS (Acceptance Test Set) is the collection of test cases for a story, mandatory, created first, and the only link to the story that counts toward coverage; TC (Test Case) is the individual test case, with its steps and expected result, documented in the test manager; ATC (Acceptance Test Case) is the test case born from an acceptance criterion: the A is for Acceptance, never Automated; the TMS is that test manager, native Jira or Xray; the ROI is the verdict that decides each case's fate (Candidate gets automated, Manual stays manual, Deferred stays out of regression); POM (Page Object Model) is the pattern the automated suite is organized around; and the acronyms ending in R (STR and ATR) are the record of what ran, not the plan.

  • Setup

    Classes that train it

    • Class 0 · Onboarding🚀 Onboarding · Week 0Deliverable: Configured workspace
  • Agentic QA Foundations

    Classes that train it

    • Class 1 · Agents and Context Engineering📚 Foundations · Weeks 1-2Deliverable: Your first CLI agent configured + a complete end-to-end agentic flow
  • QA Analyst

    Method phase: Early-Game · PreventionMethod phase: Mid-Game · Detection

    Classes that train it

    • Class 2 · Shift-Left Testing📚 Foundations · Weeks 1-2Deliverable: Refined ATPs with testable acceptance criteria
    • Class 3 · Sprint Testing: Trifuerza⚔️ Sprint Testing · Weeks 3-4Deliverable: Bugs reported in Jira (input for Class 4)
    • Class 4 · Bugs & Test Management⚔️ Sprint Testing · Weeks 3-4Deliverable: Defect dashboard + retested bugs with sign-off + formal TCs documented in the TMS with an ROI verdict (Candidate/Manual/Deferred)

    Cycle stages it covers

    1. Shift-Leftpre-sprint

      1 · Requirements Analysis

    2. Planningin-sprint

      1 · Requirements Analysis

    3. Executionin-sprint

      3 · Early Exploratory Testing

    4. Reportingin-sprint

      3 · Early Exploratory Testing

    5. Documentationpost-sprint

      4 · Risk-Based Prioritisation — 5 · Asynchronous Test Case Documentation — 6 · Assessing TCs for Automation

    6. SDLC Event

      2 · Development and Implementation

  • QA Automation Engineer

    Method phase: Mid-Game · Detection

    Classes that train it

    • Class 5 · E2E Automation: Fundamentals🎬 E2E Automation · Weeks 5-6Deliverable: 1 working KATA method with `@atc('KEY')` (the automation of a candidate ATC)
    • Class 6 · E2E Automation: Structure and Patterns🎬 E2E Automation · Weeks 5-6Deliverable: E2E suite with POM + fixtures + parallelization
    • Class 7 · API Automation🔌 API Automation · Week 7Deliverable: API automation suite integrated with E2E
    • Class 8 · CI/CD & Agentic Routines🚀 DevOps for QA · Weeks 8-9Deliverable: GitHub Actions pipeline + Allure + Xray reporting + 1 scheduled agentic routine

    Cycle stages it covers

    1. Automationpost-sprint

      7 · Automating the Candidates — 8 · Verifying the Suite in CI — 9 · Pull Request Review

  • SDET

    Method phase: Late-Game · Observation

    Classes that train it

    • Class 9 · Test Architecture (SDET)🚀 DevOps for QA · Weeks 8-9Deliverable: KATA architecture implemented with multi-project setup

    Cycle stages it covers

    1. Regressionpost-sprint

      10 · Continuous Maintenance

  • QA + DevOps

    Method phase: Late-Game · Observation

    Classes that train it

    • Class 10 · Regression and Observability🌌 Regression & Observability · Week 10Deliverable: Maintained and updated regression suite + industry observability landscape report

    Cycle stages it covers

    1. Observationproduction

      11 · Canary Release Monitoring — 12 · A/B Testing — 13 · Real User Monitoring — 14 · Chaos Engineering — 15 · Feedback Loop

// Buyer FAQ

What the person signing asks, before they sign

  • Does it work if my team doesn't use Playwright?

    The program teaches Playwright with TypeScript, and that's the stack your team will use during the ten weeks. What transfers to another tool is the judgment: why a locator is fragile, how a suite is structured so someone who didn't write it can maintain it, what goes in the smoke test and what goes in the nightly regression, how you decide what isn't worth automating. If your team uses Cypress or Selenium, those judgments apply the same way; the files don't.

    If you want to verify it before paying, the framework is public with an MIT license: you can clone it and have your tech lead look it over. And we can do a twenty-minute technical fit call with them.

  • How many hours a week does it take from my team, and in what time slot?

    One live 2-hour class per week, Tuesdays at 7:30 PM Argentina time, plus practice between classes. Budget 8 to 10 hours a week per person in total. The class falls outside working hours across almost all of LATAM; each person organizes their own practice time. Every class is recorded: if someone can't make it on a given day, they don't lose the content.

  • What language are the classes in?

    Spanish. The project's and the tools' technical documentation is in English, and technical reading English is required.

  • What happens if someone misses a class or falls behind?

    Classes are recorded in the Dojoteca with permanent access, so the content isn't lost. Deliverables are evaluated at the close of each module; anyone who doesn't reach the 70-point threshold gets a Certificate of Participation and two weeks to resubmit at no extra cost. If someone can't keep up with the term's pace, we'd rather they wait for the next edition: cohorts run continuously.

  • What do I get as the person responsible, during and after?

    During: your team works in the edition's Slack, in Jira, and in the program's GitHub organization, and their deliverables stay visible there.

    And you get into Jira with them. Whoever enrolls their team gets read access to the program's Jira: you see the stories each person picks up, how they develop them, how they test them, and the traceability between acceptance criteria, test case, the story's test set, execution and defect. Along the way you also see how we've set up our own Jira, which is that of a working product team.

    After: the evaluation with the published rubric at the close of each module, and the portfolio deliverables, which you can open and review. Progress and evaluation are per person.

  • How does the price work if I enroll several people?

    The published prices are per person: each seat costs that amount.

    If you're going to enroll a team, message us before buying. We accept custom configurations and agree on the package amount with you, in writing, before you pay anything.

    The difference between the list price and what you pay at checkout isn't a negotiation: it's the automatic discount the cart itself applies based on each purchase's total, with no code or coupon needed.

  • Do you issue an invoice in my company's name?

    Yes. Send us your company's tax details and we'll issue the invoice. If you need it settled before you pay, say so in the same message and we'll coordinate it there.

  • Does the certificate carry the backing of any institution?

    No, and we'd rather say it plainly. It's issued by UPEX Galaxy and signed by the sensei as the engineer in the field, like the vast majority of private tech certificates. No private course certificate carries state or international accreditation.

    What it does have is a unique verification code and a QR code printed on the certificate itself: scanning it lands on that certificate's verification page. And it has a public rubric that explains exactly what the person had to deliver to earn it. The program leaves more than enough foundation to sit the ISTQB exam independently, if your organization needs it as a formal credential.

  • Is there a refund?

    Yes, but it's partial, and here's why. As soon as someone joins, they get access to all the content at once (they could download almost all of it in a single day), so there's no full walking it back. The cost of the sprints already used and the operating expenses of the live classes are deducted; the rest is returned. Access to the Dojoteca, to GitHub, and to Jira is withdrawn. Slack, which is free, stays.

  • What happens if the person leaves the company after I trained them?

    Three honest answers. The first: training is one of the most effective retention levers there is, so the risk of not training is usually bigger. The second: what you can protect contractually is for you to define; we don't get involved there.

    The third is the one that depends on us: make sure the deliverable stays with the company. The framework, the suite, the pipeline, and the criteria documentation are artifacts, not knowledge locked in someone's head. If your team replicates them in your repository during the program, the asset stays even if the person leaves.

  • What does my company walk away with when the program ends?

    Five things, all auditable: a repository with the working E2E and API suite; a regression pipeline in GitHub Actions; a defect board with escape rate and reopen rate; formal test cases documented in the TMS (native Jira or Xray, depending on the instance) with a return verdict; and the agentic-qa-boilerplate framework under an MIT license, which every person keeps and installs with a single command.

  • What does the program NOT cover?

    Load and performance testing: not in the syllabus. Security testing: not in the syllabus. Observability run against a real production environment: it's covered as an industry overview, not as practice. And we don't migrate your existing suite or audit your current quality process: that's consulting, not training.

  • How many people are in the classroom?

    Message us and we'll confirm the available spots for the current edition before you enroll your team.

  • How much does it cost in external tools, on top of the program?

    A minimum of $10 USD per month per person on whichever AI tool each one chooses. Valid options: OpenCode ($5-10), DeepSeek API (top-ups from $2), Claude Pro ($20), or ChatGPT Pro ($20). It's not included in the price and it's not optional: the program is designed around AI agents. We're telling you now so it fits your budget instead of showing up later.

  • The next edition starts soon and I won't make it in time to organize my team. What do I do?

    Message us anyway and we'll reserve spots for the next edition, at today's price. Cohorts run continuously. In the meantime, there's something your team can do this week at no cost: the full fundamentals course is published on the site and the level assessment is open and free. In two hours each person knows whether they go straight into the program or need prior leveling, and you arrive at the next edition with the diagnosis already done.

// What's already happening to you

12 concrete problems, and what part of the program trains each one

There is no generic "best practices" module. Every problem on this list has a named class, a deliverable that gets reviewed, and a scored evaluation criterion.

  • // Dojo Saga 2 · Automation · Class 8

    Regression stops eating the week

    “Regression eats our week before every release”

    The problem, the way it sounds on your team

    “Regression eats our week before every release”

    What gets trained

    • 🚀 DevOps for QA · Weeks 8-9
    • Class 8 · CI/CD & Agentic Routines

    Builds a real pipeline in GitHub Actions with the three suites kept separate (smoke, sanity, and full regression) and its three triggers: manual, scheduled, and on push. Secrets and environment management, selecting and prioritizing which case goes in each suite, triaging flaky tests instead of just retrying them, and an Allure report integrated with Xray with traceability from the case to the result. It also delivers a scheduled agentic routine: it runs on its own, with a declared trigger and permissions, and reports to a person.

    + Class 6

    What's left as evidence

    • Deliverable · Class 8GitHub Actions pipeline + Allure + Xray reporting + 1 scheduled agentic routine
    • Rubric · Dojo Saga 2 · AutomationCI/CD and regression — Regression suite25 / 100 pts · passes with 70 · 2 weeks to resubmit
    • Rubric · Dojo Saga 2 · AutomationCI/CD and regression — Agentic routine25 / 100 pts · passes with 70 · 2 weeks to resubmit
    • In the portfolio.github/workflows/tests.yml
    • In the portfolioreports/allure-report/
    • The complete framework installs with one command and stays in the person's repository: agentic-qa-boilerplate, public and under an MIT license.See the framework on GitHub

    What your employee can do afterward

    Leaves regression running on its own, on a schedule, in continuous integration, and decides with judgment which case goes into the smoke test for each deploy and what runs once a night.

    What this block doesn't do

    Doesn't migrate the suite your team already has. The judgment is trained on the program's project; bringing it to your repository is later work.

  • // Dojo Saga 2 · Automation · Class 5 and 6

    The pipeline becomes a signal again

    “The pipeline's been red for two weeks. We give it another run and it passes. Nobody looks at the tests anymore”

    The problem, the way it sounds on your team

    “The pipeline's been red for two weeks. We give it another run and it passes. Nobody looks at the tests anymore”

    What gets trained

    • 🎬 E2E Automation · Weeks 5-6
    • Class 5 · E2E Automation: Fundamentals
    • Class 6 · E2E Automation: Structure and Patterns

    Locators by role, text, or test id, with the anti-patterns of XPath and fragile selectors named explicitly; auto-waiting; assertions. Then structure: Page Object Model, Playwright fixtures, parallelization, and visual regression. Triaging flaky tests is worked on once you reach the pipeline.

    + Class 8

    What's left as evidence

    • Deliverable · Class 6E2E suite with POM + fixtures + parallelization
    • Rubric · Dojo Saga 2 · AutomationE2E — Page Object Model25 / 100 pts · passes with 70 · 2 weeks to resubmit
    • In the portfoliotests/e2e/pages/
    • In the portfoliotests/e2e/fixtures/

    What your employee can do afterward

    Diagnoses why a test is flaky (synchronization, shared data, selector) and fixes the cause. And leaves the suite in a state where someone else on the team can touch it without breaking it.

  • // Class 3 and 7

    Testing stops ending at the interface

    “We only test through the interface. Data bugs and broken contracts between services show up in production”

    The problem, the way it sounds on your team

    “We only test through the interface. Data bugs and broken contracts between services show up in production”

    What gets trained

    • ⚔️ Sprint Testing · Weeks 3-4
    • 🔌 API Automation · Week 7
    • Class 3 · Sprint Testing: Trifuerza
    • Class 7 · API Automation

    A complete story covered across interface, database, and API in the same session, with Playwright MCP executing, DBHub MCP validating persistence, and OpenAPI MCP invoking endpoints. On the automation side: reusable request builders, contract testing against OpenAPI specs, schema validation, and setup and teardown via API.

    What's left as evidence

    • Rubric · Dojo Saga 1 · Sprint TestingTrifuerza UI+API+DB — Layer coverage25 / 100 pts · passes with 70 · 2 weeks to resubmit
    • Rubric · Dojo Saga 2 · AutomationAPI — Integration with E2E suite15 / 100 pts · passes with 70 · 2 weeks to resubmit
    • Deliverable · Class 7API automation suite integrated with E2E
    • In the portfolio03-trifuerza/story-1-ui.md
    • In the portfolio03-trifuerza/story-2-ui-db.md
    • In the portfolio03-trifuerza/story-3-ui-db-api.md

    What your employee can do afterward

    Closes a story validating all three layers, and catches a contract break between services before the frontend ever sees it.

    What this block doesn't do

    Nobody passes the evaluation having tested only the interface: layer coverage is a scored criterion.

  • // Dojo Saga 1 · Sprint Testing · Class 2

    Rework gets cut off at refinement

    “Stories reach development with ambiguous criteria and the rework only shows up in QA”

    The problem, the way it sounds on your team

    “Stories reach development with ambiguous criteria and the rework only shows up in QA”

    What gets trained

    • 📚 Foundations · Weeks 1-2
    • Class 2 · Shift-Left Testing

    Critical code reading without tools, Value-Cost-Risk prioritization, and turning ambiguous acceptance criteria into testable contracts in Given-When-Then format.

    What's left as evidence

    • Deliverable · Class 2Refined ATPs with testable acceptance criteria
    • Rubric · Dojo Saga 1 · Sprint TestingShift-Left — Testable ACs20 / 100 pts · passes with 70 · 2 weeks to resubmit
    • In the portfolio02-shift-left/atp-refinado.md

    What your employee can do afterward

    Walks into a refinement and stops a poorly written story before it gets developed, with the argument in writing.

  • // Dojo Saga 1 · Sprint Testing · Class 1

    The AI license starts paying off in work

    “We buy AI licenses for the team and see no return: nobody knows how to give the agent context or when to distrust it”

    The problem, the way it sounds on your team

    “We buy AI licenses for the team and see no return: nobody knows how to give the agent context or when to distrust it”

    What gets trained

    • 📚 Foundations · Weeks 1-2
    • Class 1 · Agents and Context Engineering

    Operating an agentic CLI with controlled context: the repository's context file, file references, managing the context window, and connecting MCPs. The syllabus names the context anti-patterns with the same vocabulary the industry uses.

    What's left as evidence

    • Deliverable · Class 1Your first CLI agent configured + a complete end-to-end agentic flow
    • Rubric · Dojo Saga 1 · Sprint TestingContext and agent — Documented agentic flow15 / 100 pts · passes with 70 · 2 weeks to resubmit
    • In the portfolio01-contexto/primer-flow-agentic.md
    • The real external cost is stated in the program requirements: each person pays for their own AI tools, with a published minimum monthly budget. No competitor publishes that figure.

    What your employee can do afterward

    Puts an agent to work doing QA on a real repository and recognizes when the agent is getting it wrong, instead of accepting its output.

    What this block doesn't do

    The program doesn't include a shared token or AI license package: each person pays for their own. What it does train is how to spend less and when to switch models.

  • // Dojo Saga 1 · Sprint Testing · Class 4

    Sprint quality gets defended with numbers

    “When leadership asks how quality looks this sprint, I don't have a number”

    The problem, the way it sounds on your team

    “When leadership asks how quality looks this sprint, I don't have a number”

    What gets trained

    • ⚔️ Sprint Testing · Weeks 3-4
    • Class 4 · Bugs & Test Management

    Anatomy of a bug report with severity, priority, reproduction, and evidence; defect boards with custom fields and advanced JQL; retesting with formal sign-off; formal test case documentation in Xray.

    What's left as evidence

    • Deliverable · Class 4Defect dashboard + retested bugs with sign-off + formal TCs documented in the TMS with an ROI verdict (Candidate/Manual/Deferred)
    • Rubric · Dojo Saga 1 · Sprint TestingDefect management — Dashboard30 / 100 pts · passes with 70 · 2 weeks to resubmit
    • In the portfolio04-defect-management/dashboard-defectos.png
    • In the portfolio04-defect-management/bugs-retesteados.md
    • The rubric calls the metrics out by name: escape rate and reopen rate. It's the heaviest-weighted block of Dojo Saga 1.

    What your employee can do afterward

    Publishes a board their manager can read on their own, and defends the sprint's quality status with two metrics instead of a feeling.

    What this block doesn't do

    Progress and evidence are per person, and the team lead gets into the program's Jira to see them: who works which story, with what traceability and what result. What gets reviewed is the real work, not an aggregate board.

  • // Dojo Saga 1 · Sprint Testing · Class 4

    What gets automated and what doesn't gets decided

    “We automate out of inertia. Nobody decides what's worth automating”

    The problem, the way it sounds on your team

    “We automate out of inertia. Nobody decides what's worth automating”

    What gets trained

    • ⚔️ Sprint Testing · Weeks 3-4
    • Class 4 · Bugs & Test Management

    Every documented case gets a return verdict (gets automated, stays manual, or gets deferred), justified in writing, and that verdict decides what gets automated in the following classes. It's not a side note: it's a real transition in the Jira workflow.

    What's left as evidence

    • Rubric · Dojo Saga 1 · Sprint TestingDefect management — Formal ATCs + ROI verdict30 / 100 pts · passes with 70 · 2 weeks to resubmit
    • In the portfolio04-defect-management/atcs-formales-xray.md

    What your employee can do afterward

    Justifies in writing what does NOT get automated. It's the decision nobody makes today, which is why the suite grows out of control.

  • // Dojo Saga 2 · Automation · Class 9

    The framework's standard stops living in one person's head

    “Only one person knows how to maintain the framework. If they leave, we're blind”

    The problem, the way it sounds on your team

    “Only one person knows how to maintain the framework. If they leave, we're blind”

    What gets trained

    • 🚀 DevOps for QA · Weeks 8-9
    • Class 9 · Test Architecture (SDET)

    KATA architecture (Komponent Action Test Architecture) and dependency injection, multi-project configuration, framework layering (context, bases, domain components, fixtures, and tests), custom reporters, test data factories, and cleanup strategies. The sequence is deliberate: the syllabus states that the student needs to have felt the pain of maintaining an unstructured suite before appreciating the architecture.

    What's left as evidence

    • Deliverable · Class 9KATA architecture implemented with multi-project setup
    • Rubric · Dojo Saga 2 · AutomationTest architecture — Framework layering20 / 100 pts · passes with 70 · 2 weeks to resubmit
    • In the portfolioplaywright.config.ts
    • In the portfoliotests/utilities/
    • The framework is a public repository under an MIT license, installable with one command. The tech lead can audit it before buying, which is what they're going to do anyway.See the framework on GitHub

    What your employee can do afterward

    Defines how the team's framework gets structured, and the standard ends up written in a repository, not in someone's head.

  • The manual tester enters automation by a staircase, not a leap

    “I have very good manual testers who don't code. I can't ask them to touch the repository, and replacing them isn't an option”

    The problem, the way it sounds on your team

    “I have very good manual testers who don't code. I can't ask them to touch the repository, and replacing them isn't an option”

    What gets trained

    A real staircase: first Dojo Saga Zero (a month of 1:1 practice with a Senpai, the mentor assigned to each person: pure manual QA, deliberately without AI, because judgment comes first and the tool comes after), and only then Dojo Saga 1 and Dojo Saga 2, or the full Dojo. Every week has a class, a mission on a real story, and evaluation against explicit criteria, and it closes with a final exam where a second story gets solved solo against a reference sample.

    What's left as evidence

    • The full Dojo Saga Zero roadmap is public: every world, every node, and the evaluation criteria for each stage.See the Saga Zero roadmap
    • The final exam criteria include that the whole cycle was solved solo: the Senpai observed, they didn't step in.
    • Prior leveling is free and public: the interactive fundamentals courses for testing and code, and the Checkpoint assessment.See the level assessment

    What your employee can do afterward

    Runs the full manual cycle of a story (plan, exploration, reporting, retesting, sign-off, formal cases) with auditable evidence, and ends up ready to move into automation.

    What this block doesn't do

    Dojo Saga Zero doesn't teach AI on purpose, and it gives out a Certificate of Participation, not a certificate. We say so before charging, not after.

  • QA and development start speaking the same language

    “QA and development don't understand each other. QA doesn't know why a technical decision was made or what happens before the ticket”

    The problem, the way it sounds on your team

    “QA and development don't understand each other. QA doesn't know why a technical decision was made or what happens before the ticket”

    What gets trained

    • Devlog 1 · Jira Workspace Setup
    • Devlog 2 · From Idea to Backlog
    • Devlog 3 · Design: From Idea to Mockup
    • Devlog 4 · Infrastructure
    • Devlog 5 · The Implementation Loop

    The devlogs are asynchronous content on the development side: setting up a Jira project with workflows and custom fields; producing a Constitution, PRD, SRS, and ADRs and populating the backlog with INVEST and Gherkin criteria; mapping screens to stories; standing up backend and frontend; and the implementation cycle, adversarial code review with BLOCKER, MAJOR, MINOR, and NIT severities, deployment to staging with auto-transition to Ready For QA, and production with gates and a rollback plan. Plus real sprints in Jira with full Scrum ceremonies.

    What's left as evidence

    • The devlogs and their syllabus are in the public curriculum: they can be read before buying.See the full syllabus
    • The code review severity vocabulary is the same one your development team already uses.

    What your employee can do afterward

    Reads an ADR, takes part in a refinement talking about the product and not just bugs, and does code review with a severity criterion.

  • The team's real level gets measured before you pay

    “I don't know my team's real level. I don't want to pay for a program only to find out half of them can't keep up”

    The problem, the way it sounds on your team

    “I don't know my team's real level. I don't want to pay for a program only to find out half of them can't keep up”

    What gets trained

    Three free, public resources that already exist: a full testing course published on the site, an interactive code fundamentals course, and an assessment with an aptitude badge. Plus the program's stated requirements: prior knowledge, AI tool budget, minimum hardware, and weekly time commitment.

    What's left as evidence

    What you can decide afterward

    Decides with data whether to buy Dojo Saga Zero, Dojo Saga 1, or the full Dojo, and for which people on their team.

    What this block doesn't do

    The assessment is individual and each person shares their own result. Ask your team to take it this week and send you theirs.

  • Technical competence turns into professional presence

    “I have technically competent people who don't progress: they don't communicate their work, they freeze up with feedback, they have no presence in ceremonies”

    The problem, the way it sounds on your team

    “I have technically competent people who don't progress: they don't communicate their work, they freeze up with feedback, they have no presence in ceremonies”

    What gets trained

    Live 1:1 sessions: diagnosis and an improvement plan for communication, handling feedback, and professional presence, with session-by-session follow-up; plus preparation for dailies, retrospectives, and difficult conversations. The service draws its own boundary: it's not motivational talk.

    What's left as evidence

    • The service's components are detailed and published on their own page.See the Performance Lab
    • The differentiator: while taking the Dojo, the mentor observes real performance in the sprints: how they communicate, how they report, how they react to feedback.

    What your employee can do afterward

    Presents their work in ceremonies and takes feedback without freezing up.

    What this block doesn't do

    Without the Dojo, the metrics get built on the sessions themselves, not on observed sprints.

And what you won't find here

This program doesn't cover load or performance testing, and doesn't cover security testing: they're not in the syllabus. The observability part is presented as an industry overview (incident metrics, progressive rollouts, feature flags), without running against a real production environment. Your QA will be able to understand and weigh in on the post-deployment quality strategy; they won't come out of it operating it in your production.

If your problem is one of those three, we'd rather tell you before you pay.

See the operating fact sheet: hours, schedule, language and requirements →

// What the program doesn't cover

What does the program NOT cover?

  • Load and performance testing

    Not in the syllabus. We don't cover them and we don't hint at them.

  • Security testing

    Not in the syllabus. We don't cover it and we don't hint at it.

  • Operating observability in your production

    The class covers the industry overview: canary releases, feature flags, RUM and Core Web Vitals, incident metrics, chaos engineering, and a QA-on-call playbook. The stated goal in the syllabus is to present it as a roadmap, without running it against a real production environment. Your QA will be able to understand and weigh in on the post-deployment quality strategy. They don't come out of it operating an observability stack in your production. We'd rather tell you.

    Where it comes up in the syllabus

    • 🌌 Regression & Observability · Week 10
    • Class 10 · Regression and Observability

All of this, in a document you can forward

The same information on this page, laid out to read on paper: the executive summary, the full operating fact sheet, the price per person, the 12 problems with their evidence laid out, and the buyer's questions with the full answer.

Document ready to print or forward by email