🎲 Gaming & Gambling QA

Model answer

Server-authoritative means the server owns the canonical state of the game — positions, health, scores, inventory — and the client only renders what the server confirms happened. The client can predict and display locally for responsiveness, but if the server disagrees, the server wins. For QA, the practical implication is that every outcome I care about must be tested at the server layer, not just observed in the UI. I'd test that the server rejects impossible state transitions: a client reporting a health value above its maximum, a position delta that would require teleportation given the elapsed time, an item pickup when the client was out of range. I'd assert that when the client and server desync — network partition, clock drift — the server's version wins on reconnect and the client is corrected, not the server. The anti-pattern I'm guarding against is a server that accepts whatever the client sends, which turns every player into a potential cheater. I'd cover this at the API level, not just through the game client, because the attack surface is the server endpoint.

Model answer

I separate the two properties because they're different claims about different things. RTP is a distributional claim: over a large sample, the payout percentage should converge to the certified rate. I'd run a statistically large batch — say a million simulated spins — and assert the resulting payout rate falls within the agreed statistical tolerance band around the certified RTP (e.g. ±0.1%). I'd parametrise over volatility classes too, since low-volatility and high-volatility slots reach convergence at different sample sizes. I'd specifically verify the distribution of win categories — small wins, medium wins, jackpots — against the paytable, not just the aggregate percentage. The provably-fair side is a cryptographic transparency test: I verify that the seed committed before each spin, the client nonce, and the server salt combine via the published hash function to produce the stated outcome, and that any player can reproduce this independently with their session data. I'd test that a manipulated seed or nonce produces a hash mismatch, not a silently different outcome. These two tests answer different regulator questions: the distribution test proves the game is calibrated correctly; the hash test proves individual outcomes weren't tampered with after the fact.

Model answer

The attack surface is the server endpoint, not the game client, so I test via the API directly with a valid auth token but a crafted movement payload. I'd send a series of position updates: one at exactly the speed limit (allowed), one a fraction above (boundary — depending on inclusive/exclusive rule), and one at an impossible delta like 20x the limit. For each I assert the server's response — a reject code and a rollback to the last valid position, not a 200 or a silent clamp. I'd verify the server's authoritative position after the rejected call matches the pre-call state, so the forged delta had zero effect on canonical state. I'd test a sequence of small-but-compounding deltas that individually pass but cumulatively imply an impossible speed over a short window — teleport-in-steps is a common bypass attempt. I'd also assert the session is flagged for review on repeated violations, because anti-cheat is not just about per-request rejection but about pattern detection. Throughout I'm testing the server logic, not the client renderer — the client is explicitly not trusted.

Model answer

Responsible-gaming limits are a regulatory requirement, so enforcement must be at the server, not the UI. My starting point is calling the deposit or bet API directly with a valid auth token and bypassing the front-end entirely — if that succeeds over the limit, the UI protection is cosmetic. For each limit type — deposit, loss, wager, time — I test the boundary triple: one unit below the limit (allowed), exactly at the limit (allowed per the inclusive rule), and one unit over (rejected with a limit-exceeded code, never a 200 or 500). For cumulative limits I seed prior transactions so the next one crosses the threshold, and I assert the correct window: a daily deposit limit should reset at the regulated timezone's midnight, not UTC or the server's local time, so I test deposits that straddle the reset with a controlled clock. DST transitions are a specific trap — the reset window changes length by an hour twice a year, and a limit-tracking bug there is a regulatory breach. I'd also test the cool-off and self-exclusion states as separate conditions: a player in cool-off can view but not transact; a self-excluded player is fully blocked. All test accounts use synthetic identities only.

Model answer

Matchmaking has two separate correctness concerns: constraint satisfaction (are pairs within the allowed skill and latency range?) and edge-pool behaviour (does the system degrade correctly when the pool is small?). For constraint satisfaction I'd seed pools of players with known ratings across the allowed delta boundaries — at exactly the limit, just within, and just outside — and assert that pairings only happen within the permitted skill delta. I'd parametrise over the tolerance widening that typically kicks in after a player has waited too long, asserting the widening step is applied correctly and not too aggressively. For latency I'd simulate players in different regions and assert the matchmaker respects the configured latency threshold, not just skill, so a low-ping pairing in the same region is preferred over a cross-region pairing with a better skill delta. For edge-pool cases I test: an empty pool (no match found, player queued gracefully); a single player in a pool (queued or matched to a bot per the product rule, not matched to themselves); a pool where all players are in the same narrow rating band (matches efficiently); and a pool where the skill spread exceeds the tolerance (highest-priority waiter gets widened pairing first, not arbitrary). I'd also verify that the matchmaker never produces self-matches or duplicate-player-in-match conditions, and that the queue position and estimated-wait metadata are accurate under each pool state. This is orthogonal to server-authoritative state validation — I'm testing the pairing algorithm, not the game state that follows.

