Устану ли я играть, нужно ли уметь кодить и чем вообще занимаются QA в геймдеве

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

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

Дисклеймер: в статье я не буду разделять специалистов QA и тестировщиков. Кому-то просто не нравится термин «тестировщик», кто-то акцентирует на том, что тестирование это только частный случай контроля качества. Вопрос во многом философский, оставим его за рамками этого материала.

Начнем с небольших общих вопросов, которые часто получаю или встречаю в сети. А потом перейдем к более практичным вещам — инструментам, задачам и воркфлоу.

FAQ

— Правда ли, что QA — это легкий путь в геймдев?

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

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

— Нужно ли тестировщику уметь кодить?

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

Мы, кстати, периодически помогаем разработчикам обнаружить опечатки в коде. В Git есть история изменений, тянем коммит, который только запушили, он не запускается, открываем лог и понимаем, где может быть проблема. Идем с этим к программисту и фиксим за пару секунд.

— Какие навыки нужны тестировщику?

Банально, но первый пункт — человек должен сильно любить игры, посвящать им много времени. Самые простые баги, основанные на игровых механиках, геймер увидит сразу, а человек, не увлекающийся играми, может легко пропустить.

Второе — софт-скиллы. Хард-скиллов у новичка обычно нет, но всегда можно научить пользоваться ADB Tools, Xcode, Git, Jira или Unity. А вот научить правильно и лаконично общаться письменно и устно — намного сложнее. Мы больше остальных коммуницируем с другими отделами: и устно, и письменно. Например, нужно завести баг так, чтобы он был понятен другим тестировщикам, разработчикам, геймдизайнерам и фиче-овнеру.

Скажу так: интроверт может быть прекрасным разработчиком, но для тестировщика это может привести к сложностям в процессе обучения, работы и роста. Потому что у нас тестировщик является связующим звеном между отделами.

Например, есть фича. Читаешь ТЗ, начинаешь проверять и находишь подводные камни — моменты, которые не описаны в ТЗ и непонятно, как они должны правильно работать. У тестировщика есть два варианта действий: плохой и хороший. Плохой — придумать самому, как она должна работать, но с большой долей вероятности это закончится повторной проверкой функционала. Хороший вариант — идти к геймдизайнеру, который ведет эту фичу, и вместе с ним пытаться понять и отрегулировать неопределенное место так, чтобы всем было понятно.

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

— Правда ли, что тестировщик просто целый день играет?

Самый популярный стереотип. Конечно, это не так. Хотя первую неделю джуны играют 100% времени, некоторые даже бросают в этот момент.

Когда работа уже на потоке, то процентов 70% времени занимает тестирование, коммуникация внутри отдела, написание чек-листов, работа с фичами. Остальное — поиски сценариев от игроков и коммуникация с другими отделами.

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

— Останется ли у меня желание играть после работы?

Мне говорили, что я не смогу играть, когда шел в тестировщики, но все хорошо. Играю, как и раньше. Иногда морально трудно после работы, но это было в основном в период адаптации. Единственное — стал много обращать внимание на баги в других играх, оказывается в AAA-проектах их очень много (и я не про Cyberpunk 2077).

— Нужно ли знать английский язык?

Я бы назвал это желательным, но необязательным требованием, хотя все зависит от компании. Нужно хотя бы уметь читать и понимать англоязычные форумы, тот же Reddit. Также мы сидим на форумах читеров, чтобы отслеживать уязвимости, так как разрабатываем мобильный PvP-шутер. Был случай, когда каким-то способом игроки массово стали доставать много предметов из клановых сундуков, не тратя валюту. Мы это видели по аналитике, но не могли понять, как они это делают. Тогда я зашел на Reddit во вкладку игры и в одном треде увидел описание способа. Нужно было открыть сундук и быстро переключиться на второго персонажа. В момент перехода есть временной фрейм, когда кристаллик загрузки подвисает — сервер переключает прогресс. В этот момент нужно выключить приложение, потом включить, перейти обратно на первого персонажа и сундук снова станет доступен. При этом все предметы с предыдущего оставались.Еще время от времени читаем тематические форумы и сайты, на которых выкладывают моды для Pixel Gun 3D. Такой ресерч является постоянной задачей — раз в неделю один человек проверяет, есть ли новые моды. Если есть — проверяет их на работоспособность.

— А можно ли обойтись совсем без QA-отдела?

На большом проекте точно нет. Тот, кто пишет код, — смотрит на него субъективно с той стороны, с которой написал. Например, видит, что вкладка работает, но может не проверить ее взаимодействие с остальными вкладками, фичами, переходами и так далее.

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

