Case Study · Satlink · Learning Experiences

I designed the QA process.
Then I designed how to learn it.

A software team was writing its tests after the software was built, at the same time as running them. I moved the writing to before the build, made AI-assisted test generation an official and auditable part of the process, added a UI validation gate that did not exist, and documented all of it so it would survive without me. Then I turned that same process into the QA Explorer, a gamified course, so that the system and the way people learn it were designed by the same hand.

Process Design Gamified Learning Game Design Documentation System Azure DevOps Test Plans AI-Assisted Workflows Onboarding
Client project · 2026 · Delivered under Foxtale

Problem

Testing entered the picture when the software was already built and published: it picked up what had been developed, wrote the tests and ran them, all in the same final days of a two-week sprint. When there was a rush, what got cut was the writing, which is the part that adds value.

Worse: writing a test is what reveals that a requirement can be read two ways. In that order, the discovery arrived when the code was already written according to one of the two readings. What should have cost a message to the Product Owner cost rework.

Around it: six inconsistent documents, no test plans, no version recorded on failures, no formal review of what the AI generated, and a new tester with good will and no map.

Goal

Define the whole functional QA process for a maritime data platform with five applications inside it, document it so that it survives without me, and make it learnable by someone who has never done QA before, in time for a fixed launch date.

Not a manual nobody opens. A system a tester can follow on a Tuesday afternoon with a sprint on fire.

Objectives

  • Move test writing before the build, without moving execution
  • Add UI validation as a formal quality gate
  • Make AI-generated test cases official, traceable and human-approved
  • Anchor every test to its backlog item in Azure DevOps
  • Close the fifteen gaps found in the previous way of working
  • Build a four-week onboarding path for a junior tester
Part 01 · The one change

Move when the tests are written. Don't move when they run.

Nobody changes role, nobody takes on new responsibilities, the circuit gains no step. The only thing that changes is which week one of the existing activities happens in. It was possible because in this project the Product Owner already writes acceptance criteria at definition time; if they only existed at the end, the change could not be made.

Before
Define → Build → Publish → Write tests + run tests

Writing and running collide in the same final days. Ambiguities surface once the code exists.

Now
Define → Write tests → Build → Publish → Run tests

Writing a test forces a suspicious reading of the requirement. Gaps go back to the Product Owner before a line of code exists: the cheapest return in the whole circuit.

Does it look like what we defined?

UI validation, run by whoever defined the interface, before the business demo. Components, spacing, type, colours within the palette, empty / loading / error states, responsive behaviour.

The team that builds a screen stops seeing it with fresh eyes. Business does see it, and used to see it in the demo, which is the worst possible moment.

Every finding is logged as a bug with the tag diseño, even the ones fixed in five minutes. Without a record there is no trend.
Does it do what the requirement says?

Functional QA, run by testing against the acceptance criteria: business rules, calculations, error conditions, permissions, persistence, data integration.

Plus a 30–60 minute unscripted flow review inside this gate, for the problem neither gate catches: every piece correct and the whole still asking five steps where two would do.

Flow findings carry the tag ux; the Product Owner decides whether they enter the sprint or the backlog.
Part 02 · The system, on paper

Four documents instead of six, and a folder that explains itself

The first decision was editorial: what does a tester need to read, and in which order? Six legacy documents became four, each with a single job, and the folder structure was rebuilt so that a newcomer opens it and knows where to start without asking anyone. The order of the folders is the order in which to read them.

QA-01
The Process

How testing works and how it fits with the rest: the five phases and two gates, the four roles, why the roles work on different sprints, the audit of the fifteen gaps, and five metrics (and two deliberately not used).

QA-02
The Standard

What "done well" means: the test life cycle in ten phases, naming, the objectivity rule for expected results, severity and priority, regression, entry and exit criteria, and the rules for using AI. Three annexes with checklists.

QA-03
The Manual · v1.1

Everything step by step, with the clicks: twelve steps to set up the AI workspace per application, then twenty-two steps from reading the backlog item to closing the cycle. Azure notifications configured so failures arrive on their own.

QA-04
Day to Day

The job in five sentences, my day, my sprint, what I say in planning, what to do when something goes wrong, and the four-week plan for starting from zero.

P1–P6
Prompt library

Six prompts in working order, each with when to run it and how to know it went well. From reviewing the requirement to drafting the cycle report.

×11
Templates

Product sheet, functional glossary, decisions log, naming rules, UI validation, defect report, cycle report, CSV import for Azure DevOps. Corrected so none of them points to a document that no longer exists.

