RESIDUUM - Ongoing QA Case Study
🧾 Project Overview
- Game: RESIDUUM
- Developer: Will Nightingale
- Role: Embedded QA Tester
- Testing dates: Ongoing from May 2026
- Status: In development, with ongoing QA support across closed builds
- Platform: PC / Windows 11
- Current focus: Playtest feedback triage, onboarding clarity, early progression testing, usability review, reproduction planning, and future regression support
- Coverage note: This page reflects QA work completed so far and will be updated as additional passes are completed.
🎯 My QA Role
I provide ongoing QA support for RESIDUUM, an in-development PC psychological horror game by Will Nightingale.
The work completed so far has focused on turning closed playtest feedback into useful QA priorities, then testing the early game from a first-time player perspective. This included onboarding clarity, early progression, navigation readability, interaction feedback, note readability, and player-facing usability.
This is a living case study. It reflects the QA work completed so far and will be updated after future passes, including debug-build testing, issue reproduction, regression checks, final-area playtesting, and later full-game playtest support.
Developer Feedback
Developer feedback will be added here once approved for public use.
🧠 Triage & Planning
- Grouped playtest feedback
- Identified duplicate reports
- Flagged softlock risks
- Separated bugs from clarity issues
- Prepared focused test priorities
🎮 Testing Focus
- Onboarding clarity
- Early progression flow
- Navigation readability
- Interaction feedback
- Note and clue readability
🔁 Ongoing Support
- Reproduction testing
- Debug-build testing
- Regression validation
- Final-area playtest support
- Future full-game playtest support
🛠️ Workflow & Communication
I offered support as a Systems QA Tester to help with functional, exploratory, and regression testing focused around gameplay systems, progression flow, usability, and validating recent fixes or changes.
After access was arranged through the closed playtest process, I began by reviewing current feedback and then completed an initial onboarding and early progression QA pass. I kept private findings internal during development and organised the work into clear documents, summaries, bug logs, evidence links, and follow-up notes for the developer.
As the reproduction workload expanded, I also identified that repeated setup would become inefficient without basic debug support. I suggested QA-focused debug tools such as area teleport, key item unlocks, monster disable or god mode, unstuck/reset options, and quick checkpoint reloads to make future reproduction and regression testing more efficient.
| Workflow Area | How It Worked |
|---|---|
| Communication | Ongoing Discord communication with the developer around testing support, closed build access, internal findings, future QA needs, and planned debug-build support. |
| Feedback Triage | Community playtest feedback was reviewed, grouped, prioritised, and converted into focused reproduction areas and developer clarification questions. |
| Hands-On Testing | Initial testing focused on first-time player onboarding, early progression, navigation clarity, interaction readability, note readability, and usability. |
| Evidence | Findings were supported with structured bug log entries, screenshots, video evidence, repro notes, player impact, priority, and status tracking. |
| Process Improvement | Debug-tool recommendations were raised to reduce repeated setup time and improve future issue reproduction efficiency. |
| Future Support | Further QA support is planned around the final gameplay area, a dedicated debug build, reproduction testing, and later regression validation. |
🧭 Onboarding & Early Progression Pass
This pass was carried out on the closed PC playtest build on Windows 11, focusing on onboarding and early progression from a first-time player perspective.
I tested without using Discord hints or community discussion during progression, so I could see what the game communicated naturally through objectives, signage, environmental guidance, tutorial prompts, readable notes, and player feedback.
This was not intended as a full-game systems, combat, performance, or late-game validation pass. Those areas are better suited to later focused testing, especially once debug tools are available for faster setup and repeatable issue reproduction.
| Test Area | Observed Focus |
|---|---|
| Onboarding clarity | Checked whether tutorial prompts, objective direction, room signage, and early progression guidance supported a first-time player. |
| Navigation flow | Reviewed whether route changes, blocked paths, map information, and environmental rerouting remained understandable during early play. |
| Interaction clarity | Observed whether doors, locks, notes, environmental objects, and player feedback communicated enough information during exploration. |
| Note readability | Checked whether readable notes and highlighted clue text remained clear and usable during normal play. |
| Early-game usability | Identified friction around recovery, information retention, route interpretation, and player confidence during first-time progression. |
⚠️ Current Player-Facing Risk Areas
Testing found that the onboarding structure generally worked: objectives, room signage, lock/key feedback, tutorial popups, environmental rerouting, and creature pressure all helped guide progression while keeping the horror tension intact.
The main risks came from the supporting systems around that progression. The objective usually made sense, but recovery, route readability, area naming, note review, and reading-mode clarity sometimes added extra strain during early play.
| Risk Area | Player Impact |
|---|---|
| Recovery and hard-lock risk | Players may become unable to recover during onboarding, forcing them to close the game and breaking first-session confidence. |
| Route readability | Players may understand the objective but struggle to identify the intended physical route when paths are blocked, rerouted, or unclear. |
| Area naming and map clarity | Objective wording and map guidance need to work together clearly, otherwise players may think progression is blocked or that they have missed a required step. |
| Information retention | Progression clues that cannot be reviewed later can increase memory load during stressful exploration or after interruptions. |
| Reading-mode readability | If highlighted clue text becomes harder to read in reading mode, the feature risks reducing clarity instead of improving it. |
🤝 Working With the Developer
The testing scope was shaped through direct conversation with the developer. We discussed the current playtest feedback, the need to keep findings internal during development, and the most useful way I could support the project at this stage.
Rather than jumping straight into broad testing, I suggested starting with the existing playtest reports first. This allowed me to group repeated feedback, identify higher-risk issues, and turn scattered player comments into clearer reproduction areas before continuing with hands-on testing.
After the onboarding and early progression pass, I shared a structured QA summary, bug log, screenshots, video evidence, and follow-up notes through an organised Drive folder. The aim was to give the developer useful findings without creating extra admin or burying the important risks in noise.
As the next stage of testing moves toward issue reproduction, final-area playtesting, and future updates, the developer has confirmed that a dedicated debug build is planned. This should make repeated setup, positioning checks, progression validation, and regression testing much more efficient.
The focus of this work is ongoing QA support: turning playtest feedback into useful QA signal, testing early player understanding, identifying player-facing risks, and keeping the developer updated with clear, evidence-backed findings.
🧰 Tools & Evidence Workflow
| Tool / Method | Used For |
|---|---|
| PC / Windows 11 Testing | Testing the closed playtest build from a player-facing perspective. |
| Structured QA Summary | Summarising scope, test style, focus areas, strong areas, friction areas, outcomes, and potential improvement areas. |
| Bug Log | Capturing issues by charter, title, area/system, repro steps, expected result, actual result, player impact, priority, repro rate, evidence, status, and notes. |
| Screenshot Evidence | Supporting readability, UI, objective clarity, map guidance, and player-facing usability observations. |
| Video Evidence | Recording behaviours that required movement, input, collision, or recovery context to understand clearly. |
| Discord Communication | Discussing testing access, internal handling of findings, developer priorities, debug-build needs, and future playtest support. |
| Google Docs / Drive | Organising internal QA summaries, logs, linked evidence, and developer handover materials. |
✅ What This Case Study Shows
- Provided structured QA support for an in-development PC psychological horror game following closed playtesting.
- Reviewed community playtest feedback and grouped reports into clearer QA priorities, repeated themes, risk areas, and developer clarification requests.
- Completed an onboarding and early progression pass without external hints to preserve a genuine new-player perspective.
- Tested onboarding clarity, objective communication, navigation flow, route readability, interaction feedback, note readability, and early usability.
- Identified player-facing friction around recovery, route interpretation, information retention, reading-mode readability, and early progression confidence.
- Suggested debug-build tools to improve future reproduction testing, reduce repeated setup time, and support more efficient regression validation.
Need QA Support for Your Game?
If you have a demo, PC build, closed playtest, update, or release candidate that needs structured QA support, message me with the platform, build, and what you need checked.
📎 Disclaimer
This page documents QA work completed so far by Kelina Cowell for portfolio and recruitment purposes. RESIDUUM is still in active development, and this case study will be updated as further QA passes, debug-build testing, reproduction testing, regression testing, and playtest support are completed. I am not the developer or publisher of RESIDUUM. All trademarks, logos, screenshots, clips, and game assets remain the property of their respective owners. Internal QA details, full bug logs, private developer communications, closed playtest materials, and NDA-protected findings are not published here. If anything needs to be removed or credited differently, please contact me and I’ll update it promptly.