Testing AR/VR Apps for Performance and Comfort, Not Just Function

An AR or VR feature can pass every functional test case and still be a bad, or even physically uncomfortable, experience. These platforms introduce test dimensions that a typical web or mobile app simply does not have.

Frame rate is a correctness issue here, not just a performance one

Dropped frames in a VR headset do not just look rough; they can directly cause disorientation and nausea. Frame rate needs to be tested and held to a strict threshold, not treated as a nice-to-have performance metric.

Latency between movement and response matters more than usual

Any noticeable delay between a user's head or hand movement and what they see happen in the experience breaks immersion and can contribute to discomfort. This needs to be measured directly, not estimated from how the app feels to a tester after a few minutes.

Comfort testing needs real sessions, not quick checks

Many comfort issues (eye strain, disorientation, motion sickness) only appear after sustained use, not in a two-minute smoke test. Testing sessions long enough to resemble actual usage are necessary to catch these.

Spatial tracking accuracy needs its own scenarios

For AR specifically, how well virtual objects stay anchored to the real world as a user moves is its own category of bug. Drift or misalignment during movement needs dedicated test scenarios, not just a static placement check.

Test across a range of physical spaces and lighting

AR tracking and VR boundary systems behave differently in different room sizes and lighting conditions. A test plan limited to one controlled test room will miss issues that show up in a typical user's actual living room or office.