Охота за ошибками: QA в игровой разработке

Quality Assurance — «серый кардинал» в процессе создания игры: достижения QA сияют не так ярко, как геймплей, сеттинг или саунд-дизайн. Зато недочёты сразу делают продукт неиграбельным для пользователя.

По своим задачам QA в геймдеве практически не отличается от классического IT. Ключевые задачи тестировщиков:

• Функциональность. Едва ли не самый важный компонент QA. Тестировщики определяют, работает ли игра, как было задумано, нет ли багов, недоработок. В игровой индустрии есть примеры багов, которые со временем стали фичами: отмена анимации некоторых ударов в Street Fighter II позволяет наносить следующие удары быстрее — идея легла в основу всех современных файтингов. Но это исключение, которое подтверждает правило.
• Юзабилити. QA является связующим звеном между разработчиками и игроками. Тестировщики взаимодействуют с игрой так, как это сделал бы самый преданный фанат, и поэтому обнаруживают недоработки быстрее, чем разработчики. А технических знаний у тестеров больше, чем у пользователей — значит, они могут не только сообщить о проблеме, но и предложить разумные изменения. Часто это более конструктивный подход, чем прямой фидбэк игроков.
• Соответствие требованиям. QA проверяет, что все необходимые фичи имеются и работают как надо. Например, если игра MMORPG, то многопользовательский режим должен быть доступен при самых разных игровых сценариях.

Рассмотрим вкратце этапы производства игр, в которых задействован QA-отдел на примере Alawar.

Этап I — Концепт

Это скелет будущего проекта. На данном этапе QA по опыту других проектов и собственной экспертизы заранее предполагает проблемы с игровыми механиками. К примеру, если в концепт-доке указано, что игрок может прыгать — надо понимать высоту и длину прыжка, условия, которые позволяют совершить прыжок. Исходя из этих параметров можно проводить тестирование и проверять, работает ли механика как задумано и не нарушается ли её работа в зависимости от других механик.

Вот ещё пример: если в игре планируется инвентарь, QA может заранее предположить трудности: дублирование предметов (дюп), их пропажу или «блокирование» из инвентаря. И посоветует фичи к инвентарю, например, сортировку по критериям или автоматическую.

Этап II — Прототип

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

• Будут ли игровые механики работать, как задумано. Пока без цифр и настроек, просто на уровне понимания.
• Как реализованные игровые механики смогут взаимодействовать. К примеру, можно ли стрелять в прыжке, задавать очередь действий?
• Общее представление интерфейсов. Какие элементы UI будут использоваться чаще других, удобно ли до них добраться?
• «Целостность» механик, сеттинга, сюжета. Не выбивается ли что-нибудь из общего представления?

Этап III — Вертикальный срез

Это такой «хомо сапиенс» среди остальных прототипов, минимальная полноценная версия игры, которая иллюстрирует большую часть игровых процессов, содержит все базовые фичи и в которую уже можно поиграть. В вертикальном срезе QA проверяет:

• Базовые игровые механики — очень важный для проверки компонент. Именно корректная работа всех базовых механик во всех игровых состояниях — один из главных критериев качества.
• Юзабилити: удобно ли пользоваться игровыми интерфейсами.
• Графику и саунд-дизайн: соответствуют ли требованиям заказчика или продюсера.. Интересен ли игровой цикл? Что можно добавить или убрать, чтобы сделать игру более захватывающей.

Этап IV — Продакшн

После прототипа и вертикального среза игра идёт в производство — к альфа-стадии разработки. Это один из самых долгих и объёмных этапов работы над проектом, на котором очень важна документация. От геймдизайнеров и программистов полезны ТЗ на фичи и то, как именно они реализованы. Отталкиваясь от этой информации, QA пишет тест-кейсы по каждой из тестируемых фич. Затем компонует тест-кейсы в чек-листы, по которым в дальнейшем будет проверять игру, например, при регрессионном тестировании.

На альфа-стадии QA тестирует:

