Мы поговорили с экспертами из небольших, средних и крупных игровых компаний, с целью узнать, каким образом они справляются с такой часто недооцененной дисциплиной, как обеспечение качества.
Обеспечение качества — часто недооцененная и неправильно понимаемая часть процесса разработки игр. В зависимости от студии команда QA может состоять из одного человека или целой группы людей, ответствечающех за тестирование, отслеживание и оповещение о любых багах, которые они могут обнаружить.
В связи с чем, рабочий процесс разных студий может заметно отличаться, например, предпочтением определенного программного обеспечения или процесса у команды.
Разница в размере команды
Леслианн Уайт (Lesleyann White) — главный специалист по обеспечению качества в студии Failbetter Games, специализирующейся на интерактивных фантастических играх, таких как Sunless Sea и Sunless Skies. До этого она работала над Runescape в Jagex, где отдел QA состоял примерно из 30 человек. Сейчас же она — единственный человек, ответственный за обеспечение качества в Failbetter.
«Иерархия везде очень разная», — объясняет Уайт. «Помню, до моего прихода в Failbetter отдел обеспечения качества отсутствовал, так что эта должность своего рода всеохватывающая. Необходимо работать над всеми проектами, выполнять всю работу, заниматься планированием, тогда как в более крупной компании — например, в Jagex… у нас были младшие тестировщики, которых можно было повысить до тестировщика, старшего, а затем лида. Также у нас был QA менеджер, который отвечал за весь отдел обеспечения качества и за всех сотрудников, работая с кадрами».
Team17 — разработчик и издатель из Уэйкфилда. Отдел QA этой студии отвечает за тестирование своих собственных игр, таких как Worms WMD, а также помогает небольшим командам тестировать их собственные проекты, включая такие популярные игры, как Overcooked и Overcooked 2. В настоящее время в отделе обеспечения качества издателя работают 43 человека, выполняющие разные задачи в рамках этой команды.
Хлоя Крукс (Chloe Crookes) — старший аналитик отдела обеспечения качества в этой студии. В своем недавнем выступлении на Yorkshire Games Festival она объяснила свои обязанности следующим образом: «По моему опыту, обычного QA отличает от старшего то, что старший QA обычно имеет свою команду тестировщиков и помимо своей работы, контролирует работу всей команды. Также вы можете заниматься составлением планов тестирования и организацией сценариев тестирования». Текущий проект Крукс — Moving Out, новая игра, разрабатываемая совместно Devm Games и SMG Studio, издателем которой выступает Team17.
Кембриджская студия Frontier Developments — еще одна крупная студия разработки, которая в основном специализируется на играх-симуляциях, например, Jurassic World Evolution и Planet Zoo.
Как и в Team17, отдел обеспечения качества Frontier Developments выполняет ряд различных задач. Колин Дэвис (Colin Davis), глава отдела обеспечения качества, поделилась преимуществами работы в большом отделе: «Размер нашей студии позволяет нам предоставлять большое разнообразие видов тестирования. У нас есть ряд специализированных команд, работающих рядом с более типичным подходом к функциональному тестированию. Наши функциональные тестировщики ответственны за тестирование всего игрового процесса в целом и самих фич, формирующих игру, для которой они разработаны, в то время как специализированные команды работают над игрой, которая требует определенного типа тестирования в данный момент времени».
Инструменты для работы
Помимо различных задач в QA, есть также ряд различных инструментов, и они могут различаться в зависимости от студии и их собственного внутреннего рабочего процесса.
«В Failbetter мы выполняем практически все виды тестирования», — говорит Уайт. «Системное, интеграционное, выборочное, регрессионное, тестирование производительности, совместимости, соответствия и т. д. Проще будет назвать те типы тестирования, которые мы не проводим в Failbetter: локализации и модульное тестирование». Уайт объясняет, что первое не осуществляется в связи с большим словесным наполнением игр Failbetter, что делает процесс дорогостоящим и неэффективным, а второй вид тестирования она хотела бы внедрить в будущем.
Для составления багрепортов и для управления проектами в течение последнего года или около того Уайт предпочитает использовать багтрекер Jira. Как системному администратору, ей нравится, насколько он настраиваем и гибок как для небольших, так и для крупных проектов. Такое же мнение у Frontier, которая также использует одно и то же программное обеспечение для отслеживания багов и время от времени для других своих нужд.
Что касается других инструментов, Уайт использует такое программное обеспечение как Unity для тестирования и исправления ошибок, а также различные другие специальные инструменты тестирования, включая макросы, такие как AutoHotkey и собственную CMS Failbetter: Storynexus. Это в дополнение к Confluence или Google Docs для написания технических документов. Учитывая небольшой размер студии, команда предпочитает простоту и экономичность, чтобы не усложнять свой рабочий процесс и сократить объемы вероятных проблем.
Тем временем Team17 использует Excel для составления планов тестирования и Redmine в качестве своего багтрекера на основе базы данных. Redmine позволяет им предоставить сводку по каждой проблеме, с которой они столкнулись, описание этой проблемы и ввести настраиваемые поля, чтобы указать, в каком формате или на какой платформе они столкнулись с проблемой. Они также могут добавлять любые соответствующие скриншоты или видео, чтобы дать разработчикам больше информации для дальнейшей работы.
«Как правило, прежде чем передать разработчикам вопрос для исправления, мы всегда пытаемся воспроизвести его необходимое количество раз, чтобы получить надежный путь воспроизведения», — уточняет Крукс. «Чаще всего, причина возникновения бага очевидно, поэтому воспроизвести его вновь легко... Но иногда бывают ситуации, когда вы не совсем уверены в причине возникновения бага... В этом случае мы просто должны предоставить разработчикам максимальное количество информации по багу, а затем следить, столкнемся ли мы с ним снова».
По словам Дэвиса, Frontier пошла еще дальше и создала свой собственный инструмент, который может взаимодействовать сразу с несколькими багтрекерами с базами данных. Таким образом, разработчики Frontier могут шаблонизировать большую часть описания багов, что в целом увеличит эффективность и совместимость. На проектах они применяют различные виды тестированмя, исходя из требований конкретной игры. Это включает в себя все: от сертификации до совместимости и локализации, взаимодействия с пользователем, деструктивных действий и автоматизации.
Дэвис объясняет: «Автоматизация — важная часть того, что мы делаем, поскольку она позволяет нам автоматизировать наиболее повторяющиеся операции, такие как размещение каждого отдельного объекта в такой игре, как Planet Coaster, и совершать автоматическую проверку возможности их размещения на игровом поле. Это экономит нам время, чтобы мы могли более детально взглянуть на то, на что похож игровой опыт».
«Помимо этого, мы также используем автоматизированное тестирование для создания ряда тестов, которые помогают нам с каждой игрой, над которой мы работаем. Эти тесты могут варьироваться от простых вещей, таких как проверка того, что вы можете начать игру на любой платформе на только что скомпилированной сборке, до более сложных вещей, таких как полет на корабле в Elite, приземление на различных станциях, а затем определение лучшего торгового пути, исходя из представленной информации. Этот тип автоматизации ближе к опыту игрока и его возможным действиям в игре, что может помочь выявить проблемы, больше связанные с эмпирической стороной».
И Уайт, и Крукс также отметили важность «регрессионного тестирования» или «тестирования эффекта гало», как его иногда называют. То есть проверка внесенного исправления, для того, чтобы убедиться, что изменение не повлияло на сборку в другом месте.
«Наши действия выглядели бы так: для начала мы бы непосредственно проверили проблему, а затем, например, если был изменен способ разблокировки достижения, мы бы переключили внимание и более широко взглянули на это достижение», — говорит Крукс. «Например, если вам нужно пройти определенный уровень, чтобы разблокировать это достижение, возможно, вы протестируете провал уровня и убедитесь, что за этим не последует его разблокировка. Таким образом, это своего рода слепое тестирование, в котором вы также должны использовать ваш опыт, и если ранее встречали такое в другой игре, вы можете протестировать это и здесь».
Практический подход
Одна вещь, которую отмечают все команды, — это ценность игры для игроков. Особенно это касается вопросов доступности и баланса.
Уайт поясняет: «Что касается тестирования доступности, важно, чтобы команды QA выполняли его, но я считаю, что ничто не заменит демонстрацию продукта перед целевой аудиторией. При наличии определенных групп тестирования для оценивания фичи, часто поднимаются аспекты доступности дизайна, которые вы не предполагали. Это одна из причин, по которой мы открываем ранний доступ к нашим играм, что позволяет нам представить игрокам игру с целым рядом проблем с доступностью и получить их фидбэк».
Недавно, например, Failbetter запустил новую бета-версию интерактивной карты (рисунок ниже) для Fallen London. Одной из частей этого процесса было обращение к игрокам в сообществе, которые используют программу чтения с экрана, чтобы услышать их мнение об этом новом дополнении.
Team17 регулярно проводит юзабилити-тесты, приглашая простых людей ознакомиться с их играми и проверить, насколько они сбалансированы. Это позволяет им получать фидбэк от людей, незнакомых с игрой, в которую они играют, что оказалось очень ценным ресурсом.
«Мы привлекаем обычных людей, чтобы они тестировали игры, а мы получали от них фидбэк», — говорит Крукс. «Я считаю, что это действительно полезно для нас, потому что команды QA могут работать над проектами около шестнадцати месяцев, а иногда, ведь мы супер крутые, мы немного усложняем ее. И нам трудно сделать шаг назад и признать: "Да, это на самом деле работает не так хорошо, как мы ожидали"».
Для тех, кто думает о том, чтобы попасть в QA, я поинтересовался, какие шаги люди должны предпринять, чтобы выделиться, и какие студии можно рассмотреть будучи соискателем на должность QA. Вот что мне ответили:
«Если это начало пути, не думайте, что попав в QA вы уже одной ногой в игровой индустрии», — говорит Дэвис. «Обеспечение качества — неотъемлемая часть процесса разработки, это отличный выбор карьеры для всех, кто интересуется играми и хочет внести свой вклад». Он приводит несколько примеров того, как развивать свои навыки. «Если вы когда-либо пробовали заспидранить игру, попробуйте улучшить эти навыки, не полагаясь на информацию, которую вы найдете в Интернете. Навыки и способности, которые вы приобретете в результате этого, могут быть чрезвычайно полезны в тестировании!».
«Лучше всего демонстрировать свое желание попасть в индустрию, а не просто говорить то, что вы хотите играть в игры», — отвечает Крукс. «Люди откликаются на вакансии, думая, что они просто будут играть в игры весь день, но они не продержатся долго, потому что это довольно тяжелая работа, особенно когда приближаются дедлайны. Я думаю, чтобы быть в индустрии, вы должны суметь доказать, что у вас есть страсть к этому, и это вероятно, главное. Если вы делали игры дома, покажите их и скажите: "Эй, посмотрите, сколько усилий я приложил. Вот где я хочу быть. Этим я хочу заниматься". Я думаю, вам просто нужно правильно это показать.»
Всех желающих мы приглашаем на открытое занятие «Тестирование графики в играх». На вебинаре расскажем: как и когда развивалась графика, про основные составляющие создания графики, что необходимо учитывать при тестировании изометрии, про 3-D и 2-D графику. Регистрация доступна по ссылке.