Documentation system · root
00_START_HERETwo walkthroughs and a one-page cheat sheet for the tester who joins tomorrow
01_STANDARDSQA-01 The Process · QA-02 The Standard · QA-03 The Manual · QA-04 Day to Day
03_TEMPLATESProduct sheet, glossary, decisions log, naming rules, UI validation, defect report, cycle report, CSV import
04_PROMPTSP1 to P6, each with a usage guide: when to run it and how to know it went well
05_PRODUCT_LINESOne context folder per application, ready to load into its own AI project
06_REPORTSCycle reports with the metrics table and a verdict field
07_TRAININGThe four-week onboarding plan and its deliverables
99_WORK_IN_PROGRESSDrafts. Nothing in here is a rule yet
00_READMEStructure and naming, in one page
OPEN_QUESTIONSEvery open decision, blocker and pending verification, numbered

The tree as delivered. Two files at the root: a one-page README and the open-questions log, where every undecided point has a number.

Spread of the QA manual

A page of the manual. Every step says what to click, what you should see, and what breaks if you skip it.

6→4
Legacy documents → core documents
15
Gaps audited and closed
22
Steps in the manual, with the clicks
1→5
Platform · applications covered
Part 03 · AI as a team member with a contract

The AI drafts. A person approves. The rules say which is which.

The company wanted QA inside its AI-assisted engineering initiative. The answer was not a magic agent but a procedure: one AI project per application, loaded once with the product sheet, the glossary and the decisions log, and six prompts run in a fixed order with a human gate in the middle. Every generated batch records date, source requirement, prompt used and review outcome, and cases carry the tags ia-generado and, after review, revisado, so the real effectiveness of the assistance can be measured.

What the AI does
  • Derives test cases from written acceptance criteria
  • Finds ambiguities, gaps and contradictions in a requirement, its highest-return use
  • Proposes edge cases and error conditions that habit skips
  • Converts cases to the Azure import format
  • Drafts defect reports and cycle reports from supplied data
What the AI never does
  • Approve its own cases. Human review is mandatory and cannot be delegated
  • Invent requirements. A gap is a question to the Product Owner, not a confident guess
  • Issue the verdict of an execution. Passed or Failed is signed by a person
  • Close defects
P1
Review the requirement

No cases yet. Ambiguities, gaps, non-objective criteria, questions for the PO, verdict.

P2
Generate the cases

Each case traced to a written sentence. Coverage matrix and declared gaps at the end.

P3
Self-critique

The model audits its own batch as an external reviewer. Thirty seconds, always finds something.

Gate
Human review

Against the checklist in Annex A. State changes from Design to Ready only here.

P4
Export to CSV

Exact column set for Azure DevOps. Import two cases first, then the rest.

P5 · P6
Defect and cycle report

Drafted from data. "What was left untested" is never left blank.

Part 04 · The game

A course you actually want to finish: five rooms, one treasure

Azure DevOps Test Plans is one of the most arid tools a newcomer can meet. The QA Explorer wraps the whole process in an expedition: a temple with five knowledge rooms, a fox guide, XP, a backpack, a journal and a treasure at the end called software quality. Every mechanic exists for a learning reason, not for decoration.

It is a complete, self-contained product: it runs in the browser, needs no backend, and was designed, written, illustrated and built by one person, using AI for art and copy and hand-written HTML, CSS and JavaScript for everything else.

Game Design Motivation Design Progression Systems Branching Narrative Pixel Art
LEVEL 2 · QA EXPLORER QA Explorer — the temple map with the five rooms

The map. Rooms unlock in the same order as the real workflow, so the player's progression is the process itself.

🗺️
Progression · why
Five rooms in workflow order

Map, Scrolls, Oracle, Chamber of Tests, Antechamber of Verdicts. You cannot execute before you have designed; the map enforces the order the standard asks for.

⭐
Feedback · why
XP and levels

Every decision returns XP immediately. Level names mirror real seniority, from QA Explorer to QA Master, so the progress bar means something outside the game.

🏆
Transfer · why
Achievements tied to real actions

"Map: create your first Test Plan." "Scribe: write ten test cases." "Bug Hunter: run twenty tests." Each badge is a task you will actually do on the job.

📖
Judgement · why
Interactive book with branching choices

Read a requirement, choose what to do, see the consequence. The wrong path teaches as much as the right one, which a manual can never do.

🔮
AI literacy · why
The AI Oracle

A room where the player learns to interrogate the model, not trust it: the same P1–P3 discipline as the real process, played before it is applied.

📁
Reality · why
A real project case at the end

After the temple, the actual case: context, metrics, decisions taken and lessons learned. The game closes by showing that all of this happened for real.

5
Knowledge rooms
5
Achievements, all job-linked
+350
XP to the treasure
90–120
Minutes, beginner level
A page of the interactive book with a branching choice

