Requests and responses
Test valid and invalid input, authentication boundaries, required fields, precision, identifiers, status handling and documented error behaviour.
Acceptance criteria
Define “ready” before
the launch review.
A playable round is only one test. Production acceptance should cover the contract, money path, repeated requests, game rules, fairness evidence, limits, browser behaviour and the operational records needed to investigate an exception.
Core test groups
Build one evidence pack across product, engineering and operations.
Run the agreed cases in the intended environment and retain enough information to reproduce a failure without relying on screenshots alone.
Money-path correctness
Verify debit, credit, insufficient balance, duplicate delivery, timeout, retry and reconciliation behaviour against the operator’s ledger.
Game-rule outcomes
Cover normal, boundary and invalid player choices; confirm the visible result, backend record and settlement describe the same round.
Reproducible evidence
Capture commitment and reveal inputs, reproduce selected outcomes and confirm that support can retrieve evidence by round identifier.
Configuration boundaries
Check minimum and maximum inputs, currency precision, payout or exposure constraints and behaviour when configuration changes between sessions.
Player experience
Test supported viewport and browser targets, interrupted sessions, refresh and resume behaviour, localization, loading and clear error feedback.
Evidence and exit
A test passes only when the result is reviewable.
For each case, retain the test identifier, environment, game and configuration version, request or player action, expected result, observed result, round and transaction identifiers, relevant timestamps and the reviewer. Sensitive values belong in the approved test system, not in a marketing document.
Agree severity and exit criteria before execution. A critical money-path, authorization or reproducibility defect should remain visible in the launch decision. Lower-severity presentation issues can be accepted only with an owner, written rationale and follow-up date. Re-running a failed case should create new evidence rather than overwrite the original result.
- All required test groups have an accountable owner.
- Expected results are written before the final execution.
- Failures, retries and duplicate requests are tested deliberately.
- Round, wallet and support evidence can be correlated.
- Open defects and accepted exceptions are included in the launch record.
Game-specific cases should extend this baseline. Dice needs boundary choices; Plinko needs board and risk selections; crash formats need timed state and interrupted-session cases. Use the game decision pages to identify those format-specific questions.