Охота за ошибками: QA в игровой разработке
Какие задачи решает QA на проекте и что проверяют тестировщики на разных этапах создания игры.
Quality Assurance — «серый кардинал» в процессе создания игры: достижения QA сияют не так ярко, как геймплей, сеттинг или саунд-дизайн. Зато недочёты сразу делают продукт неиграбельным для пользователя.
По своим задачам QA в геймдеве практически не отличается от классического IT. Ключевые задачи тестировщиков:
- Функциональность. Едва ли не самый важный компонент QA. Тестировщики определяют, работает ли игра, как было задумано, нет ли багов, недоработок. В игровой индустрии есть примеры багов, которые со временем стали фичами: отмена анимации некоторых ударов в Street Fighter II позволяет наносить следующие удары быстрее — идея легла в основу всех современных файтингов. Но это исключение, которое подтверждает правило.
- Юзабилити. QA является связующим звеном между разработчиками и игроками. Тестировщики взаимодействуют с игрой так, как это сделал бы самый преданный фанат, и поэтому обнаруживают недоработки быстрее, чем разработчики. А технических знаний у тестеров больше, чем у пользователей — значит, они могут не только сообщить о проблеме, но и предложить разумные изменения. Часто это более конструктивный подход, чем прямой фидбэк игроков.
- Соответствие требованиям. QA проверяет, что все необходимые фичи имеются и работают как надо. Например, если игра MMORPG, то многопользовательский режим должен быть доступен при самых разных игровых сценариях.
Рассмотрим вкратце этапы производства игр, в которых задействован QA-отдел на примере Alawar.
Этап I — Концепт
Это скелет будущего проекта. На данном этапе QA по опыту других проектов и собственной экспертизы заранее предполагает проблемы с игровыми механиками. К примеру, если в концепт-доке указано, что игрок может прыгать — надо понимать высоту и длину прыжка, условия, которые позволяют совершить прыжок. Исходя из этих параметров можно проводить тестирование и проверять, работает ли механика как задумано и не нарушается ли её работа в зависимости от других механик.
Вот ещё пример: если в игре планируется инвентарь, 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 должен убедиться в корректном взаимодействии с ними: сохранения (в том числе их перенос через облако), достижения, установка и запуск, переключение локализаций и так далее. По сути, это финализация — объёмная проверка всех работ по имплементации и исправлениям.
Даже на этапе релиза в игре всё равно могут быть баги и недоработки, которые осознанно не правились (были некритичны для конечного продукта). QA собирает бэклог таких ошибок и передаёт его саппорту — это база для ответов или помощи игрокам.
Этап VI — Пострелиз
Итак, готово. Игру подготовили и выпустили на всех запланированных платформах. Это потрясающее достижение, но QA ещё есть над чем поработать.
На этапе пострелиза задача QA — проверить, что ошибки воспроизводимы, вычислить точные шаги воспроизведения и собрать все возможные данные (логи, сейвы, скриншоты), которые разработчики могут исправить.
Неважно, какой простой кажется игра, ведь в основе её качества — серьёзная работа, которой занимается QA на всех этапах проекта. Именно тестировщики проверяют, что всё работает хорошо, и дают пользователям наслаждаться игрой, а не наталкиваться на баги.