AR Testing for a Web Application

Rock Paper Reality is an Augmented Reality design agency that helps startups and Fortune 500s harness the full value of AR. The company has been working with businesses in the marketing, education, entertainment, and retail fields for over a decade. The scope of services it provides includes web and app development, content creation, consultation, and AR gifting solutions. Rock Paper Reality regularly delivers AR products that are proven to drive brand awareness and business growth.

The client was looking for a QA team that could test small web AR projects used mostly for entertainment purposes. In general, it was a standard request for AR testing. Our team was aware of the testing scenarios necessary to check and the particularities of the AR technology.

As for the project-specific details, the team needed to figure out several important things before the start of testing:

• object placement;
• sizes of objects;
• animation specifics;
• object movement;
• interaction with objects;
• audio accompaniment.

AR testing is challenging since it is complicated to describe a correct input. When interacting with an application, a QA engineer uses inputs they think software should be getting and matches them with correct outputs. Therefore, it is significant to have documentation that describes at least the latter.

Testing on estimates was chosen as a collaboration model. The AR projects we received for testing were small and not very frequent, but each required rapid testing on various devices.

It was agreed that QA engineers would log the results in the client’s Jira. Our team decided to use the checklist Rock Paper Reality shared with us as the basis for testing. We also agreed to run additional tests that weren’t on the list but the QA specialists considered essential.

So, the working process went like this:

1. We prepared a testing estimate for a few initial projects, committing to check each in up to three days after receiving.
2. Since all the projects were almost identical in terms of size and difficulty, the teams agreed to work based on this scheme.
3. The client’s team provided their checklist for testing. We added several more checks QA engineers considered necessary.
4. The QA team executed the planned tests and logged the detected bugs in Jira.