Инструменты тестировщика

Перейдем к практике.

Как я и говорил, на начальном этапе для тестировщика самое главное — это умение общаться и грамотно излагать мысли. Но с инструментами все равно придется знакомиться. Сначала меня самого пугали слова, вроде Git, коммит, смоук-тестирование, но к этому быстро привыкаешь. 

Один из основных инструментов тестировщиков — это Jira, там ведутся все фичи, баги, процессы.

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

Потом идут система контроля версий (у нас это Git), ADB Tools (входит в Android Studio) — пакет драйверов для взаимодействия с приложениям на Android и Xcode для работы с iOS. Еще используем 3uTools, инструмент, по функционалу похожий на iTunes — позволяет устанавливать приложения, удалять, делать бэкапы, восстанавливать из них данные, джейлбрейкать устройства.

Лайфхак для джунов: перед собеседованием можно посмотреть стек технологий, который использует компания (например, часто его указывают в тексте вакансий) и пару обучающих роликов на YouTube по этим инструментам. Так вы на собеседовании уже будете выгодно выделяться на фоне многих других, поверьте.

Если в игре есть читеры, желательно уметь работать с программами для взлома игр — Game Guardian, Titanium Backup, джейлбрейками для iOS, через которые можно ставить твики. Как минимум, нужно повторить то, что делают читеры, чтобы потом закрыть уязвимость.

Также есть вещи, уникальные для каждого проекта/компании. У нас, например, это собственный менеджер конфигов — в нем редактируются и проливаются все конфиги для фич.

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

Первый месяц новичка

Все понимают, что с новичков нельзя много требовать. Нередко они даже не играли в проекты компании, куда приходят устраиваться (еще один лайфхак для джунов, как выделиться). Поэтому первая неделя для них начинается с ежедневной игры, без консоли разработчика, прямо по восемь часов в день. И бывает, что люди не справляются.

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

Через неделю рассказываю про ADB, сервера, версию игры с консолью разработчика и ставим эту версию на устройство. Затем еще 3-5 дней человек знакомится с консолью, изучает функции, например, добавляет валюту, отключает серверное время, переходит на тестовый сервер, накручивает уровень, пропускает тренировку, включает бессмертие, спидхак и так далее. Нужно знать, что каждая функция из себя представляет, и задавать как можно больше вопросов.В итоге первые две недели уходят на то, чтобы будущий тестировщик разобрался, где что находится.

На третьей неделе начинаем проходить чек-листы — каждый чек-лист, каждый пункт, что как работает. Это важно и для компании, так как помогает актуализировать чек-листы и проверяет внимательность новичка. Вечером снова встреча 1-1.С четвертой недели добавляем новичка третьим в пару к опытным ребятам (у нас тестировщики исторически работают в парах над каждой фичей). Он изучает, как работать с задачами, я рассказываю про Jira, Git, Unity и так далее. Через полтора месяца получается компетентный специалист.

Что нужно тестировать

У нас есть большой список чек-листов (около сотни) по всем фичам, которые были созданы за все время. В этом списке бывают неактуальные чек-листы — но это проверка на внимательность для новичков в первый месяц.

Если брать правила создания чек-листа, то я сделал универсальный шаблон с проверками, которые работают для любой фичи. Это, например, проверка локализации, аппаратного бэка (кнопка раньше была физическая, теперь на Android всплывающая) — все об этом знают, но разработчики иногда забывают добавить.

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

Еще есть внутрипроектные проверки. В игре есть офлайн-режим, в нем доступны мини-игры, кампания, арсенал. Но нет возможности покупки и сохранения прогресса. Купленная в офлайне пушка не учитывается в онлайне. Отключение и восстановление прогресса иногда вызывает проблемы, поэтому проверяется каждая фича. Отправку и получение аналитики, миграции и накаты тоже нужно проверять. Мы используем Photon (про него уже была статья) — регулирует поведение игровых комнат и ловит аномальные значения (например, скорость передвижения) — то есть читеров. Но часто бывает, что при создании новых режимов и пушек про это забывают. В консоли разработчика есть галка «не детектить читы», и она включена по умолчанию. Поэтому в чек-листе есть универсальный пункт — нужно отключить ее и проверить, что тебя не кикает.

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

Виды тестирования

Расскажу еще про несколько терминов, которые часто пугают новичков.

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

Тестирование совместимости — проверяем правильность работы приложения в разных окружениях. Отличаются версии Android, iOS, соотношение сторон, возможность/невозможность включения полноэкранного режима (Android), архитектура ARM64 или Armeabi-v7a. Внешний вид и функциональность везде должны совпадать.

