Lesson 9: Quality Assurance & Testing

You have a playable build with code, art, and audio. The next step is to treat it as a product: define what "working" means, catch bugs early, and run a small QA pass so you do not ship with avoidable surprises. This lesson walks you through test planning, bug tracking, and a practical QA workflow for a solo or small indie team.

What You'll Learn

By the end of this lesson you will be able to:

• Define a simple test plan aligned with your scope (features, platforms, and priorities)
• Track bugs and issues in one place so nothing gets lost
• Run a focused QA pass (functional, regression, and basic compatibility)
• Prioritize what to fix before launch and what can wait for a patch
• Document your testing process so you can repeat it for future builds

Why This Matters

Skipping QA leads to launch-day crashes, broken controls, and negative reviews. You do not need a full QA department; you need a clear list of what to test, a way to record issues, and a few hours of structured play. A small amount of planning makes your build more reliable and builds trust with players and partners.

Step 1: Define Your Test Plan

Before you play through the game randomly, write down what you will test so you cover the essentials and do not forget edge cases.

Core features

• List every major feature that must work for launch: movement, combat, menus, save/load, options, etc.
• For each feature, note 2–3 key scenarios (e.g. "Start new game", "Load save", "Change volume and confirm it persists").
• Mark platforms you support (PC, Mac, web, mobile, console) so you know what to test where.

Critical paths

• Happy path: New game to first win or completion (or main loop). Play it start to finish at least once per build.
• Save/load: Save in the middle of a level or run, quit, relaunch, load. Confirm state is correct.
• Settings: Change resolution, fullscreen, volume, controls; restart game and confirm settings persist.
• Quit and resume: Quit from menu and in-game; relaunch and confirm no crashes or corrupted state.

Edge cases and stress

• Input: Every control (keyboard, mouse, gamepad, touch if applicable). Unplug/replug gamepad; try odd key bindings.
• Bounds: Walk to level edges, fall off the world, trigger every death condition. Ensure no softlocks.
• Performance: Play for 15–30 minutes; check for memory growth, frame hitches, or audio glitches on a mid-range target device.

Pro Tip: Put this in a simple checklist (spreadsheet or doc). One row per test case, columns: Feature, Scenario, Pass/Fail, Notes, Build version. Reuse it for every build so you run the same set of checks.

Common mistake: Testing only the "fun" path. Boring paths (menus, options, save/load, quit) are where many launch bugs hide.

Step 2: Set Up Bug Tracking

You need one place to log issues so they do not vanish from memory or chat.

Lightweight options

• Spreadsheet: Columns such as ID, Title, Severity (Critical/Major/Minor), Steps to reproduce, Build, Status (Open/Fixed/Deferred). Simple and good for solo or tiny teams.
• Notion, Trello, or Airtable: Same idea with a bit more structure; you can add labels, assignees, and links to builds.
• GitHub/GitLab issues: If you already use them for code, create a "Bug" label and a short template (steps, expected vs actual, build/commit). Keeps bugs next to the repo.

What to capture per bug

• Title: One line describing the issue (e.g. "Game crashes when loading save from main menu").
• Steps to reproduce: Numbered list so anyone (or future you) can repeat the bug.
• Expected vs actual: What should happen vs what does happen.
• Build/version: So you know which build the bug was seen in.
• Severity: Critical (blocks play or launch), Major (big feature broken), Minor (polish, typo, small glitch).
• Status: Open, In progress, Fixed, Deferred (e.g. post-launch patch).

Pro Tip: When you fix a bug, add a short "Fix" note or link to the commit. That helps when the same issue reappears or when you need to write patch notes.

Common mistake: Vague reports like "game broke". Always write steps to reproduce; it saves hours when you come back to fix it.

Step 3: Run a Focused QA Pass

Use your test plan and run through it methodically. One pass per build is enough for indie scope if the checklist is good.

Functional pass

• Execute each test case in your plan. Mark Pass/Fail.
• For every failure, log a bug with steps and severity.
• Do not skip "boring" tests (menus, options, save/load).

Regression pass (after you fix bugs)

• Re-test the areas you changed, plus the critical path (new game to completion or main loop).
• Re-run any test that failed last time to confirm it is fixed and nothing else broke.

Compatibility (if you support multiple platforms)

• Run the critical path and main features on each platform (e.g. Windows, Mac, web, or mobile).
• Note platform-specific bugs (resolution, input, performance) in your tracker.

Pro Tip: Time-box your QA (e.g. 1–2 hours per build). When time is up, stop and triage: fix critical and major first; defer minor and polish to a patch if needed.

Common mistake: Playing randomly without a checklist. You will miss whole features or platforms.

Step 4: Prioritize What to Fix Before Launch

You will find more issues than you can fix. Triage so launch stays realistic.

Fix before launch

• Critical: Crashes, progression blockers, save corruption, game-breaking bugs on main path.
• Major: Core features broken (e.g. controls, main mechanic, purchase flow if you have one). Fix if you have time.

Defer to patch

• Minor: Typos, small visual glitches, rare edge cases that few players will hit.
• Nice-to-have: Performance tweaks, extra polish. Schedule for post-launch if needed.

Pro Tip: Maintain a "launch blocker" list: only bugs that must be fixed for day one. Everything else goes into a backlog. That keeps scope clear and avoids last-minute panic.

Common mistake: Trying to fix every bug before launch. Ship with known minor issues and patch them; players prefer a working game with small flaws over endless delays.

Step 5: Document Your Process

A short testing doc helps you and any future collaborators.

Include

• Test plan summary: What you test (features, platforms, critical path).
• How to run a build: Where to get the latest build, how to install or run it.
• Where bugs live: Link to your tracker or spreadsheet.
• Triage rules: What counts as critical/major/minor and what you fix before launch vs in a patch.

Pro Tip: Add a "QA" or "Testing" section to your project doc or README. When you onboard a helper or contractor, they can follow the same process.

Mini-Challenge

By the end of this lesson:

1. Write a test plan with at least 10 test cases covering: critical path, save/load, main menu, options, and one edge case (e.g. unplug controller, quit mid-level).
2. Choose a bug tracker (spreadsheet or issues) and log format (title, steps, expected vs actual, severity).
3. Run one full QA pass on your current build using the plan; log every failure as a bug and mark severity.
4. Triage: Mark 1–3 issues as "launch blocker" and the rest as "patch" or "backlog".

Share your test plan structure or one lesson learned from your first QA pass in the community so others can reuse the idea.

Troubleshooting

What's Next

In Lesson 10: Marketing Preparation & Branding you will define your game's identity and prepare assets and messaging so you can talk about your game consistently and attract players before and at launch.

For more on testing and QA, see our Game Testing and QA Track and the Help section on common game dev issues. Bookmark this lesson and reuse your test plan for every new build so quality stays under control.