• Игровые механики. QA проверяет, что механики настроены и работают как ожидается, контролирует поведение каждой механики отдельно и взаимодействие механик друг с другом во всех возможных игровых состояниях. Вообще это самый важный этап в плане поиска сценариев, которые не были предусмотрены разработчиком — такие баги обычно самые критичные и неприятные, в том числе для игроков.
• Юзабилити. Этот процесс часто перекликается с настройками и реализацией механик. Если в игре есть часто используемое меню, оно должно быть легко доступно через кнопку в интерфейсе (расположенную близко к другим «популярным» элементам) или по горячей клавише.
• Игровой функционал. Здесь «узкое место» — как сохранение и загрузка игры влияют на состояние игровых объектов. Бывает, что при загрузке игры неправильно считываются (или не считываются вовсе) состояния объектов и персонажей, а это ломает основные механики. Также довольно часто встречается проблема сохранения состояний. К примеру, многие казуальные игры в жанре hidden object можно сломать, если закрывать игру во время анимаций. Частое применение и сбор предметов завязаны на анимацию, и если её прервать — могут быть проблемы. Получается, игра знает, что предмет взят, но не добавляет в инвентарь, потому что анимация не была закончена. Новое состояние предмета игра не понимает, «теряет» его и блокирует прохождение.
• Интерфейс. QA последовательно тестирует все возможные комбинации и последовательности взаимодействия с ними.
• Функциональное тестирование. QA проверяет графику: отображаются ли все текстуры, объекты, модели, пропы, анимации так, как задумано, во всех состояниях. А также звук: воспроизводится ли в соответствии с «якорями», на все ли игровые события «подвешены» нужные звуки, соответствует ли задумке старт и финиш мелодий, как настраивается громкость звуков, музыки, эмбиента.

На этом же этапе QA проводит конфигурационное тестирование: работает ли игра на всех системах, которые соответствуют минимальным системным требованиям. Смотрит, не зависит ли поведение игры от железа. Проверяет взаимодействие с ОС: игра должна вести себя нативно и подчиняться тем же правилам, что и другие процессы в операционной системе. Контролирует потребление ресурсов (RAM/VRAM/CPU) и утечки памяти.

Следующий шаг — бета-версия игры, в которой могут быть недоработки или незначительные ошибки. Здесь происходит полишинг и финализация игры, выполняются минорные задачи: отрисовка финальных версий артов, добавление звуков и анимации. Результат — готовый продукт, который можно дать потестить аудитории.

• Закрытый бета-тест — показ игры небольшому количеству пользователей, чтобы выявить критические баги, недоработки игровой логики, геймдизайнерские ошибки, а также собрать статистику по игровым процессам.
• Открытый бета-тест — запуск проекта на широкую аудиторию. Здесь происходит feature freeze — программисты перестают делать новые фичи и переключаются на отладку.

На этапе бета-версии тестировщики проверяют:

• Доступен ли игровой контент для пользователей.
• Все ли пользовательские сценарии протестированы и работают нормально. Проверка сценариев начинается раньше, но именно на этом этапе можно проверить максимум сценариев и снять риски.
• Корректно ли локализована игра с технической стороны: все ли тексты видны, читаемы и расположены в отведённых для них пределах, нормально ли переключаются локализации и прочее.

Этап V — Релиз

Официальная публикация игры. До него QA выполняет предрелизное тестирование: проводит смоук-тесты (игра должна запускаться и работать на всех системах, близких к минимальным системным требованиям), проверяет основные кейсы по игровому функционалу и проходимость игры хотя бы по простым сценариям, следит, что все изменения, которые были внесены в игру перед релизом, ничего не ломают и не вызывают неожиданных изменений.

Если игра выходит в GOG, Epic Games Store, Steam или других сервисах цифровой дистрибуции, QA должен убедиться в корректном взаимодействии с ними: сохранения (в том числе их перенос через облако), достижения, установка и запуск, переключение локализаций и так далее. По сути, это финализация — объёмная проверка всех работ по имплементации и исправлениям.

Если игра выходит в GOG, Epic Games Store, Steam или других сервисах цифровой дистрибуции, QA должен убедиться в корректном взаимодействии с ними: сохранения (в том числе их перенос через облако), достижения, установка и запуск, переключение локализаций и так далее. По сути, это финализация — объёмная проверка всех работ по имплементации и исправлениям.

Валерий Давыдов, руководитель QA в Alawar

Даже на этапе релиза в игре всё равно могут быть баги и недоработки, которые осознанно не правились (были некритичны для конечного продукта). QA собирает бэклог таких ошибок и передаёт его саппорту — это база для ответов или помощи игрокам.

Этап VI — Пострелиз

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

На этапе пострелиза задача QA — проверить, что ошибки воспроизводимы, вычислить точные шаги воспроизведения и собрать все возможные данные (логи, сейвы, скриншоты), которые разработчики могут исправить.

Неважно, какой простой кажется игра, ведь в основе её качества — серьёзная работа, которой занимается QA на всех этапах проекта. Именно тестировщики проверяют, что всё работает хорошо, и дают пользователям наслаждаться игрой, а не наталкиваться на баги.