Регрессионное тестирование — это тоже тестирование уже существующих функционалов игры. Так мы можем выяснить, не появились ли ошибки в работе старых фич после добавления всех новых в одной ветке. Естественно, регрессионные тесты проводятся также и при функциональном тестировании новых фич. Но нам крайне важно убедиться, что ничего не сломалось в тот момент, когда все новое «встретилось» в одной ветке. Регрессионное тестирование у нас начинается, как правило, в предрелизную неделю.

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

Смоук-тестирование — проводим, когда знаем, что завершили полное функциональное тестирование, билд был стабилен, но по какой-либо причине (реджект Google Play или App Store, не пролили локаль) пришлось пересобрать. В таком случае, вместо того, чтобы повторно проводить полное функциональное тестирование (а оно занимает 3-4 часа), достаточно убедиться, что все основные функции игры работают — покупки, вход в матч, матчмейкинг, реклама, установка/переустановка приложения, накат. Все перепроверяем и релизим.

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

Как заводить баги

Есть золотое правило — «что, где и когда». Создаешь тикет в Jira, пишешь лейбл и нужно максимально лаконично написать, что, где и при каких обстоятельствах сломалось. Так можно сэкономить время при починке и проверке, поэтому не стоит это игнорировать. Например, состоялся релиз режима импостер на Android, провели функциональное тестирование и обнаружили, что он сломался. Что нужно делать:

1. Написать лейбл: «Режим предатель (что) ломает геймплей (где)». Все понятно.

2. В описании рассказать, как воспроизвести баг. Есть шаги воспроизведения — ожидаемое и наблюдаемое поведение. Все это обязательно заполняется.

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

4. Назначить исполнителя, то есть разработчика, который будет фиксить баг.

Но есть один момент: мы придерживаемся правила, что если что-то получилось воспроизвести только один раз — то это пока еще не баг, и его рано заводить в Jira. 

Например, игрок пожаловался в саппорт-сервере Discord (про его организацию писали тут) на сломанную скролл-сетку в арсенале. Факт бага есть, но непонятно, как воспроизвести. Если это критичный баг перед релизом, то смотрим всем отделом. Если не критичный, то на будущее заводим сами себе билет на поиск сценария. Выставляется версия, до релиза которой нужно сценарий найти. Когда появляется время — тестировщик возвращается к поиску.

Рабочий день на примере появления нового оружия

У каждой пары тестировщиков есть свой чат в Slack и определенная область ответственности. Есть те, кто проверяют монетизацию и коммерцию, есть проверяющие новый контент, батл пассы, новые режимы и так далее.

Утром я выстраиваю им в Slack очередность списка задач по приоритету. Они открывают Jira, сверяются с тем, что я им скинул, меняют статус на «На тестировании», переходят на ветку, начинают проверять.

Допустим, в игре появилось новое оружие. Кидаю задачу, тестировщик переходит на ветку и ставит собираться билд с фичей, чтобы через три часа она собралась и можно было ее проверить на устройстве. У нас есть билд-сервер — это локальная машина, на которой есть интерфейс, два билдера Android и iOS. Тестировщик заходит и ставит на Android и iOS нужную сборку.

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

Находит проблемы, маркирует непройденные пункты. Затем в Jira заводит отладку, что вот там, например, неправильная анимация по сети. Потом берет следующую пушку, так как в релизе у нас их в среднем 15 штук. Ждет фиксы.

В оружии большая часть проблем обычно связана с визуалом — их решают художники. Они часто просят помочь воспроизвести, потому что редко контактируют с геймплейной частью. Тестировщик вместе с художником воспроизводит баг и после фикса снова проверяет по чек-листам. Потом закрывает задачу, ставит статус «готово».

Когда статус «готово» стоит у всех задач — собираем сборку, которую можно показать продакт-овнеру и фиче-овнеру. Они смотрят пушки, если все хорошо — фича сливается в основную ветку.Правда, у Git есть интересная особенность — после слития что-то может перестать работать (из-за конфликтов) так, как было нужно. Поэтому после слития нужно всегда проверять фичу по чек-листам заново.

Советы для новичков и полезные ссылки

• Из книг могу посоветую то же, что и все — «Тестирование dot com» Романа Савина. Пригодится для понимания процессов и определения желания этим заниматься.

• Также регулярно читаю Хабр и смотрю сайты вроде 4pda, потому что важно следить за новыми девайсами и ОС. Недавно был кейс с iOS 15, когда игра крашилась в 100% случаев. Хорошо, что проверили еще за пару месяцев.

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