Каждое знакомство с новым проектом начинается с подготовки исследовательского документа. Его еще можно назвать фундаментом, который выстраивается для удобства работы с тем или иным приложением. Этот документ включает в себя несколько основных разделов, позволяющих с первого взгляда ознакомиться со спецификой, первоочередными задачами и основными проблемами приложения.

Давайте пройдемся по этим разделам, чтобы понимать, из чего же состоит самый важный подготовительный этап любого исследовательского тестирования.

1. Agenda - (дословно - повестка дня)

Первый раздел содержит всю необходимую информацию о том:

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

Пример оформления раздела Agenda

Таким образом, этот раздел наполнен подсказками, ориентирами и важными ссылками, которые понадобятся для работы с приложением.

2. Testplan - (дословно - план тестирования)

Одним из обязательных моментов является подготовка плана тестирования.

А именно:

• составление задач по проекту (создание документации, тестирование производительности, исследовательское тестирование, тестирование сети);
• определение сроков, которые будут затрачены на работу (точные даты/часы);
• распределение обязанностей между тестировщиками (кто возьмется за ту или иную задачу).

Пример оформления раздела Testplan

Можно сделать вывод, что Testplan позволяет разделить проект на части и разложить все первоочередные задачи по полочкам, определив ответственных за каждую задачу и время на её выполнение.

3. Devices - (дословно - устройства)

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

Это могут быть планшеты, смартфоны, отличающиеся характеристиками, версиями, прошивками, разрешениями экрана, диагональю, ОС. Чем обширнее будет список отличительных особенностей выбранных девайсов, тем глубже будет проведено тестирование приложения.

Пример оформления раздела Devices

Раздел Devices позволяет не только распределить, какие устройства будут использованы в качестве инструментов для тестирования, но и помогает в дальнейшем выявить слабые стороны приложения, исходя из характеристик выбранных моделей.

4. Checklist - (дословно - контрольный список)

Еще один важный момент - подготовка чеклиста. Чеклист в тестировании - это список, который содержит перечень проверок для работы приложения. В процессе тестирования можно упустить серьезные детали, а значит не выполнить доскональный, качественный поиск багов.

Удобнее всего разбивать чеклист по механикам (лобби, туториал, геймплей, настройки). Это нужно для более удобного ориентирования по приложению. Оформлять чеклист желательно в едином стиле и формате. Например, использовать только глаголы (“собрать”, “добавить”, “расширить”), или только существительные (“сборка”, “добавление”, “расширение” и т.д.).

После составления чеклиста тестировщик начинает проверку, придерживаясь данного списка. Если по каким-то причинам пункт не может быть выполнен, в комментариях нужно указать причину (требуется долгое прохождение, нужны читы, не подключены тестовые платежи и т.д.). В случае удачной проверки, напротив каждого пункта отмечают статусы (“passed”, “failed”, “blocked”, “skipped”), либо соответствующий цвет (где “зеленый” - выполнена успешная проверка, а “розовый” - проверка была провалена). Для удобства можно отметить номер бага, который будет расшифрован в разделе Bugs.

Чеклист не нужно делать слишком большим. Необходимо включить только позитивные сценарии, которые помогут максимально ёмко охватить основной функционал приложения, не затратив при этом много времени. Можно опираться на ГДД (гейм-дизайн документ), чтобы узнать, какие места в приложении наиболее важны при проверке.

Пример оформления раздела Checklist

Подводя итоги вышесказанного, составление чеклиста - особенно ответственный раздел при подготовке к исследовательскому тестированию, ведь это позволяет не только увидеть рабочий прогресс, но и не забыть выполнить проверку тех или иных пунктов.

5. Bugs - (дословно - “ошибки”)

Главная задача тестировщика - это поиск багов или ошибок, которые мешают корректной работе приложения. У пользователей всегда есть ожидание, как должна работать программа. Но не всегда ожидание и реальность совпадают. Для этого и существует тестирование, чтобы до выпуска в релиз найти, как можно больше несоответствий.

Когда тестировщик находит тот или иной баг, его необходимо зафиксировать, иначе зарепортить.

Оформление бага происходит, как правило, по единой схеме:

• Порядковый номер. Каждому багу присваивается номер для удобства. Например, в чеклисте можно перечислить номера багов для наглядности.
• Название. Здесь важно ёмко и коротко описать баг. В названии обычно указывают проблему, которая встретилась и где. Например, “не открывается инвентарь в лобби”.
• Платформа (Android, IOS, PC).
• Приоритет (Low, Mid, High, Crit, Blocker).
• Статус (“Открыто”, “Фикс готов”, “Закрыто”, “Не воспроизводится”, “Не баг”, “Нужна доработка”).
• Шаги. Их нужно прописывать максимально чётко, недвусмысленно и подробно, чтобы любой из тестировщиков и разработчиков мог воспроизвести проблему.
• Результат. Здесь описывается фактический результат и ожидаемый результат. Что хотели и что есть по факту.
• Файлы. Сюда прикрепляются ссылки на видео, скрины, логи.
• Комментарии. Обычно в комментариях разработчики могут пометить, в чем была проблема бага, есть ли вообще проблема, будет ли она устранена. Также комментарии могут использоваться для заметок между тестировщиками.

