# Run a playtest you can learn from

BerryBlox creator resources
Edition 1.0 · November 4, 2026

Choose a question, record normal play, and turn observations into a small, testable next change.

Take away: A useful playtest record and an ordered repair list.
Beginner · 7 min read

Original BerryBlox editorial worksheet. You may copy, adapt, and use it in your own projects and team handoffs. Linked sources and third-party materials retain their own terms.

Download this Markdown file and fill it in with any text editor. Your notes stay in your copy; this worksheet does not upload or save them to BerryBlox.

## Choose 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](https://create.roblox.com/docs/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.