A Black-Box QA Checklist for a Browser Snake Game

A Black-Box QA Checklist for a Browser Snake Game
A small browser game is a good reminder that QA begins with observable contracts, not guessed framework details. I am treating this as a public-interface checklist, not source-code analysis.

Start with the player contract
For Snake Game, the visible contract includes immediate browser play, solo controls, a local second player, and an optional AI rival. Record what the screen promises before writing a test: food grows the snake; walls, bodies, and duel traffic create risk; restart should return a playable round.

Model the risky transitions
Test a round as states: ready, moving, collision, result, restart. At each boundary, verify that input affects the intended player and that the result state does not accept stale movement. In local mode, test WASD and arrow keys independently. In AI mode, repeat the check at Easy, Normal, and Hard without asserting private pathfinding logic.

Use a compact regression matrix
| Area | Check |

| --- | --- |

| Launch | Board is usable without an account prompt |

| Controls | A requested direction changes the correct snake |

| Collision | Wall or body contact ends the applicable round |

| Modes | Solo, local, and AI choices remain distinguishable |

| Recovery | Reload or restart yields a clean new state |

Preserve uncertainty
This checklist cannot prove performance, internal AI rules, or mobile behavior that was not observed. It gives a product team a stable first pass: describe the visible rule, trigger a state change, and capture the result. That discipline scales far beyond an arcade board.