Dungeon Raiders - Ongoing Embedded QA Case Study
🧾 Project Overview
- Game: Dungeon Raiders
- Studio: Loom & Lore Interactive Games
- 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”
Introduction
This case study covers my ongoing embedded QA work on Dungeon Raiders, an Android mobile game by Loom & Lore Interactive Games.
My work on the project has continued across multiple builds, updates, fixes, and new content drops. I have completed eight QA passes so far, covering player-focused exploratory testing, targeted regression, fix validation, save/resume persistence, class behaviour, UI stability, and Android usability.
This page summarises the scope and structure of that ongoing QA support without publishing internal bug logs, private developer communication, or sensitive build details.
| Game | Role | Status |
|---|---|---|
| Dungeon Raiders | Head of QA | Released Android game with ongoing QA support |
Studio 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.”
🎯 My QA Role
My role is to provide ongoing QA support for Dungeon Raiders across live updates, new features, regression cycles, and player-facing gameplay checks. The work combines exploratory testing, targeted regression, fix validation, smoke testing, persistence checks, and mobile usability review.
Because this is a small indie workflow, the aim is not to create unnecessary production overhead. The value comes from clear test focus, structured reporting, useful evidence, fast validation, and practical feedback that helps the developer prioritise fixes and improvements.
🧭 QA Focus
- Android mobile gameplay
- UI and overlay stability
- Gameplay readability
- Class and ability behaviour
- Save and resume persistence
- Player-facing usability
📄 Reporting
- Structured QA passes
- Regression notes
- Patch-note targeted verification
- Player-impact explanations
- Screenshot and video evidence
- Clear handover summaries
🔁 Validation
- Fix validation after updates
- Regression checks around changed systems
- New content smoke testing
- Save/resume checks
- Menu and transition checks
- Release and update support
🛠️ Workflow & Communication
Testing is carried out as an ongoing embedded QA workflow, with each pass shaped around the current build, latest patch notes, known risk areas, and player-facing behaviour observed during Android gameplay.
The work 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. |
🧠 How I Decided What to Test
The test strategy changed depending on the build. Early passes focused on player-facing stability, readability, transition flow, menus, overlays, and mobile interaction behaviour. Later passes became more targeted, focusing on patch notes, regression fixes, class changes, save/resume behaviour, new content, and combat feedback.
I prioritised issues that could affect normal Android players: confusing UI states, unclear class mechanics, broken resume behaviour, unreliable menu flow, missing feedback, progression friction, shop and economy problems, and anything that could make the game feel unstable or unfinished.
Player-Focused Exploratory Testing
I tested the game as a normal Android player would experience it, focusing on menu flow, active gameplay clarity, transition behaviour, readability, touch interaction, Game Over flow, restart behaviour, and usability under pressure.
Targeted Regression & Patch Verification
When new builds were provided, I tested specific fixes and patch-note changes, including class abilities, relic persistence, save/resume behaviour, reward pools, shop interactions, button feedback, and menu functionality after resume.
📈 Testing Lifecycle
The QA work has evolved across multiple passes. Each pass had a defined purpose rather than repeating the same coverage blindly.
| Stage | Focus | Purpose |
|---|---|---|
| 1. Initial player-facing stability | Menu and overlay stability, relic/menu functionality, gameplay readability, transition flow, and mobile interaction behaviour. | Identify visible issues likely to appear during standard Android gameplay sessions. |
| 2. UI and readability regression | Recent UI/readability fixes, first-time player clarity, rushed-player behaviour, Game Over flow, restart flow, and player-facing presentation. | Check whether the game felt stable, understandable, and presentable enough for more players to see it. |
| 3. Run-state and economy coverage | Win, lose, menu, reset behaviour, save/persistence, gold, Soul Shards, shop purchases, upgrades, relics, unlocks, and Level 1 setup comparison. | Assess whether core run flow and player progression systems behaved consistently. |
| 4. Combat and progression regression | Single sword attacks, Cleave behaviour, Warrior setup, weapon damage upgrades, level-up rewards, Character Sheet access, Legendary Weapon milestone, no-move board refresh, and shop behaviour. | Verify whether recent combat, stat, UI, reward, and progression fixes worked correctly. |
| 5. Save/resume and persistence checks | Save/resume progression, Android backgrounding, no-move board refresh, Character Sheet scrolling, duplicate shop prevention, Warrior Thorns access, and shop item persistence. | Check whether the game preserved important player state correctly across mobile resume behaviour. |
| 6. New class and patch-note smoke testing | Druid, Fisher, seven-class selection screen, class-specific level-up pools, relic resume regression, button visuals, pressed states, combat feedback, audio changes, and skull-death sound regression. | Smoke test new content while also checking regression risks introduced by the update. |
| 7. Ability and menu regression verification | ENTANGLE behaviour, Cursed Blade description, empty-board ability handling, End Run feature, menu reopen behaviour, and Druid/Fisher weapon art persistence after resume. | Confirm specific patch-note fixes and ensure key menu and resume behaviours remained stable. |
| 8. Ongoing update support | Further regression, fix validation, new feature testing, class behaviour checks, UI review, and Android gameplay stability. | Continue supporting Dungeon Raiders as the game receives additional updates and improvements. |
🔍 QA Areas Covered
The QA work has covered both functional behaviour and player-facing experience. This includes systems that affect whether players understand what is happening, trust the game state, and feel confident continuing a run.
UI Stability
- Menu behaviour
- Overlay persistence
- Button feedback
- Pressed-state visuals
Gameplay Readability
- Combat feedback
- Class HUD clarity
- Board icon readability
- Reward display clarity
Mobile Behaviour
- Android interaction stability
- Rapid tapping behaviour
- Backgrounding and resume
- Touch-based menu flow
Combat Systems
- Sword attack behaviour
- Cleave behaviour
- Thorns behaviour
- Ability handling
Progression & Economy
- Gold behaviour
- Soul Shards
- Shop purchases
- Upgrade persistence
Regression Support
- Patch-note verification
- Fix validation
- Relic resume checks
- New content smoke tests
🤝 Working With the Developer
Dungeon Raiders is a live, evolving project, so the QA support needs to be flexible. Some passes are broad and exploratory. Others are tightly focused on a specific 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 crash, a broken save/resume state, unclear ability behaviour, missing button feedback, confusing class onboarding, 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.
The focus of this work is ongoing Android QA support: identifying player-facing risks, validating fixes, checking regressions, testing new content, and helping the developer keep Dungeon Raiders stable and readable across updates.
🧰 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. |
🚀 Current Outcome
So far, I have completed eight QA passes on Dungeon Raiders, covering Android gameplay stability, UI/readability fixes, class behaviour, combat systems, save/resume persistence, shop and economy interactions, new content smoke testing, and patch-note targeted regression verification.
The work has helped support ongoing updates by identifying player-facing risks, validating fixes, checking for regressions, and giving the developer clear information before wider player exposure.
I am credited in the released game as Head of QA Kelina Cowell, reflecting my ongoing QA contribution to the project.
✅ 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.