Как ИИ стал секретным оружием в тестировании игр — кейс SunStrike

Команда SunStrike поделилась с редакцией App2Top кейсом имплементации ИИ в пайплайн тестирования игровых проектов.

Автор — коллектив QA-департамента SunStrike

Введение

Если вы управляете разработкой игры или отвечаете за ее качество, то знаете, как выглядит день тестировщика: проверка функционала, работа с документацией, обновление кейсов, багфиксы, изменения дизайна — и все это одновременно. Рутинные задачи съедают 20-40% времени. Иногда больше.

Но на деле зона ответственности QA еще шире. В реальности тестировщик также занимается:

• sanity-проверками нового функционала;
• регрессионным тестированием перед релизами;
• валидацией багфиксов (после фикса необходимо убедиться, не сломалось ли что-то еще);
• исследовательским тестированием (а если игрок сделает Х во время Y?);
• верификацией внутриигровой аналитики;
• проверкой производительности и стабильности;
• кроссплатформенным и кроссбраузерным тестированием.

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

Нагрузка критическая: от AAA до инди

В крупных проектах работа обычно ведется с десятками фич одновременно, GDD вырастают до сотен страниц, происходят постоянные правки и A/B-тесты на тысячах пользователей. В таких условиях QA-отдел перегружен: ручное обновление кейсов и чтение документации занимают значительную часть времени.

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

В чем боль: ручная работа с документацией

Обычно цикл тестирования начинается с документации. Процесс по шагам выглядит так:

1. ознакомление с GDD;
2. декомпозиция фич;
3. написание первичных тест-кейсов;
4. выявление краевых сценариев;
5. правки и обновления кейсов.

Алгоритм разработки тестовой документации в ручном режиме

Какой этап самый затратный? Конечно же, написание тест-кейсов. Именно здесь ИИ уже сегодня может стать отличным помощником.

Решение: ИИ как первый читатель GDD

Что, если всю первичную работу с GDD (чтение, разбор, оформление кейсов) можно передать ИИ, а тестировщик при этом сосредоточится на том, что машине пока не под силу: креативных сценариях, проверке логики и аналитике?

Для начала потребуется:

• ИИ-ассистент (например, ChatGPT, Claude или Gemini);
• шаблон промпта;
• GDD (в формате .docx или .pdf);
• шаблон CSV-файла.

Выглядит просто, но есть нюансы. Разберем на примере.

Как это работает: пошагово

1. Загрузка документа

Загружается конкретная страница GDD, например, с описанием «Системы крафта» в выбранную модель.

2. Анализ GDD: промпт

Перед генерацией кейсов ИИ должен понять, что именно он анализирует. Пример запроса:

«Проанализируй прикрепленный файл CW_2.0.docx (страница 5: ‘Система крафта’). Выдели:

• основные функции (например, «Создание предмета из ресурсов»);
• жесткие правила;
• ограничения;
• особые условия.

Подтверди список функций перед генерацией тест-кейсов.»

3. Генерация кейсов: строгое ТЗ

После подтверждения можно запрашивать тест-кейсы в формате CSV:

«Сгенерируй тест-кейсы для функции «Система крафта» в формате CSV, как в примере test.csv.

Только текст в формате CSV, без Markdown, заголовков или пояснений.

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

Пример:

«Позитивный: крафт предмета С из А+В»,»1. Открыть меню…»,»В инвентаре появился предмет С»».

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

4. Экспорт в TMS

Готовый текст копируем, а затем сохраняем как .csv, и дальше импортируем в систему управления тестами (TestRail, Qase, Jira и др.).

На выходе получаем полноценный черновик тест-кейсов, который можно использовать сразу после минимальной правки.

Что дальше? Ручная проверка!

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

Поэтому роль QA-специалиста остается ключевой:

• удаление дублирующихся и не актуальных кейсов;
• добавление нестандартных и креативных сценариев;
• проверка соответствия кейсов реальному билду игры.

Алгоритм разработки тестовой документации с использованием ИИ

Где ИИ ошибается: типовые проблемы

Вот несколько типичных проблем, которые мы обнаружили:

• галлюцинации: модель сгенерировала кейс про «систему пробоя стен», хотя в GDD упоминалось только вскользь разрушение объектов;
• дублирование: около 20% кейсов повторялись с разными формулировками;
• недостаток креатива: при генерации не был предложен кейс, описывающий поведение системы крафта во время прыжка — баг был найден позже вручную.

ИИ умеет хорошо «читать» и структурировать, но не «фантазировать», как человек.

До и после внедрения ИИ

При ручной работе:

• чтение GDD и написание кейсов занимали до 30 часов;
• из них около 70% — чисто рутинные задачи.

После внедрения ИИ:

• генерация черновика кейсов — 30-40 минут;
• проверка и доработка — еще 6-8 часов.

Итоговая экономия — до 20 часов на одну крупную фичу.

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

Заключение: ИИ — не волшебник, но эффективный инструмент

Искусственный интеллект не заменяет тестировщика — он перераспределяет фокус с рутинной работы на аналитику, нестандартные сценарии и качество.

Плюсы:

• ускорение подготовки тест-кейсов;
• масштабируемое базовое покрытие;
• снижение нагрузки на команду.

О чем стоит помнить:

• результаты требуют ручной проверки и адаптации;
• креативные сценарии остаются за человеком;
• возможны дубли и логические ошибки.

Вывод

ИИ — это инструмент. Он быстро превращает GDD в рабочий черновик, но финальное качество зависит от самих специалистов: именно им предстоит превратить заготовку в ограненный бриллиант.

Мы применяем подход в живых проектах и продолжаем его развивать. Если сталкиваетесь с похожими задачами — будем рады поделиться опытом.