Exploratory testing
Learn the build, follow unexpected behaviour and create room for edge cases that scripted paths can miss.
Capability 01 · QA & Playtesting
QA that helps the team decide what happens next.
Finding a defect is only part of the job. I want to understand its impact, reproduce it clearly and give the team enough context to choose the right response.
Evidence loopObserve → reproduce → prioritise → change
Capability coverage
Testing the build from more than one angle.
I connect system behaviour, player behaviour and production context in the same QA pass. I might start by exploring broadly, then narrow the focus as the evidence points me towards the questions that matter most.
Feature and regression checks
Compare intended behaviour with what the build actually does, then confirm whether changes resolve the issue without creating another.
Gameplay and UX
Assess controls, feedback, comprehension, pacing, agency and the moments where friction changes how the game feels.
Balance and progression
Test difficulty, party or build variation, rewards, progression gates and the conditions that can create exploits or dead ends.
Technical evidence
Capture build context, reproduction conditions, supporting media and enough detail for the team to investigate efficiently.
Readiness and risk
Consider player impact alongside integrations, dependencies, accessibility, platform requirements and delivery pressure.
The working method
From build question to useful next action.
I keep the context attached to every finding. What was the build meant to prove? What did the player or system actually do? Can someone else reproduce it, understand the impact and make a clear decision?
Test
Define what the build or feature needs to prove.
Observe
Watch player behaviour and capture what actually happens.
Reproduce
Turn observations into reliable technical evidence.
Prioritise
Separate noise from issues that affect experience or delivery.
Recommend
Give the team a useful next action, not just a problem list.
Evidence in practice · Dolven
Depth, variation and player behaviour across a beta build.
I combined exploratory and focused testing across multiple party compositions to examine pacing, balance, Steam systems and technical friction — then documented the findings clearly for the development team.
- Coverage
- Eight solo playthroughs with different party compositions.
- Focus
- Gameplay, pacing, Steam integration, achievements, leaderboards and technical issues.
- Handoff
- Written notes, screen recording, spreadsheets and clear reproduction steps.
Evidence in practice · Ka-Pow City
A playtest finding became a production decision.
What I like about this example is how clearly the evidence travelled. Early enemy behaviour proved the core loop, testing exposed a reliability problem around level geometry, and that player-facing issue became a concrete technical change.
- Observation
- Enemies could get stuck or lose the player around environmental geometry.
- Impact
- Combat flow and pressure became inconsistent across the level.
- Change
- The team integrated Unity NavMesh and tuned subway traversal.
The handoff
What useful QA gives the team.
I don’t want to hand a team a wall of comments. I want to give them a compact, inspectable path from what happened to what they should consider doing next.
Reproducible evidence
Build context, clear steps and the conditions that make the issue visible.
Player impact
A plain-language account of how the finding changes clarity, control or flow.
Prioritised next action
Enough context for the team to weigh severity, delivery risk and the right response.
Collaborative context
Communication that respects design intent, technical constraints and the reality of shipping the work.
For hiring teams
Useful where player experience, technical behaviour and production reality meet.
I’m at my best in work that needs curiosity without chaos. I enjoy exploring a build, isolating what matters and bringing people enough context to have a useful conversation — while keeping both the player and the reality of delivery in view.
- Game QA and exploratory playtesting
- QA and development hybrid contribution
- Bug reproduction, evidence and documentation
- Gameplay, balance and progression feedback
- Production-readiness and risk awareness
QA & playtesting FAQ
A few questions you might have before we talk.
I’ve answered them plainly and linked to the case studies and testing notes where you can dig deeper.
01What do you look for when you test a game build?
I look at functional behaviour and player experience together: bugs, controls, clarity, pacing, progression, balance, edge cases, integrations and anything that could put delivery at risk. I’ll always shape the test around what the build needs to prove at that stage.
02How do you turn playtesting feedback into action?
I connect the test objective to what I observed, when it happened, how it affected the player or project, and what I think the team should consider next. My goal is to hand over evidence people can use, not a loose pile of opinions.
Read the Ka-Pow City QA example →03Do you test more than bugs?
Definitely. I also pay attention to comprehension, player agency, pacing, difficulty, progression, balance, feedback and replayability. A feature can be technically correct and still miss the experience the team is trying to create.
04What might you include in a QA handoff?
It depends on the project, but I can include build context, clear reproduction steps, categorised findings, impact and priority reasoning, written notes, screen recordings, spreadsheets and a recommended next action. I want the handoff to make the team’s next conversation easier.
See the Dolven testing approach →05Can you work directly with developers on technical issues?
Yes. My hands-on experience with Unity, Unreal, programming, source control, 2D animation workflows, 3D and level implementation gives me useful technical context. I can describe what I’m seeing clearly, ask better questions and help narrow down where the problem lives.
Explore the development capability →06Where can I see your QA approach in practice?
Start with Ka-Pow City to see how testing changed production priorities, then read my Dolven note for a structured multi-session beta playtest. I’ve also included project case studies, public development sources and playable builds so you can check the evidence for yourself.
Browse the QA Blog →