Сейчас большую популярность набирает такое направление в IT как дополненная реальность. И у тестировщиков этого направления появляется вопрос — как вообще к этому «зверю» подойти и с чего начать тестирование?

Что же вообще такое — «дополненная реальность»?

Дополненная реальность (или расширенная реальность, augmented reality — AR) — это система, которая совмещает виртуальное и реальное, и взаимодействует в реальном времени. Например, при отлавливании объекта (будь то картинка или координаты местоположения) на нашу реальность накладывается виртуальная реальность.

Теперь возникает вопрос — как это тестировать? Ответ неоднозначный, так как направление молодое, и подход к тестированию еще выстраивается. Я расскажу о своем подходе, согласно которому весь процесс можно разделить на 4 этапа.

1 этап.

Самое первое, с чего нужно начать, это определить в какой среде разрабатывается AR-приложение. И если у тестировщика есть навыки в этой среде, то он может развернуть тестовую площадку для тестирования методом white box («белого ящика»). Большое распространение имеет Vuforia, которая предоставляет свой комплект средств разработки (sdk). Есть sdk как для нативной, так и для кроссплатформенной разработки. Если ведется кроссплатформенная разработка на Unity, то тестировщику пригодятся знания в таких языках, как C# и JavaScript, а так же базовые знания работы в Unity. В тестировании понадобится веб-камера, которая будет служить аналогом камеры смартфона.

2 этап.

Необходимо определить, под какую систему разрабатывается приложение. Чаще всего это мобильное приложение (iOS, Android и т.п.), а это значит, что и часть тестирования у нас будет проходить по чек-листу для мобильного приложения. Этот чек-лист в себя включает:

1) смена ориентации экрана (вертикальное и горизонтальное позиционирование);

2) Уровень связи интернета (отличная постоянная связь, плохая постоянная связь, потеря связи, отсутствие связи);

3) Прерывания (звонок, смс, оповещение системы, сворачивание, спящий режим);

4) Заполненность памяти девайса (например, кэшем);

5) Расход заряда батареи.

3 этап.

Определение основной концепции приложения и дополнительных возможностей. Например, если у приложения есть возможность перехода в VR-режим (режим виртуальной реальности), то этот переход необходимо проверить. Так же надо учитывать, что нашему приложению может быть задан не один объект для отлавливания, а несколько, поэтому появляется необходимость протестировать, что произойдет, если эти объекты будут наложены друг на друга (будет ли крэш приложения или крэш отображения, или же приложение нормально обработает это событие). Еще приложение может запрашивать текущее местоположение, вот тут можно проверить:

1) выключено местоположение;

2) периодически включать/отключать местоположение;

3) подавать ложные координаты местоположения.

4 этап.

Дальнейшее тестирование будет проходить в свободной форме с проверкой различных позитивных и негативных кейсов функционала приложения. Хотелось отметить, что немаловажно было бы проверить приложение на юзабилити. Например, у приложения должны быть информационные блоки, где рассказывается о том, как приложение работает, и что необходимо для него. Если это не учитывать, то при выкладывании на App Store, например, ваше приложение может не пройти проверку модератора.

Автоматизация.

Что же касается автоматизированного тестирования, то тут мы сможем проверить в основном только дополнительные элементы приложения (меню, например), а не саму дополненную реальность. Так же авто-тестами можем влиять на само устройство: сворачивать / разворачивать приложение, производить касание по экрану в нужном месте и т.п.

Если проект крупный и предполагает значительное количество подключений (с учетом того, что часть данных хранятся на сервере), то появляется необходимость провести тестирование производительности.

Если у Вас есть вопросы, замечания или идеи в тестировании этого направления, то можете писать в комментариях.