Run a playtest you can learn from
Choose a question, record normal play, and turn observations into a small, testable next change.
A useful playtest record and an ordered repair list.
Completed example
Original fictional example. These are filled-in worksheet answers, not evidence of a built or tested game.
Can a new player find the orchard basket?
- Question
- Does the first objective lead a new player from spawn to the basket without a hint? This session does not assess the entire game's quality.
- Repeatable start
- Use the same build, spawn, camera direction, and empty inventory for each attempt. Record the test mode and input device.
- Illustrative observation
- Example only: the player collected fruit, returned to the clearing, and searched both side paths before noticing the basket behind a tree.
- Interpretation to check
- The basket may be hidden from the approach. The observation does not yet show whether the instruction, camera, or prop placement caused the search.
- Next repair
- Move only the basket into the approach sightline. Repeat from the same start and record the route; keep the old layout available for comparison.
Expected resultAn observation separated from its explanation, followed by one repair that can be checked without changing the whole scene.
Try it in your blank worksheetChoose one question and a repeatable start
Decide what this session can answer: can a new player find the first objective, recover from failure, or understand a purchase screen? Give the tester a goal without teaching the exact solution. Preserve the starting save state and build identity so another reviewer can repeat the case.
- The tester has permission to participate and to be recorded.
- The recording avoids personal chat, account details, and credentials.
- The build and test data can be safely restored without touching unrelated work.
- Question
- Build / date / reviewer
- Starting save state
- Task given to the tester
- Success signal / stopping condition
Pick the right test mode
In Studio, Test starts with an avatar; Test Here starts near the camera. Run simulates without an avatar, so it cannot demonstrate the normal player journey. Solo testing includes separate client and server simulations. Use multi-client tests for player interactions and record which mode produced each result.
Begin at the intended spawn for arrival and tutorial checks. Keep local simulation, a private Roblox session, and physical-device play as separate evidence. None of these should be silently inferred from a source review.
Source checked November 4, 2026: Roblox: Studio testing modes.
Record actions and outcomes, then review
Capture the player camera, relevant UI, and input context. Keep an unedited source recording when possible. Mark cuts and time compression in any shareable edit. If narration explains a result that is not visible, identify the supporting evidence separately.
During review, separate observation from interpretation. 'The tester reopened the menu three times' is an observation; 'the label was unclear' is a hypothesis to check. Do not invent time saved, frame rate gains, or satisfaction scores.
- One normal loop was attempted through completion.
- One meaningful refusal or recovery was attempted.
- Rejoin or respawn was checked where the feature persists state.
- Multiplayer behavior was checked where players affect one another.
- Timestamp / player action
- Expected visible cue and authoritative state change
- Observed outcome
- Evidence file
- Hypothesis / confidence / next check
Leave with a bounded repair list
Fix blockers to the player journey before decorative changes. Give each repair one owner, a concrete reproduction, and a pass condition. Retest against the same starting state and include the changed case that exposed the problem.
- Priority / issue / owner
- Smallest change to try
- Retest steps and required evidence
- Outcome: pass / fail / blocked / not tested
- Next session's question
Turn one observation into the next task
Select the earliest point where the player stalled. Give the next owner the timestamp, starting state, expected cue, and observed action. Ask them to propose one explanation and the smallest change that could challenge it.
Keep raw observations with the recording even if you later reject the hypothesis. A repair list is more useful when it explains which evidence led to each priority.
- Observation / hypothesis / proposed change / condition that would disprove it
Evidence and limits
This is a recording plan and review template. No playtest has been performed by downloading or completing the template. One session cannot prove production readiness, player retention, or commercial success.
Retain the actual build, source clip, failures, and test conditions. A cinematic, edited demo, or automated internal callback is not evidence of normal input or physical-device performance.