Nothing Strange Here - QA Case Study
🧾 Project Overview
- Game: Nothing Strange Here
- Studio: Dandelion Developers
- Role: External QA Tester
- 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
Introduction
This case study covers my QA work on the Steam Next Fest demo for Nothing Strange Here, developed by Dandelion Developers.
The project was approaching a public demo release deadline for Steam Next Fest. After speaking directly with the producer, I focused my testing on recently added and higher-risk demo systems, including the Map, Time Skip, Journal, quest progression, and outcome validation.
This page focuses on the QA workflow, testing strategy, and decision-making behind the project. Rather than listing individual findings, it shows how testing was planned, how coverage was prioritised, how updates were verified, and how ongoing QA support contributed to the project's development.
| Game | Role | Demo Release |
|---|---|---|
| Nothing Strange Here | External QA Tester | Steam Next Fest June 2026 demo |
🎯 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.
🧭 QA Focus
- Quest progression
- Objective guidance
- Journal and Map synchronisation
- Time Skip behaviour
- Save/Load persistence
- Early demo flow
📄 Reporting
- Google Docs QA report
- Google Sheets bug log
- Structured session tracking
- Linked screenshots
- Unlisted YouTube evidence videos
- Discord delivery to producer
🔍 Validation
- New systems testing
- Quest state validation
- Player guidance review
- Boundary and collision checks
- Performance and stability sweep
- Exploratory chaos testing
🛠️ 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. Video evidence was uploaded as unlisted YouTube clips, while screenshots were linked through Google Drive inside the bug log. This gave the team both a high-level summary and detailed evidence they could review quickly and action from.
| Workflow Area | How It Worked |
|---|---|
| Communication | Direct Discord DMs with the producer to confirm scope, priorities, and report delivery. |
| Planning | I focused the pass around the new and less-tested demo systems identified by the team. |
| Findings | Findings were documented in a structured bug log, capturing reproduction steps, expected and actual results, impact assessment, priority, repro rate, supporting evidence, status tracking, and additional QA notes. |
| Reporting | A detailed QA report gave the team a clearer overview of what was tested, what worked, what needed attention and suggested improvements. |
| Evidence | Issues were supported with linked screenshots and unlisted YouTube videos where useful. |
| Delivery | The report and bug log were sent directly to the producer before the deadline. |
🧠 How I Decided What to Test
The test plan was built around risk. Since the team was preparing for Steam Next Fest, I prioritised recently added systems that had received less internal testing and were closely tied to player progression, navigation, and understanding.
The producer mentioned that the newer systems had received the least internal testing, so those became the main focus of the pass. I tested the Map, Journal, Time Skip, quest progression, objective tracking, save/load behaviour, NPC behaviour, player exploration, and time-based events both individually and as connected systems.
Risk-Based Focus
I prioritised systems most likely to affect demo readiness: Map, Journal, Time Skip, quest flow, objective updates, event cues, and save/load persistence.
Player-Facing Perspective
I looked beyond whether progression technically worked and focused on whether the player understood what was happening, where to go next, and why a system behaved the way it did.
📈 Testing Lifecycle
The QA pass followed a structured progression from quest validation and system interaction testing through to stability, boundary testing, and exploratory stress checks.
| Stage | Focus | Purpose |
|---|---|---|
| 1. Quest and Time Skip interaction | Tested quest progression across Time Skip, NPC schedules, Journal updates, and follow-up quest states. | Check whether time-based progression remained functional and understandable. |
| 2. Save/Load persistence | Tested save/load during active quests, after objective completion, and after quest completion. | Confirm quest state, Journal entries, NPC state, and completion state persisted correctly. |
| 3. New systems interaction | Tested Quest, Journal, Map, NPC progression, progression updates, and Save/Load together. | Identify cross-system issues that might not appear when testing systems in isolation. |
| 4. Journal robustness | Tested Journal navigation, readability, tabs, scrolling, rapid opening/closing, and Journal to Map switching. | Check whether the Journal remained stable, accurate, and usable during normal and repeated use. |
| 5. Exploratory chaos testing | Stress-tested NPCs, interactables, Journal, Map, Pause menu, noticeboard, phone booth, Save/Load, and objective markers. | Look for crashes, stuck UI, duplicate interactions, input conflicts, or unexpected broken states. |
| 6. Performance and stability sweep | Observed FPS, load times, menu transitions, Save/Load behaviour, audio, visual stability, and UI behaviour. | Check whether the demo remained stable during normal play and transitions. |
| 7. Boundary and out-of-bounds testing | Tested world edges, fences, buildings, barriers, water, cliffs, slopes, stairs, and recovery behaviour. | Check for clipping, stuck locations, progression bypasses, terrain falls, and blocked-route confusion. |
🔍 QA Areas Covered
The pass covered functional behaviour, player guidance, system communication, accessibility-related discoverability risks, and general demo stability.
Quest Progression
- Quest acceptance
- Objective updates
- NPC interaction state
- Quest completion state
Journal & Map
- Objective text accuracy
- Map marker behaviour
- Quest and location synchronisation
- Save/Load consistency
Time Skip
- Time advancement
- NPC schedule changes
- System availability
- Player feedback clarity
Player Guidance
- Tutorial instruction clarity
- Objective signposting
- Progression event discoverability
- Objective marker visibility
Stability & Persistence
- Save/Load persistence
- Quest state recovery
- Main menu transition
- Crash and softlock checks
Boundaries & Navigation
- Out-of-bounds attempts
- Collision checks
- Fall and water recovery
- Blocked route review
📌 Player-Facing Risks Identified
The main findings centred on player-facing clarity rather than major technical failure. The issues I identified were mostly related to how the demo communicated objectives, system states, progression cues, and next steps to the player.
For public portfolio purposes, I have grouped the findings by theme rather than publishing the internal bug log, repro steps, or evidence links.
| Finding Category | Player-Facing Risk |
|---|---|
| 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 & 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 be looking 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 & World Interaction | Some world elements needed review to confirm whether they were intended as usable routes, blocked paths, or decorative geometry. |
✅ Systems Validated
The QA pass also confirmed several important areas were working well. This was useful because demo readiness is not only about identifying defects. It is also about confirming which systems are stable enough to rely on for public release.
Quest and Save Stability
- Quest progress persisted correctly across Save/Load.
- Objective state and completed quest state were preserved.
- No duplicate rewards or progression resets were observed.
- NPC state and world state remained stable after reloads.
Performance and Boundaries
- Gameplay remained stable at around 60 FPS during normal play.
- Save operations were effectively instant.
- Load times remained under 2 seconds during testing.
- No out-of-bounds access, stuck locations, or terrain falls were found.
🤝 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 the 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 producer's priorities while still matching my intended second-pass approach. The focus was to provide coverage information, evidence-backed findings, and clear player impact notes across demo-critical systems before the public Steam Next Fest deadline.
The focus of this work was demo readiness: testing the new 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 | 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, systems validated, and overall 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 for my QA contribution to the demo.
✅ What This QA Project Shows
- Planned a focused QA pass around newer demo systems the producer identified as needing more coverage.
- Used risk-based testing to prioritise quest progression, player guidance, Journal and Map behaviour, Time Skip interactions, and save/load persistence.
- Tested both individual systems and how those 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 that were important for demo readiness even where progression remained technically functional.
- Confirmed key areas of stability, persistence, performance, and boundary behaviour during the tested scenarios.
- Worked directly with the producer and kept the QA approach aligned with the project’s 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 Is Strange. 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.