5.4 Assist if required in tests and user trials

Testing and user trials are related but different

The criterion says to assist, if required, in tests and user trials. Testing is a broad quality activity that checks whether the prototype behaves as intended. User trials, often called playtests in games, involve people using the prototype so the team can observe player experience, usability, engagement and problems. Both are needed because a build can be technically correct but confusing, or enjoyable but unstable.

Common prototype tests include:

• Smoke testing: does the build launch and can the main loop be reached?
• Functional testing: do controls, interactions, UI, enemy behaviours, triggers and win or fail states work?
• Regression testing: did a recent change break something that previously worked?
• Compatibility testing: does the build run on target operating systems, input devices and hardware profiles?
• Performance testing: what happens to frame rate, loading, memory and responsiveness in representative scenes?
• Asset integration testing: do imported models, textures, rigs, animations, audio and UI assets appear correctly and efficiently?
• User trials or playtesting: can intended players understand, use and respond to the prototype as expected?

Define goals first

Do not run a user trial just to 'see what happens'. Set trial goals. Examples include: determine whether first-time players understand the objective without explanation; test whether combat difficulty is appropriate; compare two camera settings; identify motion discomfort in a movement system; or check whether players notice a visual affordance.

Clear goals determine the method. If you need usability evidence, observation and task completion are important. If you need preference evidence, a short questionnaire may help. If you need performance evidence, capture device specifications and build metrics. If you need accessibility direction, include participants with relevant needs where possible and use respectful, voluntary processes.

Ethical and legal considerations

If trials involve identifiable people, handle personal information responsibly. Tell participants what the trial is for, what data is collected, how it will be used, and whether their gameplay, voice or screen will be recorded. Obtain consent before recording. For minors, obtain appropriate parent or guardian consent and follow organisational requirements.

WHS also applies. Plan comfortable session length, breaks, safe equipment setup and warnings for flashing imagery, loud sounds, horror content, motion sickness risk or VR use. Do not pressure participants to continue if they feel unwell.

Workplace example

A Newcastle studio developing a 3-D VR maintenance trainer schedules a user trial with apprentices. The goal is to test whether users can identify hazards and complete a lockout sequence. Because VR can cause discomfort, the team limits session length, provides a seated rest area, explains how to stop at any time, sanitises shared equipment and records only necessary observations.

Common mistakes

Avoid using only the development team as testers. They know too much. Also avoid collecting more personal data than needed. Prototype testing should produce useful evidence without creating unnecessary privacy, safety or ethical risk.

What assistance may involve

You may not lead every test, but you can assist by preparing materials, setting up builds, writing scenarios, observing sessions, logging issues, managing files, or helping testers access the prototype. In a Diploma-level role, assistance should be organised and informed by the evaluation criteria.

Start with a test plan. For a prototype, the plan can be concise but should include:

• Purpose of the test or trial.
• Build version and branch.
• Target platform and hardware requirements.
• Participant profile, if user trial participants are involved.
• Test scenarios or tasks.
• Data to collect.
• Roles and responsibilities.
• Schedule and session length.
• Known risks and safety controls.
• Exit criteria, such as when the trial is complete or must be stopped.

Design scenarios and tasks

A test scenario is a realistic situation in which the prototype is used. For example, 'Start from the main menu, enter the training level, pick up the scanner, locate three hidden energy leaks and return to the exit.' Tasks should match the trial goal and avoid leading the participant too much. If you want to test whether the player can discover an interactable object, do not tell them exactly where it is.

For functional tests, expected results should be explicit. Example: 'When the player presses interact within two metres of the terminal, the terminal UI opens, input focus changes to the UI, player movement is disabled, and closing the UI returns control to the player.' This level of detail helps testers identify actual defects rather than vague impressions.

Schedule and critical path

Testing depends on build readiness. Do not schedule a user trial before smoke testing confirms the build can be completed. Use production scheduling techniques such as milestone calendars, sprint boards and dependency checks. Leave time after implementation for packaging, upload, installation, account access and troubleshooting. Online learners often underestimate upload time and platform permissions.

If a critical path feature is unstable, plan an alternative. For example, if the final save system is not ready, the trial may start from a prepared scene. If multiplayer is not stable, test the core mechanic in a local single-player harness first. Be clear about what evidence the workaround can and cannot provide.

Roles

In a user trial, useful roles include facilitator, observer, technical support and note-taker. The facilitator gives instructions without coaching. The observer records behaviour. Technical support resolves build access problems. The note-taker captures timings, comments and issue IDs. In small teams one person may cover multiple roles, but avoid overloading the facilitator because it leads to missed observations.

Common mistakes

