AI-система автотестування та QA для ігор: розробка під ключ

ШІ-тестування ігор: де ламається ручний QA-прогін

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

Чим більший проєкт, тим менше часу залишається на сценарії, які гравець реально відтворює вже в першій сесії.

Хибні спрацювання тестів з'їдають не час прогону, а довіру до нього. Перевірка блимає через несинхронізовану анімацію, спливаюче вікно з подією або різний час завантаження рівня — і інженер звикає ігнорувати червоний результат.

Після цього справжня відмова проходить повз: звіт зелений, дефект у релізі, а зсув строків пояснюють «нестабільною збіркою».

Покриття ігрових сценаріїв упирається в комбінаторику: стан інвентарю, прогрес, складність, кооп на трьох. Руками такі гілки не перебрати, а скриптові прогони зазвичай перевіряють лише основний шлях.

Непокритою залишається саме та частина, де ламається найчастіше — перехід між станами та збереження прогресу.

Окрема стаття — візуальна звірка: зсунутий елемент інтерфейсу на іншій роздільній здатності руками шукають по пачці знімків. Наші інженери працюють зокрема з проєктами на Unity і знають, що у збірці дає плаваючий результат.

Далі розбираємо, як це закривається: як будується ШІ-тестування ігор і автоматизація QA для ігор, за якої прогін залишається стабільним і зростає разом із проєктом.

Що змінюється після впровадження: ефект у вимірюваних числах

Ефект автоматизації QA видно не за кількістю написаних перевірок, а за чотирма величинами: скільки триває повний регрес, яку частку перевірок система підтверджує сама, скільки дефектів доходить до гравців і як часто ламається збірка. Нижче — як змінюється кожна з них після впровадження.

Скорочення часу регресійного прогону

• Повний прогін критичними шляхами уміщується в одну ніч замість кількох днів ручної перевірки: сценарії розпаралелено за ігровими збірками та конфігураціями.
• Звіт за своєю гілкою розробник отримує за хвилини, а не наприкінці циклу, — правка потрапляє у збірку, поки контекст ще в голові.

Менше хибних спрацювань і блимаючих перевірок

• Частка хибних спрацювань падає до одиниць відсотків: очікування готовності сцени та завантаження ресурсів замість фіксованих пауз.
• Блимаючі перевірки виносяться в окремий список і не розмивають звіт — червоний статус знову означає реальний дефект.
• Кожне падіння зберігає запис проходження, логи клієнта та кроки відтворення: розбір займає хвилини, а не години.

Покриття перевірок і стабільність збірки

• Покриття зростає насамперед на критичних шляхах — запуск, прогрес, платежі, мережеві сесії. Сценарії, до яких не доходили руки, стають регулярними.
• Кількість пропущених дефектів знижується: регрес іде на кожній збірці, включно з нічними та гілками на Unreal Engine.
• Окремий клас відмов збірки зникає — нестабільність і падіння ловляться до того, як збірка піде в публікацію.

Режими прогону: записаний сценарій, автономний агент, гібрид

Режим прогону визначає, що вважається результатом перевірки: повтор дій із запису чи рішення агента про те, що стан гри зламано.

У першому випадку еталон — зафіксована послідовність подій і знімок стану, у другому — набір правил і модель поведінки, за якими агент сам обирає, куди йти й що натискати. Змішування цих моделей без явної межі й дає хибну впевненість у покритті.

Коли достатньо записаних сценаріїв

Якщо механіки усталилися, а екрани змінюються передбачувано, записані сценарії закривають регрес найдешевше: прогін повторюваний, розходження з еталоном означає конкретну поломку, а не шум.

Прив'язку варто тримати за стійкими вузлами — старт рівня, видача нагороди, перехід між екранами, — тоді частину правок графіки й тексту прогін не рве. Обмеження режиму в тому, що він перевіряє лише пройдені вручну шляхи.

Коли потрібен автономний агент і гібрид

