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

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

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

В гостях:

Ведущие – Сергей Галёнкин и Михаил Кузьмин.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#опыт #индустрияигр #какделаютигры #кди