Model answer

Self-exclusion is a cross-product obligation, so I start by setting an exclusion in one product and asserting that every other product in the operator's portfolio also blocks that player — casino, sports book, and poker must all honor the exclusion, not just the one where it was set. Fail-closed under degraded conditions is the next concern: I stub the exclusion-check service to return a timeout or 503 and assert the gate defaults to blocked, not open — the system must not allow a bet or login when it cannot confirm exclusion status. Re-registration is a common bypass: I test that a player who self-excluded and creates a new account with different credentials but matching identity data (name, date of birth, address) is detected and blocked at the KYC stage. Location spoofing tests cover VPN IP, forwarded-header forgery, and GPS mock on mobile — I assert the server-side geo check rejects these rather than trusting client-reported location. Age gating uses synthetic identity documents with known ages — under threshold, exactly threshold, and over — and I verify the gate is enforced at account creation and at each transaction, not just once on signup. Every gate decision — allowed or blocked — must produce an audit log entry with the decision reason, actor, and timestamp, because the regulator may ask for evidence of any individual case.

Model answer

Settlement under disconnect has three failure-point windows that need separate test cases: disconnect before the settlement transaction starts, disconnect mid-transaction (after the bet is consumed but before the balance is credited), and disconnect after the transaction commits but before the acknowledgement reaches the client. For each I assert exactly one settlement record in the database and the correct ending balance — the disconnect window should not produce double-settlement or lost settlement. The mechanism I'm testing for mid-transaction safety is idempotency: the settlement operation must be idempotent so a retry on reconnect produces the same record, not a duplicate. I'd assert this by replaying the settlement request with the same idempotency key and checking the balance and record count. On reconnect, I assert the client receives the server's canonical state — not a cached client-side prediction — so if the result was a loss the player cannot reconnect and see a misleading pending-win state. For game state specifically, I'd also verify that any in-progress game (e.g. live dealer round, spin animation) is either completed deterministically or cleanly rolled back — no half-committed states where the game thinks it's still running but the bet is already settled. This is a stronger guarantee than 'retry works'; it's proving that the settlement is a transactional unit with exactly-once semantics.

Model answer

Virtual-currency integrity has two separate attack surfaces. The first is technical: a concurrent double-spend. I'd fire two simultaneous requests to spend or transfer the full balance from the same account and assert exactly one succeeds and one fails — not that both succeed (double-spend) and not that both fail (money destruction). The correct server-side mechanism is an atomic compare-and-swap or a database transaction with the right isolation level, and I test by controlling concurrency at the API layer, not through the game client. I'd also cover the zero-balance case: a transfer request when balance is exactly zero must be rejected, and a crafted negative-amount transfer (to move currency in reverse) must be validated and rejected server-side. The second surface is economic abuse. Chip-dumping — a player repeatedly losing intentionally to transfer chips to a confederate — should be detected and flagged; I'd test the detection rule by seeding the known collusion pattern (one account loses 10 straight hands to the same opponent beyond statistical chance) and asserting the system flags it for review. I'd also test carousel transfers: many small transfers between a ring of accounts that move value without triggering single-transfer limits. Every transfer must have a server-side audit entry, and over-threshold patterns must surface in the anomaly queue.

Model answer

The release question in a regulated gambling product is: 'can we prove the game is fair, the limits are enforced, and the regulator can audit every decision?' I'd define hard gates that unconditionally block shipping: first, the RNG and RTP certification gate — the outcome distribution must match the certified RTP within statistical tolerance across a large batch, and the provably-fair hash chain must be independently verifiable. Second, the responsible-gaming gate — all limit types (deposit, loss, wager, time) enforce at the API even under direct-API bypass, all resets happen at the regulated timezone boundary, and the cool-off and self-exclusion states block every product. Third, the geo, age, and self-exclusion fail-closed gate — these gates must default to blocked when the check service is degraded, VPN and location-spoof attempts are rejected, and cross-product exclusion is verified. Fourth, bet-settlement determinism — exactly-once settlement under disconnect at all fault-point windows, idempotency of the settlement operation, and balance correctness. Fifth, audit-log completeness — every gate decision, settlement, limit enforcement action, and exclusion check has an immutable log entry with actor, timestamp, and outcome. The deposit and withdrawal money rail is not in scope here; it inherits the Fintech gate strategy (reconciliation, idempotency, rounding, PCI) rather than being re-authored, so changes to the money layer don't need to be re-tested against the gambling gates independently. I'd layer for feedback speed: property tests for RTP distribution and rounding, contract tests for the RNG API and exclusion-check service, integration tests for limit enforcement and settlement, and a thin E2E covering the full bet → settle → balance → audit path. Every gate has an unambiguous pass/fail, and any red gate stops the release.