Start Building

Lesson Goal

Lesson 13 gave you working desktop and web builds. Now you need confidence that players can actually complete the slice without blockers.

By the end of this lesson, you will:

  • run a compact but reliable QA checklist for your vertical slice
  • classify bugs by severity and reproducibility
  • produce clear known issues and release notes
  • make a practical go/no-go decision for your build

Step 1: Define your QA scope before testing

Do not test everything. Test what your promise requires.

For this course project, lock scope to:

  1. Main menu and onboarding flow from Lesson 10
  2. One full gameplay loop: movement, combat, reward, save/load
  3. One complete mission path with success and fail states
  4. Exported desktop + web build startup and completion

If a feature is outside this scope, mark it as post-course backlog instead of treating it as a release blocker.

Step 2: Build a lightweight test matrix

Use a matrix simple enough to maintain in one file:

Area What to verify Pass condition
Boot flow App opens, menu renders, no fatal errors Reach playable state in under 60 seconds
Core controls Move, attack, interact, pause Inputs respond consistently in all target builds
Combat loop Enemy engage, damage, death, reward No soft lock; encounter resolves cleanly
Save/load Save, quit, relaunch, continue Progress persists with no duplicate entities
UI and readability HUD updates, prompts clear, contrast readable Critical info remains legible during combat
Performance sanity No major frame collapse in target encounter Stable and acceptable frame pacing

Keep this as your "must-pass" baseline. Anything outside it is nice-to-have for v1.1.

Step 3: Use reproducible bug report format

Bad bug reports waste your final week. Use one format for every issue:

  1. Title: short and specific
  2. Build/version: exact version string
  3. Environment: platform + quality setting
  4. Steps to reproduce: numbered, minimal
  5. Expected vs Actual
  6. Severity and Frequency
  7. Evidence: screenshot/video/log excerpt

Example:

Title: Pause menu can trap player input after loading checkpoint
Build: 0.14.0-web
Environment: Chrome 123, Windows 11
Steps:
1) Start new game
2) Open pause menu
3) Load checkpoint
4) Close menu
Expected: Player can move and attack
Actual: Input ignored until scene reload
Severity: High
Frequency: Always
Evidence: Console log + clip

Step 4: Severity triage for fast decisions

Use a clear severity rubric:

  • Critical: crash, data loss, or progression blocker
  • High: major feature broken but workaround exists
  • Medium: visible quality issue that does not block progress
  • Low: polish issue, typo, minor visual inconsistency

Release rule for this slice:

  • 0 Critical bugs
  • 0-2 High bugs only if clear workaround is documented
  • Medium/Low can ship if added to known issues

This keeps your release decision objective instead of emotional.

Step 5: Verify known high-risk areas

Prioritize checks where indies usually break late:

  1. Checkpoint reload path from Lesson 11
  2. Particle-heavy encounters from Lesson 12
  3. Web hosting path and MIME setup from Lesson 13
  4. Input fallback behavior (keyboard/gamepad focus and pause/resume)

If these pass, your real-world failure risk drops dramatically.

Step 6: Prepare release notes and known issues

Create two short files near your build output:

  • RELEASE_NOTES.md
  • KNOWN_ISSUES.md

Release notes should include:

  • build version
  • what's new
  • what changed since last test
  • where to report feedback

Known issues should include:

  • issue summary
  • workaround if available
  • severity
  • planned fix window (for example: "next patch")

Players forgive imperfections when communication is clear.

Step 7: Run a final go/no-go meeting (even solo)

Use this checklist:

  1. Must-pass matrix complete
  2. No unresolved critical bugs
  3. Build artifacts are archived (desktop zip/web folder)
  4. Release notes + known issues published
  5. Rollback or hotfix plan exists

If any must-pass item fails, delay and fix. A one-day delay is cheaper than a broken release.

Pro tips

  • Timebox your final QA pass (for example: 2 focused sessions) to avoid endless retesting.
  • Test with one "fresh eyes" player who has never seen the project before.
  • Always test one clean install path, not only your dev machine state.

Common mistakes

  • Treating every medium bug as a launch blocker.
  • Skipping reproducible steps and relying on memory.
  • Shipping without known issues documented.
  • Testing only editor runs and ignoring packaged builds.

FAQ

How many testers do I need for a vertical slice?
Two to five focused testers is enough if reports are structured and scoped.

Should I fix all medium bugs before release?
Not always. If core loop is stable, document medium issues and patch them after launch.

Can I ship if web build has one minor UI issue?
Yes, if it does not block core loop and you add a workaround in known issues.

Mini challenge

  1. Run your test matrix on both desktop and web.
  2. Capture at least three bug reports using the exact template above.
  3. Produce RELEASE_NOTES.md and KNOWN_ISSUES.md for version 0.14.0.

Summary

  • QA works best with scope + matrix + triage, not endless ad hoc testing.
  • Reproducible bug reports speed fixes and reduce confusion.
  • A simple go/no-go checklist protects you from shipping unstable builds.

Next lesson is your final presentation pass. Continue to Lesson 15: Portfolio Packaging and Showcase, where you turn this build into a polished case study and recruiter-friendly project page.

For deeper troubleshooting patterns, review Common Godot Pitfalls and Fast Fixes.

Owl Drink Coffee artwork by Dribbble artist