Do not change the build mid-trial unless the test plan allows it. Mixed build versions produce unreliable data. Also avoid writing tasks that test memory of instructions rather than the game. The prototype should reveal whether its own design communicates effectively.

Running consistent sessions

When assisting in tests and user trials, consistency matters. If one participant receives detailed hints and another receives none, their results cannot be compared. Prepare a standard introduction that explains the trial purpose, consent, session length, stop conditions and basic controls only where appropriate. If the goal is to test control discoverability, do not give a full control tutorial first.

Before each session:

1. Confirm the build version.
2. Reset settings, save state and level state.
3. Check input devices, audio, display and recording tools.
4. Confirm participant consent and comfort.
5. Note hardware specifications if relevant.
6. Start observation and timing records.

For online trials, provide clear access instructions. Test download links, passwords and installation steps before the session. Have a backup communication channel in case screen sharing or voice chat fails.

Facilitate without distorting results

A facilitator should not teach the participant how to win unless the test requires it. Use neutral prompts such as 'Please keep saying what you are thinking' or 'What are you trying to do now?' Avoid leading prompts such as 'Did you notice the glowing door?' because they contaminate the evidence. If a participant is stuck, follow the test plan. You may record the time, provide a standard hint after a defined period, then note that help was required.

Record what happens

Good observations are specific. Write 'Participant attempted to jump to the red platform four times, then looked around for another route for 35 seconds' rather than 'Participant was confused.' Capture defects separately from design observations. A defect is a failure of the build to behave as intended, such as collision not triggering. A design issue may be that the intended behaviour is working but players misunderstand it.

If using video or screen recording, ensure consent and secure storage. Label files with participant codes rather than unnecessary full names. Store issue logs in the agreed project area.

Safety and contingencies

Escalate immediately if a participant feels motion sickness, distress, eye strain or discomfort, especially in VR or intense 3-D motion. Stop the session if required. For content such as horror, violence or emergency simulations, warn participants beforehand and respect withdrawal.

If the build crashes, record the exact steps, hardware, logs and build version. Do not simply relaunch and pretend it did not happen. Crash evidence is important for prototype evaluation.

Example

During an online trial of a Unity 3-D puzzle prototype, a tester cannot open the build on a Mac because the file is blocked by operating system security settings. The technical support person records the compatibility issue, provides the approved alternative video walkthrough for that session, and flags that Mac distribution needs a separate test before endorsement.

Data quality affects decisions

Assisting with tests and user trials includes managing the data that comes out of them. Poorly organised test data leads to poor evaluation. A useful defect or observation record should allow another team member to understand, reproduce and prioritise the issue.

For a defect, record:

• Title and short description.
• Build version, platform and hardware.
• Steps to reproduce.
• Expected result.
• Actual result.
• Frequency, such as always, sometimes or once.
• Severity and impact.
• Screenshots, video, logs or crash reports.
• Related asset, script, scene or system.
• Owner and status.

For a user observation, record:

• Participant code or profile category, not unnecessary personal details.
• Task or scenario.
• Behaviour observed.
• Verbal comment, if relevant.
• Time or location in the prototype.
• Possible interpretation, clearly separated from fact.
• Link to criterion being tested.

Defect triage

Triage is the process of reviewing issues and deciding priority. A crash in the first minute is usually higher priority than a minor visual seam. However, repeated confusion by several participants may be more important than a rare physics glitch if the criterion is user-friendliness. Use the project criteria, severity and schedule impact to triage.

Technical evidence

Game engines often produce logs, profiler data and warnings. Learn to collect relevant evidence without drowning the team. For example, an Unreal or Unity log can help identify missing assets, script exceptions, shader compilation problems or memory issues. A profiler capture can support a performance issue. Asset integration evidence might include screenshots of a broken material, import settings, polygon counts relative to project guidelines, rig errors or texture compression settings.

Privacy and confidentiality

If recordings or notes identify participants, treat them as personal information. Use participant codes where possible, restrict access to the project team, and delete or archive data according to organisational requirements. Do not upload recordings of testers to public channels without explicit permission. If the prototype is under client or studio confidentiality, do not share builds, logs or videos outside approved systems.

Example

A Darwin team testing a 3-D underwater exploration prototype receives a report that 'the fish AI is broken'. The note-taker improves the issue: in build 0.5 on Windows laptop with integrated graphics, fish school freezes after the player collects the second sample; expected behaviour is continued avoidance; actual behaviour is all fish stop moving; reproduction 3 of 3; console shows null reference in FishSchoolManager. This issue can now be assigned and fixed.

Common mistakes

Do not mix participant preference data with confirmed defects. Also avoid deleting failed session data. Failed installs, crashes and access problems are valid evidence about readiness for broader trials or release.