QA, ИИ и тестирование в геймдеве

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

Поэтому сегодня говорим с нашим лидом QA Кириллом о том, какие задачи выполняет QA, и в какой момент на горизонте появляется искусственный интеллект, способный облегчить или ускорить эту работу.

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

Пока общедоступные модели очень плохо справляются с самыми базовыми задачами по тестированию. Я пробовал генерировать простейшие тест-кейсы почти каждой нейронкой, про которую вспомнил - от ChatGPT до отечественных решений типа GigaChat и YandexGPT. Последние 2 даже интегрировал в нашу TMS [от редактора:система управления тестированием, например, TestRail или Zephyr от Jira], пытаясь получить хоть сколько-либо внятные, сгенерированные на основе требований к фичам, заготовки к тест-кейсам. Почти всегда полученный результат нельзя было использовать даже как болванку, чтобы доработать руками. Невероятный расход тысяч промтов в никуда. Но если мы говорим, например, об автотестах (тем более используя популярные инструменты/фреймворки), то ситуация иная. С помощью ИИ я вполне спокойно нагенерил много тестов для нашего сайта-магазина (Python + Selenium), быстро разобрался в незнакомом ранее языке и собрал адекватный тестовый набор, лишь немного занявшись рефакторингом.

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

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

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

Доступный для общего пользования ИИ в принципе невероятно плох в придумывании тестовых сценариев. Чаще всего это просто тест-кейс в одну строчку с самым банальным действием типа "нажать пробел - персонаж прыгнул". Т.е. не покрываются даже все позитивные проверки, о негативных и думать не приходиться. Сейчас многие пользуются анализом документов в чат-ботах, и, казалось бы, нужно всего-то скормить документ с требованиями к фиче ИИ, описать требования к тест-кейсам и потягивать бабл ти. Увы, даже этот вариант не способен материализовать тестовую документацию минимально приемлемого качества. Насчет выполнения проверок - не скажу, для геймдева точно не знаю таких ИИ-агентов, в других областях, может, они и есть. Проблема в том, что мне не интересны другие области :)

Как я говорил ранее, никто из крупных разработчиков нейросетей почему-то даже не заинтересован в серьезном продукте для/вместо QA. Вероятно, на это есть свои причины. Кроме того сейчас ИИ на той стадии развития, что все, что он родит в любом случае проходит через человеческий контроль качества. Так зачем же делать ИИ-контроль качества, чтобы после него проводить еще и человеческий? Я думаю, если такой инструмент для QA и появится, то все будет происходить точно так же, как с художниками и разработчиками. Он станет не заменой человека, а просто еще одним инструментом, ускоряющим работу.

Думаю, что роль QA в команде станет более важной, соответственно и обязанностей у QA станет больше. Видно, что QA и QC роли на практике слились и довольно давно. Общая тенденция идет к тому, что между Manual/Automation разницы также не останется - специалист будет обязан уметь тестировать как руками, так и заниматься автоматизацией. Лично мне такая тенденция не нравится, но один я против системы не пойду)

Кроме собственно проведения тестирования QA довольно сильно вовлечены в общекомандные процессы и имеют большое на них влияние.

Определенно, развитие ИИ будет иметь вес в изменении роли QA, но здесь пока можно только фантазировать о том, куда ИИ нас заведет.

Есть, но только в ресурсах. Вообще все всегда упирается в ресурсы. Как сказал однажды мой коллега, что я хорошо запомнил: тестировщик не может выдать качества больше, чем этого позволяет бизнес. Условно говоря: у ААА больше ресурсов = выше качество, у инди меньше ресурсов = ниже качество. Но здесь можно возразить, что инди-игры выходят вполне себе удовлетворительными в плане качества, тогда как ААА довольно часто оказываются обсуждаемы как технические провалы. Тут я бы искал ответ в человеческом факторе - инди-разработчики понимают свои возможности и режут хотелки, за что на выходе получают качественный продукт. Неграмотные ААА-разработчики могут забить на обеспечение качества, но взвинтить требования для разработчиков. Конечно, описанные мной выше сценарии не являются правилом. Есть множество причин, почему та или иная ААА/инди игра может выйти качественной или провальной, причем в каком угодно плане - интересная/скучная, оптимизированная/технически провальная и т.д. Главное понимать одно - чем амбициознее и больше игра, тем больше ресурсов она потребует для тестирования при условии, что бизнесу важно качество продукта.

QA прежде всего - человек (нивироятна!!!), а наши продукты мы делаем для людей. Он должен уметь ставить себя на место пользователя и бизнеса. Понимать, какие проблемы для продукта критичны, а какие - нет именно с человеческой точки зрения. В геймдеве, конечно, обязан быть прошаренным игроком. QA - это не только исполнитель рутинных действий по типу "почитать док - написать тестовую документацию - прогнать тесты", он все же исследователь. ИИ может быть натренирован на рутинные задачи, но способность QA к нестандартному мышлению, как я считаю, очень долго будет неподвластна для ИИ, потому что он не способен придумать что-то новое, что он еще не видел.

Невозмутимость и отсутствие какого-либо стыда. Достань всех. Спроси самые тупые вопросы. Покажись самым идиотским идиотом из всех идиотов, но пристань с расспросами ко всем, к кому надо. И докопайся до того, как же все-таки оно действительно должно работать :)

Мое самое любимое - при использовании перка "Ускорение" боевая машина изменяла свою 3D-модель на модель церкви. Следом за этим идет краш в диалоге, где ГГ наконец-то находит любовь всей своей жизни - мрачно и жыжнено.

Все тестирование влияет на метрики, но косвенно. За крупные релизы мы находим в среднем от 100 до 150 багов, из которых ~20% это критические дефекты, и это если команда разработки не косячит. Измерить, насколько мы этим предотвратили падение метрик продукта можно только вылив его со всеми этими багами на прод, выдав игрокам абсолютно не играбельную версию)

И при всем этом все еще можно читать что-то типа: "игру вообще тестируют перед тем, как игрокам отдавать?". Но мы привыкли.

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

Думаю, стоит пояснить, что наша работа - максимально предотвратить падение метрик, тогда как вопрос об их увеличении находится в рамках ответственности других команд, хоть мы и можем давать свои советы, основываясь на большом игровом опыте в тестируемом проекте.

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

Так называемая "База" у QA остается неизменной, поэтому учим ее - а затем смотрим на то, что нужно бизнесу в данный период времени. Дополнительно к базе советую любой популярный в AQA язык программирования и фреймворк для тестирования, а почему - писал выше.

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