Write observable test cases, generate named build and configuration combinations, record actual results and keep complete exports for retesting.
Record the build or commit, supported configurations, intended player journeys and release acceptance conditions. Identify high-impact failures such as lost progress, unusable controls, failed purchases or inability to finish a session. Choose coverage from those risks and observed device usage; do not infer it from a leaderboard percentile or retention rate.
For each task, record setup, data or save fixture, exact actions and expected behavior. Include normal completion and relevant failure/recovery paths. Give the test a short unique label for the matrix and keep its detailed instructions in the downloaded test note or your issue system. Name configurations that can actually be run together.
Enter target/build labels, configurations and test labels one per line in the matrix tool. Generate the cases and inspect them before testing. The tool supports up to 30 labels per dimension and 1,000 combinations per run; split a larger scope into named runs. Confirm every intended combination is present and that duplicated labels have been resolved.
For each case, execute the written procedure and set Pass, Fail, Blocked or Not applicable; leave unexecuted cases as Not run. Record reproduction notes, expected versus actual behavior, evidence/issue references and who ran the case. For timing-specific tests, convert the chosen FPS target only as a comparison interval and retain actual profiler evidence.
Create a new target label for a changed build and rerun the failed case plus related regression cases. Keep the original evidence and link the fix revision. Review remaining Not run, Blocked and Fail entries against release risks; assign owners and record the rationale for any accepted limitation.
Save the draft manually on the current browser and check the visible save outcome. Download all cases as CSV for review and a complete JSON backup for restoration; both exports include rows outside the current page. Keep the test procedures, evidence and release decision together with the build identity and next retest owner.
Loading your checklist…
Use observed results and retain exclusions as visible decisions.
| Result | Meaning |
|---|---|
| Not run | No execution result has been recorded |
| Pass | The written expected behavior was observed under this case |
| Fail | Observed behavior differed; record reproducible evidence |
| Blocked | A prerequisite prevented execution; name it and its owner |
| Not applicable | This combination is intentionally excluded; record why |
These fields make a defect useful to the person fixing it.
| Field | Details |
|---|---|
| Identity | Case label, build/commit, configuration and tester |
| Setup | State, save fixture, account type and prerequisites |
| Action | Steps and expected versus actual behavior |
| Evidence | Capture/log or issue reference, fix revision and retest result |
The generator enumerates your declared dimensions and records results. It does not execute the game, simulate load, estimate staffing, produce pairwise coverage or prove a release is defect-free.
Change the target label whenever a new build needs a fresh result.
Pagination is only a viewing aid. Use the complete exports to hand off cases and notes.