Пример оформления раздела Bugs

Раздел Bugs - это, своего рода, отчет, который не только помогает исправить существующие проблемы, но и позволяет выявить наиболее слабые места приложения.

6. Performance - (дословно - производительность)

Тестирование производительности - это способ определить, достаточно ли хорошо оптимизировано приложение.

• В мобильных приложениях делается замер показателя FPS. Как правило, проводится 10-минутный замер (если для тестирования не требуется большее количество времени) FPS. После этого строится график для отслеживания просадок, минимальных, максимальных и средних значений. Далее происходит анализ значений - подведение итогов. Также указываются такие показатели, как время сессии и текущие настройки в приложении.

Пример оформления раздела Performance мобильных приложений

• При тестировании PC приложений делается замер таких показателей, как: FPS, использование оперативной памяти (RAM), загрузка процессора (CPU Usage), загрузка видеокарты (GPU load).

Пример оформления раздела Performance PC приложений

RAM

На графике RAM проверяется, нет ли тенденции к постоянному росту потребляемой памяти, и, в целом, адекватность её потребления приложением.

Пример оформления раздела Performance PC приложений

GPU Load

На графике GPU Load интересует то, на сколько % используется видеокарта. Если видеокарта используется на 90-99%, то приложение правильно использует возможности видеокарты.

Если приложение не может выдать стабильные 60 кадров и при этом ни процессор, ни видеокарта не загружены под 99%, значит приложение не использует возможности системы и недостаточно оптимизировано.

Пример оформления раздела Performance PC приложений

CPU Load

Здесь нужно обратить внимание на то же самое, что и при загрузке видеокарты, но только с процессором. График нужен для того, чтобы понять нет ли высоких требований к процессору, помимо использования видеокарты.

Пример оформления раздела Performance PC приложений

На этапе проверки производительности выявляются узкие места производительности, устранив которые, вырастут возможности пользования приложением.

7. Feedback - (дословно - обратная связь)

Обратная связь или другими словами UX-тестирование (User Experience Testing). На этом этапе тестировщик должен дать свою обратную связь о приложении, предоставить свое мнение об удобстве работы с программой.

Важно дать развернутое пояснение:

• Что понравилось/не понравилось с пользовательской точки зрения.
• Какие моменты показались наиболее странными.
• Как это влияет на текущий геймплей.
• Какие есть варианты решения этих нюансов, как можно исправить.
• Как эти исправления повлияют на приложение, что изменится.

Пример оформления раздела Feedback

Таким образом, Feedback - это первое впечатление и субъективный взгляд тестировщика, который помогает определить эффективность взаимодействия пользователей с продуктом.

8. Network - (дословно - сеть)

Раздел Network даёт возможность искусственно повлиять на состояние сети и посмотреть, как будет вести себя приложение в различных состояниях.

Для начала нужно определить, как именно тестировщик будет влиять на Интернет-соединение:

• Отключение Интернет-соединения на девайсе.
• Переход с Wi-Fi на мобильную сеть.
• Создание нестабильного Интернет-соединения.
  
  

Для тестирования на мобильных устройствах потребуется USB WiFi адаптер.

После выбора способа прерывания сети можно начинать тестирование. Вот несколько примеров, на что может повлиять Интернет-соединение и на что стоит обратить внимание в первую очередь:

• Загрузка приложения.
• Загрузка карты, загрузка уровня и т.д.
• Геймплей.
• Покупка каких-либо игровых предметов, сбор награды за ежедневное задание и т.д.
• Покупки в приложении (IAP).
• Просмотр рекламы.

Пример оформления раздела Network

Раздел Network даёт возможность заранее исключить проблемы, с которыми могут столкнуться пользователи при использовании приложения, поэтому очень важно сделать максимальный упор на проверке сети.

9. Reviews  - (дословно - отзывы)

На этом этапе тестировщика интересуют отзывы пользователей, которые они оставляют в сторах. Важно обращать внимание только на комментарии, которые указывают на конкретные проблемы, ошибки.

Вот некоторые из примеров:

• Зависает приложение при N условиях.
• Тормозит приложение при N условиях.
• Крашится приложение при N условиях.
• Игровая механика не работает.

После того, как подобного рода отзывы будут выписаны в соответствующую таблицу, баги необходимо воспроизвести.

• Если ошибку удалось воспроизвести, то можно сразу оформлять её в разделе Bugs.
• Если ошибка не воспроизводится, то нужно указать, что воспроизвести баг не удалось и что предприняли для воспроизведения.
• Если не удалось воспроизвести баг  по каким-либо причинам, то нужно указать по каким причинам это не удалось сделать (требуется более длительное прохождение или нет доступа к тестовым платежам и т.д.)

Пример оформления раздела Reviews

Теперь вы знаете, что подготовка исследовательского документа - это непростой и первостепенный этап, с которого начинается знакомство с приложением и его возможностями, а в дальнейшем он используется для успешного тестирования и поиска ошибок. Поэтому к этой задаче нужно подойти наиболее ответственно, ведь от этого будет зависеть, насколько качественно будет проведена работа в целом.