Testronic’s head of Pre-Production, Julian Mower, talks about the need to properly test VR, even if it isn’t gaming.
Games publishers and developers are perfectly positioned to help various other non-games businesses with their first steps into the world of VR.
Already there are numerous applications for VR outside of games and, despite these examples mostly having limited elements of traditional progression which may be expected in most games, the interactivity still needs to be tested extensively.
In fact, when we opened a dedicated VR testing lab at our Warsaw facility 15 months ago, it was already clear that VR experiences would transcend the games market and create opportunity for innovation across multiple industries.
You might ask yourself at this point: “Why is he telling me things that I have been reading about for years now?”
But the thing is, I meet and converse with people from other industries a lot and they often, through no fault of their own, don’t have an awareness of what they need to consider with regard to testing and managing some of the risks associated with creating and executing VR experiences.
While many big players have already recruited QA experts to manage their test, design and planning processes, VR is still a risky business proposition for small and medium players as the ROI is far from guaranteed in most cases.
Plus, there is a longstanding habit of leaving QA until the last minute, or generally under-estimating the effort and strategy required. Testing in VR brings additional challenges than regular content and for smaller companies the costs of internal teams for testing are prohibitively high.
Right now there is a lot of excitement around training applications in VR and it’s easy to see why. The costs of traditional training can be extremely high due to the equipment or space required.
A major coffee chain, for example, could use VR to teach a trainee barista how to use a Mastrena Espresso machine before they ever set foot in an actual shop. The long-term cost savings could be significant, but obviously there is a pretty high cost of entry to try and implement such a system and build it to the point where it works seamlessly.
Probably the biggest QA consideration in this scenario is how long the end-user is expected to stay in the experience with the HMD on their head and their resulting comfort levels. This can be even more of a challenge when trying to achieve a measurable goal, such as training staff or converting prospective customers to actual sales with product trials.
It was with some of these considerations in mind that we implemented a Simulation Sickness Assessment process to monitor symptoms experienced during testing. This isn’t an original concept in and of itself – there have been many neuroscientists developing these systems for decades, particularly for the aviation industry.
However, we have been adjusting the model we use for evaluating the impact of different oculo-motor and nausea related symptoms to establish a comfort level for experiences we are testing.
Oculus titles on the Rift and Gear VR require that comfort levels are provided when publishing through the official storefront and it can be very helpful to cite the largest sample of user data on comfort as possible.
When developing a VR experience and spending time within it, people can become more acclimatised and it becomes even more important to get fresh eyes and fresh brains involved before making the product available to end-users.
Gamers might be willing to put up with a bit of eye strain or dizziness after taking off the HMD, but it is harder to accept when you are training for an actual job in the real world.