Автоматизация тестирования в геймдеве — «Как делают игры. 297»

О создании фреймворка тестирования, стандартизации и перспективах внедрения машинного обучения.

Мы поговорили про то, как автоматизируются процессы тестирования при разработке игр.

В гостях:

  • Александр Романов, Software Engineer, Playtika
  • Александр Шуков, QA Automation Team Lead, Wargaming.net

Оглавление

Знакомство с гостями

Александр Шуков в игровой индустрии с 2011 года, сейчас он работает в минском офисе Wargaming на проекте World of Tanks. Он начинал как Manual QA engineer, а потом на несколько лет ушёл в функциональное тестирование игрового сервера. Затем в RND группу, в которой занимался углубленной автоматизацией. Пару лет назад в компании создали полноценный отдел QA Automation, и Шуков с тех пор занимает там должность тимлида и техлида.

Александр Романов начал заниматься тестированием в 2011 году, но в геймдев пришёл чуть больше трёх лет назад. До этого он занимался автоматизацией на разных системах, в том числе финансовых. Сейчас в Playtika он занимается автоматизацией тестирования игры Caesars Casino. До этого тоже был одновременно техлидом и тимлидом.

Чем занимаются QA Automation в геймдеве: задачи, вызовы, компетенции

По словам Шукова, QA Automation — это молодое направление, которое пришло из разработки софта. Отрасль появилась из симбиоза QA-инженеров и девелоперов, которые пишут код — на стыке этих двух специальностей родилась такая дисциплина.

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

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

Александр Шуков, QA Automation Team Lead, Wargaming.net

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

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

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

Caesars Casino
Caesars Casino

Как отметил Шуков, задача автоматизации — не заменить тестировщиков. Она позволяет высвободить тот ресурс QA, который занят на прогоне регресса. Обычно необходимость тратить ресурсы на старое приводит к тому, что новое недотестировано, и выходит в худшем качестве, чем могло бы. В результате игроки недовольны.

По словам Шукова, автоматизация — молодая отрасль. Программисты были уже в 60-е, тестировщики — тоже (тогда была должность «инженер», у которого задача была — обеспечить работу того, что кто-то уже сделал до него). Автоматизация появилась в нулевых, а в играх — шесть-семь лет назад. Даже сейчас компаний, в которых есть целый отдел автоматизации, не так уж много.

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

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

В той или иной мере автоматизация была давно. Но не было полноценных фреймворков для тестирования игровой логики (фактически — движков-автотестов). Такие примеры появились относительно недавно.

Про игровой тестовый фреймворк

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

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

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

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

Александр Шуков, QA Automation Team Lead, Wargaming.net
Автоматизация тестирования в геймдеве — «Как делают игры. 297»

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

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

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

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

Но не факт, что в вашей компании это будет работать именно так. Многое зависит от того, как идёт процесс разработки: что создаётся сначала — контент или код?

Шуков также рассказал, что сейчас тестирование для ПК и консолей мало различаются. У разработчиков есть development kit, код пишется на ПК, а финальные проверки проходят на консоли. Единственная проблема возникает с разными сервисами, которые нельзя проверить локально. На ПК у команды Wargaming таких проблем почти не возникает, так как все веб-сервисы они написали сами, и могут протестировать их в локальном окружении.

Сколько стоит большое функциональное тестирование и автоматизация

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

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

В нашем контексте этот подход сработал: хорошие технические девелоперы могут проектировать такие системы намного быстрее, потому что фреймворки — это разработка. По факту, ты разрабатываешь программный продукт, которым будут пользоваться тестировщики либо другие разработчики. Меняется фокус, кто твои пользователи. А так ты пишешь тот же код, тот же продукт, те же технологии, подходы и прочее. Не надо делать упрощения автоматизации, чтобы: «Давайте на коленке напишем, а потом разберёмся».

Александр Романов, Software Engineer, Playtika
Автоматизация тестирования в геймдеве — «Как делают игры. 297»

Есть ли на рынке готовые фреймворки

Как рассказал Шуков, для ПК и консолей их, вероятно, нет. Есть фреймворк Appium, популярный в мире мобилок, который позволяет автоматизировать UI приложения. Для веб-приложений есть Selenium WebDriver. В Unreal Engine есть небольшой инструмент AutomationTool. В Unity тоже есть элементы автоматизации. Этого мало, но уже хоть что-то — это первый кирпич в пирамиде, которую нужно построить. При этом уже сейчас для Unity есть некоторые инструменты, которые можно купить.

Уверен, что через пару лет с любым публичным движком будет всё более навороченный фреймворк автоматизации. Просто сейчас, когда мне предлагают библиотеку за 20 баксов, чтобы потыкать по кнопкам, меня это не устраивает. Я ожидаю от фреймворка работу с бэкэндом, с нативными данными. Мы не выпускаем собственный фреймворк, потому что он сделан под «Танки». И если его перепиливать — придётся делать тройную работу.

Александр Шуков, QA Automation Team Lead, Wargaming.net

По словам Шукова, очень много кода и сил уходит на работу с технической стороной движка. Чтобы создать фреймворк с автоматизацией, нужны:

  • доступ к внутриигровому времени (таймерам);
  • доступ к игровому main game loop;
  • способ интроспекций игровых объектов. То есть возможность смотреть, как устроена логика внутри игры.

Со встраиванием в цикл и интроспекцией игровых объектов есть много сложностей. Если в будущем движок будет предоставлять это в виде библиотеки на популярных языках программирования, а от тестера потребуется лишь давать команды — это будет огромным шагом. И это лишь вопрос времени, когда такое станет популярным.

Перспективные области: AI, балансные тесты

Шуков рассказал, что в некоторых играх для тестирования используется настоящий ИИ. Это значит, что применяется не автоматизация, а полноценные деревья поведения. Вероятно, для этого нужно разбить всё на компоненты и отдельно проверять. Если использовать такой подход, то разработчик теста должен очень точно понимать, какой он ожидает результат, чтобы сказать, где тест «упал», а где был выполнен.

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

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

Есть подход model base тестинга, где ты накидываешь правила игры и переход между состояниями, и есть возможность не только прогнать его по всем ветвям, но и запустить в рандомном порядке: «а что будет, если после этого вызовется это». Можно ещё идти в сторону того, чтобы записывать сессии опытных игроков: как они взаимодействуют с игрой, и на основе этого тренировать систему.

Александр Романов, Software Engineer, Playtika

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

Я слышал прикольную тему насчёт баланса: «Если бы в World of Tanks был идеальный баланс, как все хотели, то это были бы шарообразные танки с разными диаметров — от одного до десяти метров».

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

Александр Шуков, QA Automation Team Lead, Wargaming.net
Автоматизация тестирования в геймдеве — «Как делают игры. 297»

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

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

Александр Шуков, QA Automation Team Lead, Wargaming.net

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

6969
16 комментариев

автоматизированный поиск ошибок в играх
фото в цвете

15
Ответить
Комментарий удалён модератором

но ведь речь про автоматизацию тестирования, а не танки

17
Ответить

Комментарий недоступен

2
Ответить

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

1
Ответить

Работал как-то auto qa- шляпа полная. Очень скучно

Ответить