Turn design promises into checks
game-qa derives evidence from six playable results: launch, actual rendering, effective input, a closed core loop, a designed outcome and restart. Record intended and tested runtimes separately; browser success does not verify another device.
Original greenhouse: inspect pipes, obtain a key, operate valves and decide whether to show a record. Set expectations first: order affects reserve; an unshown record remains unknown to the gardener; failure and restart restore custody and investigation state.
Focus on this game’s promises instead of screenshots for every click. Character appeal or emotional impact can be experience feedback, not automatic conclusions from a successful run.
Cover six results through a complete path
| Check | Example action | Observe |
|---|---|---|
| Launch | Open the delivered candidate | Correct version in recorded runtime |
| Render | Enter greenhouse | Scene, text and required options readable |
| Input | Select pipe inspection | Intended action accepted |
| Core loop | Investigate, obtain key, operate | State and feedback connect |
| Outcome | Reach success or designed failure | Reserve, plants and responses match choices |
| Restart | Start again from outcome | Declared initial state restored; action possible |
Record expectations before observed results. Keep version, runtime, initial state, inputs and final state, plus a seed when randomness exists. Review motion at normal speed; slow playback locates faults rather than proving ordinary experience.
Original failure: the picture resets but state does not
Paper failure: restart returns the picture to the greenhouse entrance, but the inventory retains the key and the log says inspection is complete. The second run skips investigation and operates a valve. The following explicit teaching state and sequence belong to this original example, not skill defaults or a game already tested.
Initial state: six water units, key held by the gardener, pipes uninspected and record contents unknown to the gardener. This design requires inspection and borrowing before valve operation. The wrong valve sequence spends three units and fails; the correct sequence spends two and waters the plants. Reading the record is not showing it to the gardener.
| Replay step | Expected result |
|---|---|
| Launch, inspect pipes, borrow key | Inspection complete, key with player, six water units remain. |
| Use the example’s wrong valve sequence | Three units remain; failure occurs; record contents stay unknown to the gardener. |
| Restart from failure | Entrance restored, six units, key with gardener, uninspected and unshown. |
| Attempt operation without inspection or borrowing | Reject unmet prerequisites without water consumption or a success outcome. |
| Inspect and borrow again, then use the correct sequence | Four units remain and watering succeeds; without showing the record, the gardener still cannot reveal its contents. |
If step three retains the key and inspection flag, report the exact failure-to-restart fault with actual initial state, inputs, final state and the corresponding view. Repair object custody, resources, knowledge and quest stage rather than deleting the displayed word “complete.”
Replay the failure and rejection path after repair, then the unshown-record success route as an adjacent countercase. Both share the greenhouse initial state but check restored prerequisites and character knowledge separately. Fluent dialogue grants no permission: revealing an unseen document remains a failure. The actual candidate’s rules, inputs and quantities must come from its own approved design. This worksheet explains choosing checks and cannot fill in a PASS for it.
Replay the fault, then a neighboring path
Keep the reproducible version, initial state and input sequence. After repair, replay the failing route and a neighboring choice sharing earlier state. Assert observable outcomes rather than merely internal function calls.
Copy or asset replacement may preserve state meaning. Changing variable semantics, nodes or action effects requires migration or explicit rejection of incompatible old saves or logs; choose the project-appropriate handling.
Use the project’s existing verification entry and include regressions in that flow rather than producing duplicate pass reports. Record unrun items and material gaps. Every claimed result must refer to the current candidate and its evidence.
FAQ
Should playtesters know the original novel?
Use both familiar and unfamiliar players when the audience includes both. Ask separate questions about adaptation recognition and whether the game works on its own.
Do it with the skill
Use $game-qa to verify the current candidate in its selected runtime from launch through core action, outcome and restart. Derive expectations from design promises and retain minimal evidence, including the reproduced fault and neighboring counterexample in the existing verification flow.
Read the method: Minimal evidence and discriminating paths · Actual candidate and six results