Агент бере те, що не масштабується руками: довгі сесії, рідкісні поєднання станів, глухі кути навігації, витоки ресурсів.

Гібридний підхід до QA будується навколо спільного журналу прогону: агент шукає нові стани, а відтворюваний шлях переноситься в записаний сценарій і йде в регрес.

Так обмеження автотестів стають вимірюваними — видно, яка частка перевірок детермінована, а яка тримається на дослідженні.

Етапи впровадження ШІ-агента: аудит, схема, перевірка, передача

Впровадження агента — не встановлення інструмента, а послідовність кроків, де кожен спирається на артефакти попереднього. Якщо пропустити аудит покриття, агент упевнено перевіряє те, що й так не ламалося, і мовчить там, де регресія йде в реліз.

Аудит покриття та постановка схеми перевірок

1. Інвентаризація перевірок — вивантажуємо тест-кейси, автотести та ручні чек-листи, зіставляємо з картою ігрових систем: бій, економіка, прогресія, мережеві сценарії. На виході — список шляхів, які не покриває жоден прогін.
2. Відбір нестабільних перевірок — позначаємо тести, які плавають і потребують ручного розбору логів; їх або робимо детермінованими, або виводимо з обов'язкового набору.
3. Схема перевірок і пріоритети — фіксуємо, що агент ганяє на кожен коміт, що на нічних прогонах, а що перед релізом. Пріоритет рахуємо за ціною пропущеного дефекту, а не за кількістю тестів.

Налаштування, перевірка на стенді та передача

• Налаштування на стенді — розгортаємо агента на копії бойового середовища, з тими самими збірками й обліковими записами, навчаємо на реальних логах і записах сесій.
• Пілотний запуск — проганяємо на минулих релізах, де дефекти вже відомі, і рахуємо, скільки з них агент знайшов сам. Частку хибних спрацювань знижуємо до прийнятної, перш ніж розширювати охоплення.
• Приймання та передача — демонстрація на живому дефекті, передача конфігурації, схеми перевірок і регламенту розбору, навчання вашої команди тестування. Далі підтримку веде вона або ми за узгодженим регламентом.

Що залишається у команди: конфігурації, звіти, регламенти

Зміни в поведінці автотестів фіксуються як артефакти в репозиторії проєкту, а не в листуванні чи голові інженера. Після передачі команда може перезапустити прогін, відтворити дефект і пояснити, чому конкретний сценарій було позначено як падіння. Нижче — комплект, який передається разом із працюючою системою.

Конфігурації агента та пріоритети запуску

• Файли конфігурації агента: параметри запуску клієнта, набори вхідних пристроїв, точки старту сценаріїв — правляться без перезбирання самого агента.
• Карта покриття сценаріїв: «ігровий модуль → сценарій → статус автоматизації» з явною позначкою прогалин, які залишилися на ручній перевірці.
• Правила пріоритетів запуску: що ганяється на кожну зміну, що за розкладом, що лише перед релізом — з обґрунтуванням меж.
• Скрипти підготовки середовища та еталонні дані, щоб повторний прогін на іншій машині давав той самий результат.

Звіти, регламенти та інструкції

• Шаблони звітів про прогони: підсумок за збіркою, падіння з прив'язкою до кроку сценарію, логи та відеозапис моменту.
• Шаблон звіту про дефект: відтворюваність, умови, очікувана й фактична поведінка — розробник бере в роботу без уточнювальних запитань.
• Регламент QA і розбору спірних спрацювань: строки реакції, хто вирішує «дефект чи нестабільний сценарій», як фіксується підсумок.
• Інструкції для інженерів: як додати сценарій, оновити карту покриття, відкотити конфігурацію агента до попередньої версії.

Кейс: як автономний агент закрив регрес перед релізом

Кейс автоматизації QA в ігровій студії: багатокористувацький проєкт із сезонними патчами — раз на шість тижнів нова збірка й обов'язковий регрес перед публікацією в Steam.

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

Метрики до та після на релізному циклі

