{"id":2568,"title":"\u0422\u0435\u043b\u0435\u043f\u043e\u0440\u0442\u0430\u0446\u0438\u044f \u0440\u0435\u043a\u043b\u0430\u043c\u043d\u044b\u0445 \u043a\u0430\u043c\u043f\u0430\u043d\u0438\u0439 \u0438\u0437 \u00ab\u042f\u043d\u0434\u0435\u043a\u0441\u0430\u00bb \u0432 Google","url":"\/redirect?component=advertising&id=2568&url=https:\/\/vc.ru\/promo\/321806-kak-ne-zamorachivatsya-s-reklamnoy-kampaniey-i-bystro-nastroit-ee-v-google-obyasnyaem-v-5-50-i-500-slovah&placeBit=1&hash=842592b001f89eba8e751c8412550d4825bd0026e6df82eb3f2e06239bc3df51","isPaidAndBannersEnabled":false}

Автоматизация тестирования в геймдеве — «Как делают игры. 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как рассказал Шуков, для ПК и консолей их, вероятно, нет. Есть фреймворк 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

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

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

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

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

0
14 комментариев
Популярные
По порядку
Написать комментарий...

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

14

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

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

17

Автотесты - это же не только регресс.

Они так же могут выполнять роль спецификации и документации.

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

Могут использоваться как метрика прогресса, если тесты писать вперёд.

2

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

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

1

Две стороны одного и того же.

Когда вносятся инкрементальные изменения, то важно проверить что ничего не сломано.

Когда вносятся фундаментальные изменения, то полезно знать что именно будет сломано, и в каком объеме.

Например, если проект решил сменить курс в середине разработки.

1
Террористический месяц

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

–1

Получается либо проект был скучным, либо это не ваше. Работаю QA инженером уже более года, никакого бэкграунда нет, самоучка полностью, но очень интересно. Да и мотивация в виде улучшения качества продукта тоже есть, мне кажется тут очень индивидуально. Кто-то любит создавать, кто-то - искать ошибки и проблемы в том, что уже создают/создали. Мне этот стык между тестированием и написанием своего фреймворка интересен, главное найти себя!

5
Террористический месяц

Да, не моё. Я software engineer. Взялся, потому что офер был хороший)

–1

Понимаю) ну здорово, зато теперь знаете что вас интересует другое. В целом пробовать себя в других ролях это хорошо, мне кажется. Я вот на разработчика хотел пойти, в итоге понял, что не для меня) У меня более деструктивный образ жизни и профдеформация уже подтвердила, что у меня любое ПО/сервис/приложение ломается в руках, поэтому видимо такая судьба) 

0

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

Статья понравилась. Довольно простым языком описаны непростые вещи. Единственное, больше хотелось бы почитать, с чего и как стоит начинать автоматизацию.

1
Террористический месяц

До вскукарека про Киберпанк осталось 3...2...1...

–1

сложный конечно подход, далеко не всем доступный

0

Пока не появится унифицированих инструментов для разних движков - автоматизация в геймдеве врядли куда-то двинется. А пока только большие компании вроде Wargaming, смогут позволить себе выделять ресурси для создания тестових фреймворков под свои игри

–1

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

Читать все 14 комментариев
null