Dungeon Raiders - Ongoing Embedded QA Case Study
🧾 Project Overview
- Game: Dungeon Raiders
- Studio: Loom & Lore Interactive Games
- Credited Role: Head of QA
- Testing dates: Ongoing from 17 May 2026
- Status: Released, with ongoing QA support across updates and new builds
- Platform: Android
- Credit: Credited in-game as “Head of QA Kelina Cowell”
🎯 My QA Role
My role is to provide ongoing embedded QA support for Dungeon Raiders across live updates, new builds, regression cycles, and player-facing gameplay checks. The work combines exploratory testing, patch-note targeted regression, fix validation, smoke testing, persistence checks, and Android mobile usability review.
Because the game is actively updated, each pass is shaped around the current build state, recent fixes, new content, known risks, and what a normal Android player is likely to encounter during play.
I am credited in the released game as Head of QA Kelina Cowell, reflecting my ongoing QA contribution to the project.
Developer Feedback
“Kelina’s ability to take a piece of software and turn it inside out has been invaluable to our pipeline. She is immaculate, professional, and fiercely reliable, helping us ship games on timelines that would be impossible for a solo dev.”
🧠 Triage & Planning
- Reviewed patch notes and build changes
- Identified regression risk areas
- Prioritised Android player impact
- Separated bugs from tuning concerns
- Planned targeted retest coverage
🎮 Testing Focus
- Android gameplay stability
- UI and menu behaviour
- Class and ability behaviour
- Save and resume persistence
- Shop and economy consistency
🔁 Ongoing Support
- Patch-note regression testing
- Fix validation after updates
- New content smoke testing
- Connected-system retesting
- Future Android update support
🛠️ Workflow & Communication
Testing is carried out as an ongoing embedded QA workflow. Each pass is shaped around the current build, latest patch notes, known risk areas, and player-facing behaviour observed during Android gameplay.
The workflow is intentionally practical. I focus on what a player can see, misunderstand, break, lose progress through, or become frustrated by during normal play. Where needed, I also use targeted regression and debug-assisted coverage to reach specific systems or later progression states more efficiently.
| Workflow Area | How It Worked |
|---|---|
| Communication | Ongoing communication with the developer around new builds, patch notes, reported issues, fixes, and retest priorities. |
| Planning | Each QA pass was planned around the current build state, recent changes, known risk areas, and player-facing impact. |
| Testing | Testing combined player-focused exploratory gameplay, targeted regression, smoke testing, persistence checks, and Android mobile usability review. |
| Reporting | Findings were written clearly with player impact, reproducible behaviour, relevant context, and evidence where useful. |
| Regression | Fixes were retested in later builds, with nearby systems checked where changes could cause regressions. |
| Ongoing Support | Further QA passes are expected as Dungeon Raiders continues receiving updates, fixes, tuning, and new content. |
🎮 Android Regression & Gameplay Systems Testing
The main testing work has focused on keeping Dungeon Raiders stable, readable, and consistent across Android updates. This includes normal gameplay flow, class behaviour, combat feedback, menu interaction, save/resume persistence, reward behaviour, shop systems, and regression risks introduced by fixes or new content.
Testing has included both player-focused exploratory passes and targeted regression passes. Exploratory testing helped identify visible issues during normal play, while patch-note targeted regression checked whether specific fixes, features, class changes, and menu behaviours worked correctly after updates.
| Test Area | Observed Focus |
|---|---|
| Android Gameplay Stability | Normal gameplay flow, transitions, touch interaction, run-state behaviour, and mobile usability. |
| UI & Menu Behaviour | Menu flow, overlays, button feedback, pressed states, readability, and reopen behaviour after resume. |
| Combat Systems | Sword attacks, Cleave, Thorns, ENTANGLE behaviour, ability handling, combat feedback, and empty-board ability behaviour. |
| Class Behaviour | Warrior, Druid, Fisher, class-specific level-up pools, class selection, and weapon art persistence. |
| Save & Resume Persistence | Android backgrounding, resume flow, relic persistence, shop item persistence, and menu functionality after resume. |
| Shop & Economy | Gold, Soul Shards, upgrades, duplicate purchase prevention, shop behaviour, and progression reward consistency. |
| Patch-Note Regression | Verification of listed fixes, changed systems, class updates, UI changes, and nearby regression risks. |
| New Content Smoke Testing | New classes, updated reward pools, new features, menu additions, and release/update readiness checks. |
⚠️ Current Player-Facing Risk Areas
The risks below are grouped by player impact rather than listing individual internal bug reports. This keeps the case study focused on QA judgement while protecting private project details.
| Risk Area | Player Impact |
|---|---|
| Save / Resume Reliability | Mobile players expect interrupted sessions to resume correctly. Persistence issues can damage trust quickly. |
| UI & Overlay Stability | Menus, overlays, and buttons need to behave consistently so players do not feel the game state is unstable. |
| Class & Ability Clarity | Unclear ability behaviour can make class mechanics feel unreliable, especially when players are making run-critical choices. |
| Combat Feedback | Players need clear feedback when damage, abilities, rewards, or deaths occur so they understand the outcome of their actions. |
| Shop & Economy Consistency | Upgrade, purchase, and reward issues can affect progression trust and make the economy feel unreliable. |
| Regression Risk After Updates | New features and fixes can affect nearby systems, especially menus, persistence, class behaviour, and reward flow. |
🤝 Working With the Developer
Dungeon Raiders is a live, evolving project, so the QA support needs to stay flexible. Some passes are broad and exploratory. Others are tightly focused on a patch, feature, regression risk, or piece of player feedback.
I separate issues by player impact and test purpose rather than treating every observation as the same kind of bug. A broken save/resume state, unclear ability behaviour, missing button feedback, confusing class behaviour, and a balance concern all need different handling.
This helps the developer understand not only what happened, but why it matters, how likely a player is to encounter it, and whether it blocks release, affects presentation, or belongs in a later tuning pass.
🧰 Tools & Evidence Workflow
| Tool / Method | Used For |
|---|---|
| Android Test Device | Primary gameplay testing on the live Android platform. |
| Structured QA Notes | Capturing scope, test style, focus areas, results, regression status, and player-facing impact. |
| Patch Notes | Planning targeted regression passes around new fixes, features, changed systems, and known risk areas. |
| Screenshot Evidence | Capturing UI, menu, readability, reward, shop, class, and progression issues where visual evidence was useful. |
| Video Evidence | Recording gameplay behaviour, transition flow, ability handling, mobile interaction issues, and regression outcomes. |
| Developer Handover | Summarising what was tested, what passed, what failed, what needed fixing, and what should be checked in future builds. |
✅ What This Case Study Shows
- Provided ongoing embedded QA support across eight Android QA passes, with more testing expected as the game continues to evolve.
- Used player-focused exploratory testing to identify visible issues affecting normal Android gameplay sessions.
- Performed patch-note targeted regression testing to verify fixes, features, class behaviour, menu behaviour, and save/resume stability.
- Tested new content including Druid, Fisher, class-specific reward pools, ability behaviour, relic persistence, and updated UI feedback.
- Separated functional bugs, usability concerns, readability issues, progression risks, regression failures, and smoke test outcomes clearly.
- Supported a solo indie developer with practical QA feedback that helped keep the project stable, readable, and player-ready across updates.
Need QA Support for Your Game?
If you have a demo, Android build, update, or release candidate that needs structured QA support, message me with the platform, build, and what you need checked.
📎 Disclaimer
This page documents credited QA work completed by Kelina Cowell for portfolio and recruitment purposes. I am not the developer or publisher of Dungeon Raiders. All trademarks, logos, screenshots, clips, and game assets remain the property of their respective owners. Internal QA details, bug logs, and private developer communications are not published here. If anything needs to be removed or credited differently, please contact me and I’ll update it promptly.