Що змінили: регрес виконує автономний агент — він розгортає збірку, проходить сценарії під навантаженням і сам позначає, де поведінка розходиться з еталонною.

Цінність не у швидкості прогону, а в розборі результату: агент відділяє мережевий шум і блимаючі перевірки від справжніх дефектів, тому звіт читається без ручної переперевірки.

Інженери переключилися з повторення чек-листа на нові сценарії та розбір спірних місць — покриття зростає, а не впирається в кількість людей.

Що робити, якщо базові перевірки вже закриті автотестами?

Якщо базові перевірки вже закриті автотестами, агента не ставлять замість них — він вбудовується поверх наявного набору.

Детермінований регрес за фіксованими сценаріями залишається за скриптами: він дешевший у прогоні, дає однозначний вердикт і не потребує розбору «чому система вирішила саме так». Агент підключається там, де жорсткий сценарій перестає працювати.

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

Міграція сценаріїв робиться так: обидві схеми проганяються на одній збірці, вердикти порівнюються, а розходження розбираються до того, як старий скрипт вимкнуть.

Поєднання підходів і є основним режимом роботи. Стара схема залишається основною на передбачуваних шляхах — завантаження, збереження, мережеві сценарії, детерміновані перевірки урону та інвентарю.

Агент закриває прогалини в покритті: рідкісні перетини механік, стани, до яких сценарист не додумався, місця, де раніше дефект знаходили лише вручну.

Критерій простий: відтворюваність і ціна хибного спрацювання. Якщо перевірка дає стабільний однозначний вердикт — вона залишається скриптом.

Якщо вердикт потребує судження або сценарій неможливо зафіксувати заздалегідь — він переходить агенту, а результат додається логом дій для ручного розбору. Так покриття зростає без переписування всього набору.

Технічні сумніви перед пілотом: розбираємо за пунктами

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

Наскільки часті хибні спрацювання?

Пороги калібруються на еталонних прогонах: розходження спочатку позначаються як підозрілі, інженер підтверджує або відхиляє їх. Після калібрування звіт звужується до реальних дефектів.

Який доступ до збірок потрібен?

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

Що при зміні інтерфейсу?

Прив'язка йде до елементів та їхнього стану, а не до координат, тому зсув кнопки прогін не ламає. Нові екрани потребують перезнімання еталонів — це процедура на кілька годин, а не переписування сценаріїв.

Хто підтримує після передачі та які строки пілота?

Передаємо сценарії, конфігурації, еталони й документацію, навчаємо команду розширювати перевірки. Пілот іде ітераціями з проміжними результатами, підтримка далі — за договором з обумовленим часом реакції.

Обговоримо задачу та повернемося з оцінкою і планом робіт

Старт пілота не потребує готового стенда й повного пакета документації — достатньо мінімального контуру, на якому перевірки почнуть знаходити реальні дефекти. Чим точніше описані критичні сценарії та обмеження, тим менше часу йде на перший прогін.

Щоб перейти від розмови до старту пілота, від замовника потрібен мінімальний набір — вимоги до запуску зводяться до шести пунктів:

• Доступ до тестового стенда або збірки — на стабільній версії, де дефекти відтворюються, а дані між прогонами не перетираються.
• Перелік критичних сценаріїв: старт сесії, бій, економіка, мережевий режим, службові панелі — те, поломка чого коштує найдорожче.
• Тестові облікові записи з потрібними ролями та рівнями доступу, включно з внутрішніми.
• Вікно на перевірки — години, коли стенд вільний і його не займають інші команди.
• Точки запуску автотестів або інтерфейс, через який перевірки стартують без ручного збирання.
• Відповідальний за приймання з вашого боку — той, хто підтверджує критерії готовності й приймає результат.

Далі ми збираємо план робіт із QA: розбиваємо обсяг на етапи, фіксуємо критерії виходу за кожним і називаємо строк першої ітерації. Готові обговорити задачу предметно — опишіть поточний стан тестування, і повернемося з оцінкою та планом, де видно, що і коли ви отримуєте.