The interactive book. Chapter II, The Sacred Scrolls: the player chooses how to read a requirement and lives with the result.

Why an expedition

Test Plans has no shape of its own; it is menus and tables. A temple with rooms gives it a spatial structure the player can remember, and a reason to move forward.

Why pixel art

Deliberately low-fi. It signals "this is a game" without competing with the content, and it keeps the art consistent even when generated with AI.

Why a fox

The guide is the Foxtale mascot. It explains the rules in character, so the tone stays playful without the instructions getting vague.

Why no backend

A single static site anyone can open, fork or host. Progress lives in the browser. Nothing to install, nothing to maintain, nothing that blocks a tester on day one.

Part 05 · Teaching it, at the desk and in the game

The manual is correct. Nobody learns from a manual, so both were built.

A junior tester does not need to memorise a process; they need to want to go through it once, end to end, and come out the other side knowing where things are. So the process became a temple with five rooms, each room one stage of the real workflow, and Azure Test Plans became the treasure you learn to use by playing.

The QA Explorer is a complete self-contained product: a map with progression, an interactive book with branching choices, achievements tied to real actions (create a test plan, write ten cases, run twenty tests) and a real project case at the end. Built solo in HTML, CSS and JavaScript, with AI-generated art and copy, on the same documentation described above.

In the processIn the game
QA-01 · The circuit and the rolesRoom I · The Temple Map
QA-02 · Naming and the objectivity ruleRoom II · The Sacred Scrolls
P1–P3 · Generate with rulesRoom III · The AI Oracle
P4 · Plans, suites, import, linkRoom IV · The Chamber of Tests
P5–P6 · Execute, report, closeRoom V · The Antechamber of Verdicts
And the onboarding behind the game

Four weeks, one deliverable per week, and week two without AI on purpose

Whoever cannot write a test case cannot review a generated one. Skip week two and you end up approving whatever arrives, because you have nothing to compare it with. That looks like control and isn't.

Week 1
Understand the circuit, move around Azure

Deliver a saved "pending QA" query and half a page on what is being built now.

Week 2
Write cases by hand, no AI

Five to eight cases for a real, closed backlog item, passing the Annex A checklist.

Week 3
The full cycle with AI

Same item, P1 to approved cases in Azure, plus a written comparison against week two.

Week 4
Execute, report, close

A full cycle on a small feature. Done when someone else can reproduce your defects without asking.

↓ What follows is the QA Explorer itself
A preview of the course interface. The full playable version lives on its own site.
Play the QA Explorer →
🦊
Explorer
Your Name Here Level 12 · QA Explorer
XP
850 / 1,250
75 XP
Azure DevOps Test Plans — temple scene

Azure DevOps
Test Plans

The Treasure of Quality

Join the expedition to master Azure DevOps Test Plans and build quality tests that protect digital kingdoms.

LevelBeginner
Duration90 – 120 min
FormatInteractive
Total XP+350 XP
Start Adventure → See the Process
Your Progress
Level 2 — QA Explorer
420 / 1,250 XP
Your Mission:

The temple hides 5 knowledge rooms. Solve tests, make decisions and master Azure Test Plans to escape with the treasure: software quality.

  • Create and configure Test Plans
  • Design effective suites and test cases
  • Execute tests and analyse results
  • Master testing best practices
Foxtale
Foxtale character

This temple was built to protect software from the bugs lurking in the shadows.

Only QA Explorers who demonstrate wisdom and judgement will make it out alive… and with quality.

You'll Learn To:
Create and manage Test Plans
Design suites and test cases
Execute tests and record results
Analyse metrics and coverage
Apply QA best practices

Learning Path

📖
Room I The Temple Map
📜
Room II The Sacred Scrolls
🔮
Room III The AI Oracle
⚔️
Room IV The Chamber of Tests
⚡
Room V The Antechamber of Verdicts
💰
Final Treasure Eternal Quality
📚 Interactive Book

Choose your path and learn by playing

Chapter II — The Sacred Scrolls
Which path do you choose?
📖 Open Book
📁 Real Project Case

See how we applied Test Plans in a real project

Azure DevOps Test Plans screenshot
Project context and objectives
Impact metrics
Challenges and decisions made
Lessons learned
Rewards

Complete rooms, earn XP and unlock achievements

🦊
QA Explorer Complete 1 room
🗺️
Map Create your first Test Plan
✍️
Scribe Create 10 test cases
🐛
Bug Hunter Run 20 tests
⭐
QA Master Complete the temple

Ready for the Adventure?

Prove your worth and conquer quality.

Start Now →
Have a project in mind?

Let's design something memorable together.

Let's Talk Back to Work 🗺️ Back to Map