Nothing Strange Here - QA Case Study
🧾 Project Overview
- Game: Nothing Strange Here
- Studio: Dandelion Developers
- Credited Role: Development Quality Assurance
- Testing date: 29 May 2026
- Version tested: 0.5.5
- Build: 23434843
- Graphics API: DX11 Default
- Platform tested: Windows PC
- Public demo: Steam Next Fest June 2026
🎯 My QA Role
My role was to provide structured external QA support ahead of the public Steam Next Fest demo release. The team had already completed internal testing, so I focused on areas where an independent QA perspective could add the most value: quest flow, player guidance, system interaction, progression confidence, and early demo clarity.
The producer specifically highlighted that the newly added systems had received the least internal testing. Based on that conversation, I built a focused QA pass around Map behaviour, Time Skip, Journal updates, quest progression, Save/Load persistence, objective guidance, boundary testing, and general stability.
🧠 Triage & Planning
- Confirmed producer priorities
- Focused on newer demo systems
- Prioritised progression risks
- Planned system interaction checks
- Prepared demo-readiness coverage
🎮 Testing Focus
- Quest progression
- Objective guidance
- Journal and Map behaviour
- Time Skip behaviour
- Save/Load persistence
🔁 Ongoing Support
- Issue validation
- System interaction testing
- Boundary checks
- Stability review
- Demo release support
Developer Feedback
“Kelina gave very precise and clear documents with all problems that she encountered. She highlighted several problems to player guidance and progression which we had completely missed.”
🛠️ Workflow & Communication
Communication was handled directly through Discord DMs with the producer. This kept the workflow lightweight and suitable for a small indie team working towards a fixed public demo deadline.
I delivered a detailed Google Docs QA report and a Google Sheets bug log. Screenshots were linked through Google Drive, and video evidence was uploaded as unlisted YouTube clips so the team could review issues quickly.
| Workflow Area | How It Worked |
|---|---|
| Communication | Direct Discord DMs with the producer to confirm scope, priorities, and report delivery. |
| Planning | The pass focused on newer and less-tested systems identified by the producer as higher priority. |
| Findings | Issues were documented with repro steps, expected and actual results, impact, priority, repro rate, evidence, status, and QA notes. |
| Reporting | A QA report summarised what was tested, what worked, what needed attention, and suggested improvements. |
| Evidence | Findings were supported with linked screenshots and unlisted YouTube clips where useful. |
| Delivery | The report and bug log were sent directly to the producer ahead of the Steam Next Fest deadline. |
🚀 Demo Readiness Testing
This pass focused on whether the Steam Next Fest demo remained stable, understandable, and progression-ready across the newer systems that had received less internal testing.
I tested the Map, Journal, Time Skip, quest progression, objective tracking, Save/Load behaviour, NPC behaviour, player exploration, time-based events, boundary behaviour, and stability both individually and as connected systems.
| Test Area | Observed Focus |
|---|---|
| Quest progression | Checked quest acceptance, objective updates, NPC interaction state, follow-up steps, and completion state. |
| Journal & Map | Tested objective text, marker behaviour, quest/location synchronisation, menu behaviour, and usability during progression. |
| Time Skip | Checked time advancement, NPC schedule changes, system availability, feedback clarity, and quest interaction after time changes. |
| Save/Load | Tested quest state, Journal state, NPC state, world state, completion state, and reload behaviour during and after objectives. |
| Boundary & stability checks | Reviewed world edges, barriers, water, cliffs, slopes, stairs, menu transitions, FPS, load times, and recovery behaviour. |
⚠️ Current Player-Facing Risk Areas
The build tested was stable overall. The main risks were not major technical failures, but player-facing clarity issues around objective guidance, progression communication, discoverability, and system feedback.
| Risk Area | Player Impact |
|---|---|
| Objective guidance | Players could lose direction if the next step was not clearly communicated after a quest interaction or progression event. |
| System communication | Some system states or limitations needed clearer feedback so players could understand whether behaviour was intentional, unavailable, or progression-gated. |
| Quest and progression flow | Quest information and player expectations needed to stay aligned as objectives advanced, NPC states changed, or events triggered. |
| Discoverability | Important progression cues needed to be noticeable enough during normal exploration, not only when the player happened to look in the right place. |
| Accessibility observations | Some feedback relied on visibility, audio awareness, or attention timing in ways that could affect players with hearing, processing, or attention-related difficulties. |
| Navigation and world interaction | Some world elements needed review to confirm whether they were intended as usable routes, blocked paths, or decorative geometry. |
🤝 Working With the Producer
The testing scope was shaped through direct conversation with the producer. We discussed two useful directions: validating any incoming playtester feedback and running a structured pass on the newer demo systems.
Since available community feedback was limited at that stage, I continued with the planned structured pass on systems the producer identified as needing more coverage. This kept the work aligned with the team's priorities while still providing coverage information, evidence-backed findings, and clear player impact notes before Steam Next Fest.
The focus of this work was demo readiness: testing the newer systems most likely to affect player understanding, validating that core progression remained stable, and reporting issues in a way the team could act on quickly before Steam Next Fest.
🧰 Tools & Evidence Workflow
| Tool / Method | Used For |
|---|---|
| Windows PC | Primary test platform for the Steam demo build. |
| OBS Studio | Recording gameplay sessions and capturing issue evidence during testing. |
| Microsoft Clipchamp | Editing longer recordings into shorter evidence clips for easier developer review. |
| YouTube Unlisted | Private storage and sharing of evidence clips through unlisted video links. |
| Google Drive | Screenshot evidence storage, linked directly from the bug log where needed. |
| Google Docs | QA report covering test focus, build information, key findings, validated systems, and demo readiness observations. |
| Google Sheets | Structured bug log with charter ID, system area, repro steps, expected result, actual result, impact, priority, repro rate, evidence, status, and notes. |
| Discord | Direct communication with the producer, including scope discussion, clarification, and report delivery. |
🚀 Release Outcome
The QA report and bug log were delivered directly to the producer ahead of the deadline. The report highlighted both stable areas and player-facing risks that could affect first-time demo players.
The build tested was stable overall, with the main concerns focused on guidance, discoverability, and system communication rather than crashes or major progression failure.
Following public release, I was credited under Development Quality Assurance for my QA contribution to the Steam Next Fest demo.
✅ What This Case Study Shows
- Provided structured external QA support for a public Steam Next Fest demo.
- Planned a focused QA pass around newer demo systems the producer identified as needing more coverage.
- Tested quest progression, player guidance, Journal and Map behaviour, Time Skip interactions, Save/Load persistence, boundaries, and stability.
- Reviewed how individual systems interacted during quests, NPC behaviour, exploration, time-based events, and Save/Load.
- Reported issues through a structured QA report and bug log with evidence links, repro information, priority, and player impact notes.
- Identified player-facing risks important for demo readiness, even where progression remained technically functional.
- Worked directly with the producer and kept the QA approach aligned with the Steam Next Fest deadline.
Need QA Support for Your Game?
If you have a demo, early 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 Nothing Strange Here. 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.