ИИ в тестировании игр: от GDD к тест-кейсам за часы
Представьте себе: вы - тестировщик в геймдеве. За день вам предстоит проверять функционал, разбираться с документацией, обновлять кейсы, отслеживать багфиксы и постоянно подстраиваться под изменения в дизайне. В среднем 20-40% рабочего времени уходит на рутину, и это в лучшем случае.
Но зона ответственности QA в игровом проекте куда шире. Помимо функционального тестирования, приходится заниматься:
- sanity-проверками нового функционала;
- регрессионным тестированием перед релизами;
- валидацией багфиксов (а не сломалось ли что-то ещё после исправления);
- исследовательским тестированием (а если игрок сделает Х во время Y);
- тестированием аналитики и A/B-экспериментов;
- проверкой производительности и кроссплатформенной совместимости.
И всё это - часто одновременно. В этой статье разберём, как ИИ-ассистенты помогают разгрузить тестировщика от рутины, и почему мы в студии Sunstrike не считаем их угрозой для профессии.
Нагрузка критическая: от AAA до инди
В крупных проектах одновременно идут десятки фич, GDD-документы вырастают до сотен страниц, постоянные правки и A/B-тесты затрагивают тысячи игроков. QA-отдел буквально утопает в документации и ручной поддержке тест-кейсов.
В небольших командах ситуация ещё жёстче. Один QA-специалист выполняет роль целого отдела. Он же ведёт документацию, он же тестирует билды, он же на лету адаптируется под ежедневные изменения дизайна. Без автоматизации такой специалист быстро выгорает - это особенно заметно в инди-командах и на старте проектов.
В чём боль: ручная работа с документацией
Обычно цикл тестирования начинается с документации. Процесс выглядит так:
- Ознакомление с GDD.
- Декомпозиция фич на тестируемые компоненты.
- Написание первичных тест-кейсов.
- Выявление краевых сценариев.
- Правки и обновления кейсов под актуальный билд.
Самый затратный этап здесь - написание тест-кейсов. На крупную фичу легко уходит 30 часов работы, из которых 70% это рутина: разбор формулировок GDD, декомпозиция, табличное оформление. Именно тут ИИ сегодня даёт самый большой выигрыш.
Решение: ИИ как первый читатель GDD
Что, если вместо десятков часов чтения и структурирования GDD это сделает ИИ, а тестировщик займётся творческим тестированием и анализом?
Для нашего workflow достаточно четырёх вещей:
- ИИ-ассистент (мы используем Claude, ChatGPT и Gemini под разные задачи);
- шаблон промпта для анализа документации;
- сам GDD-документ (docx или pdf);
- шаблон CSV для импорта в TMS.
Звучит просто, но в деталях есть нюансы. Разберём на конкретном примере.
Как это работает: пошагово
Шаг 1. Загрузка документа
Берём страницу GDD - например, с описанием «Системы крафта» - и загружаем в ИИ.
⚠️ Важно: не перегружать модель слишком большим контекстом. Лучше обрабатывать GDD по частям, особенно если механики пересекаются. Например, крафт и инвентарь - это два связанных, но самостоятельных блока, и каждый стоит анализировать отдельно.
Шаг 2. Анализ GDD: промпт на «прочитать»
Перед генерацией кейсов ИИ должен понять, что именно он анализирует. Пример запроса:
«Проанализируй прикреплённый файл CW_2.0.docx (страница 5: “Система крафта”). Выдели:
- основные функции (например, “Создание предмета из ресурсов”);
- жёсткие правила;
- ограничения;
- особые условия.
Подтверди список функций перед генерацией тест-кейсов.»
Этот шаг критичен. Если ИИ сразу перескочит на генерацию кейсов, в 30% случаев он начнёт выдумывать функционал, которого нет в документации. Подтверждение функций - фильтр против галлюцинаций.
Шаг 3. Генерация кейсов: строгое ТЗ
После подтверждения даём ИИ конкретный промпт под формат CSV:
«Сгенерируй тест-кейсы для функции “Система крафта” в формате CSV, как в примере test.csv.
Только текст в формате CSV, без Markdown, заголовков или пояснений.
Каждый кейс включает название, шаги, ожидаемый результат.
Пример:
"Позитивный: Крафт предмета С из А+В","1. Открыть меню...","В инвентаре появился предмет С"»
Жёсткий формат ответа важен: без явных ограничений ИИ обычно добавляет вводные предложения и комментарии, которые потом приходится чистить вручную.
Шаг 4. Экспорт в TMS
Готовый текст копируем → сохраняем как .csv → импортируем в систему управления тестами: TestRail, Qase, Jira или то, что используется на проекте.
На выходе получаем полноценный черновик тест-кейсов, который можно использовать сразу после минимальной правки. На наших игровых проектах такой workflow стал стандартом ещё в 2024 году.
Шаг 5. Обязательная ручная проверка
ИИ не тестировщик и не знает специфики проекта. Поэтому после импорта QA-специалист:
- удаляет повторяющиеся или неактуальные кейсы;
- добавляет недостающие сценарии (особенно креативные и нестандартные);
- проверяет соответствие текущему билду игры;
- расставляет приоритеты по риску.
Этот этап нельзя пропускать. Без ручной проверки в продакшен пойдёт половина кейсов, не относящихся к актуальному состоянию игры.
Почему ИИ не заменил тестировщиков
За год работы с ИИ-ассистентами в QA-процессах мы накопили список типичных проблем. Они одинаково проявляются у всех моделей.
Галлюцинации. Однажды ИИ сгенерировал нам кейсы про «систему пробоя стен», хотя в GDD говорилось только про разрушение ресурсов. Стены ИИ домыслил из контекста, и без ручной проверки эти кейсы попали бы в TMS. На реальном билде они оказались бы невыполнимы.
Дублирование. Примерно 20% сгенерированных кейсов повторяют друг друга разными словами. ИИ переформулирует тот же сценарий несколько раз, пытаясь набрать «полное покрытие». Без чистки получается раздутая, но неинформативная база.
Недостаток креатива. ИИ хорошо генерирует позитивные сценарии «всё работает как задумано». Но он почти не предлагает странных краевых случаев - например, никто из моделей не подумал проверить крафт во время прыжка. А именно этот баг мы потом нашли в реальной игре.
ИИ умеет хорошо «читать» и структурировать. Но «фантазировать» как опытный игрок-тестировщик пока не умеет ни одна модель.
Сравнение: раньше и сейчас
📊 Раньше (полностью ручной процесс):
- Чтение GDD и создание тест-кейсов на крупную фичу: ~30 часов.
- Из них: 70% - рутина (декомпозиция, структурирование, табличное оформление).
- Креативная часть (краевые сценарии): 30%.
⚙️ Сейчас (ИИ-ассистент + ручная доводка):
- Черновик от ИИ: 30-40 минут.
- Проверка и доработка тестировщиком: 6-8 часов.
- Экономия: до 20 часов на одну крупную фичу.
Что важно: общее время на QA-фазу не сократилось пропорционально. Освободившееся время тестировщики тратят на исследовательское тестирование и нестандартные сценарии - то есть на ту работу, где их экспертиза реально нужна.
ИИ как инструмент, а не замена
ИИ не заменяет тестировщика. Но он меняет саму суть подхода: с рутинного на аналитический. Это особенно важно в игровой разработке, где качество билдов напрямую влияет на удержание игроков и репутацию студии.
Плюсы внедрения ИИ в QA-процесс:
- скорость генерации базового покрытия;
- разгрузка тестировщика от рутины;
- более широкое первоначальное покрытие сценариев.
Минусы и ограничения:
- требует обязательной ручной проверки;
- не заменит творческое тестирование;
- периодически ошибается в логике или придумывает несуществующий функционал.
ИИ обрабатывает GDD как «сырой камень», тестировщик шлифует его в алмаз. Вместе они работают в идеальном тандеме: один находит, другой дополняет. Так мы перестали тратить силы на очевидное и начали концентрироваться на сложном - а значит, делать игры качественнее.
Если вам интересна тема выбора и оценки QA-специалистов в команду, мы недавно разобрали её в отдельном материале: как выбрать тестировщика для проекта.
Иллюстрации: Pexels (CC0).