What XR functional QA actually covers

Functional QA in XR is not a 2D test plan with a headset strapped on at the end. The product is the interaction: where the user’s hands, head, and playspace are, what the runtime thinks those are, and what the app does when those disagree. QualityReality exists to test that loop on XR platforms. This note is a working definition of the functional pass - what to cover, what to write down, and when to stop calling a build “playable.”

What “works as intended” means in a headset

On a phone or PC, a button either responds or it does not. In XR, the same feature can pass a checklist and still fail a session. Gaze-select that works in a seated tutorial can miss in a standing room-scale scene. A grip that feels correct at arm’s length can clip through a tool when the user leans in. A teleport that is legal in an empty lobby can strand the player behind a baked occluder in the first real level.

Treat the intended behaviour as a session outcome, not a control mapping. For each feature, write: the user goal, the input method (controller, hand, gaze, voice, physical button on the HMD), the expected world change, and what happens if tracking, collision, or the runtime interrupts the gesture. If you cannot state the interrupt path, the case is not finished.

Input, two-handed work, and in-world UI

Cover every advertised input path, not only the one the designer uses. That includes dominant-hand swap, sitting versus standing, and the fallback when a hand or controller drops out. Two-handed actions (nocking, stretching, carrying a tray, bracing a tool) need cases for order of grab, release of one hand, and re-grab after a tracking hitch.

World-space UI is a functional problem before it is a visual one. Menus that sit too close to the face, follow the head with lag, or ignore the user’s height will be reported as “unusable” even when every click target is technically hittable. Test open, select, back, close, and re-open after locomotion. Test the same menu while the player is moving, while they are looking away, and after they have snapped-turned. If the title supports both hand-tracking and controllers, do not assume the same panel distance works for both.

System overlays - guardian/boundary, runtime pause, battery, and permission prompts - are part of the functional surface. The app must resume without eating the next input, duplicating a projectile, or leaving a grab locked on.

Tracking loss, playspace, and recovery

XR functional QA spends real time on failure, because users will. Walk through: brief tracking loss, longer loss, lighting change, a guardian resize, a recenter, and a complete session interrupt (headset removed, runtime crash, app switch on a passthrough device). The pass is whether the app restores a coherent state: player pose, held objects, in-progress craft, and audio.

Playspace assumptions hide bugs. A seated onboarding that never re-asks for standing space, a locomotion scheme that assumes a 2×2 m area, or a tutorial that cannot be completed in a smaller room will fail in the field even if the office volume was empty. You do not need a named device matrix to test this: you need cases that force the app to explain, clamp, or fail clearly when the space is smaller than the design assumed.

Session flow: boot, pause, save, quit

A functional pass that only exercises the combat loop is incomplete. Start from a cold boot. Confirm first-run permissions, comfort/locomotion defaults, and that the user can reach a stable idle without being thrown into a moving scene. Then: pause from every major activity, resume, quit to the runtime home, and re-enter. If the title has a save or a profile, test it after a mid-gesture interrupt, not only at a checkpoint.

Cross-app and OS behaviour belongs here when the platform allows it: notifications, screen-recording indicators, and passthrough toggles. None of these are “edge cases” for XR; they are how people actually use a headset.

Writing cases that a second tester can run

XR bugs that cannot be reproduced will not be fixed. A useful functional report states the HMD class (standalone, tethered PCVR, or mixed-reality passthrough), the input mode, locomotion setting, whether the user was seated or standing, and the last three actions - not a novel. Video of the pose plus a log line beats a paragraph of adjectives.

Prefer scenario cases over isolated clicks: “complete the first craft from a cold boot with hand tracking only,” “finish the onboarding in a seated playspace,” “re-grab the quest item after a tracking loss.” Those scenarios catch sequence bugs that a button list will not.

When the same title also ships as a conventional game on PC, iOS, Android, Web, TV, XR and other emerging platforms, those interaction checks sit beside GameCloud’s functional game testing on the core services catalogue. QualityReality owns the XR-specific interaction surface; GameCloud, a 16-year-old company, owns the broader game QA types around it.

What this pass does not replace

Functional QA will not tell you whether the frame time holds in a dense scene, whether the store SKU installs on last season’s runtime, or whether a locomotion scheme is comfortable for a motion-sensitive player. Those are separate passes - performance, compatibility, and comfort - and mixing them into one “headset smoke” produces reports nobody can act on.

A prototype that ‘runs’ is not the same as a build that can survive game validation from first boot through a complete session. If the XR slice is meant to ship inside a larger game, hand the frozen interaction list to validation with the known stubs named. Do not make QA discover that the grab is a placeholder.

Close

QualityReality tests XR and Metaverse applications for function, not for a marketing trailer. If you have an AR, VR, or mixed-reality build and need a structured functional pass, write to Sales@GameCloud-Ltd.com with the platforms, input modes, and what you consider a complete session.