Регресійне тестування ігор
Регресійне тестування — це не про пошук нових багів. Це про підтвердження того, що старі баги не повернулись, а робочі сценарії не зламалися після останніх змін. Без нього кожен новий патч — це лотерея: розробник чинить collider персонажа, а система збереження ламається, тому що вони обидва залежать від одного ScriptableObject-контейнера, якого ніхто не чіпав, але порядок ініціалізації компонентів змінився.
Чому регресія в іграх складніша, ніж в звичайному ПО
В звичайному веб-додатку регресійний тест — це запит до API та перевірка відповіді. В грі «анімація сломалась при смерті персонажа» означає: запустити сцену, увійти в боєвий режим, знизити HP до нуля, чекати на тригер анімації, перевірити, що Animation Controller перейшов у стан Death, що Collider відключився в потрібний момент, що UI смерті з'явився без артефактів.
Це складно автоматизувати повністю. Тому регресія в іграх зазвичай працює в гібридній моделі: автотести охоплюють детерміновану логіку (розрахунки шкоди, інвентар, прогресія, мережеві протоколи), ручне тестування охоплює візуальні та поведінкові сценарії.
Конкретний випадок: у мобільному RPG після оновлення системи діалогів тригер досягнення «провести 10 розмов» зламався. Автотест на DialogueManager.OnDialogueComplete пройшов — подія викликалась. Але логіка підрахунку переїхала в інший клас і втратила підписку на подію. Ручний тест знайшов це за 10 хвилин; автотест — ні, тому що перевіряв тільки виклик подіі, а не фінальний стан лічильника досягнення.
Як будується регресійний набір для гри
Основа — regression pack: набір тест-кейсів, що охоплюють критичні шляхи. Для кожного патчу визначаємо scope of impact: які системи зачепляє зміна? Якщо чинили AI ворогів — тестуємо не тільки AI, але й все, з чим він взаємодіє: NavMesh, агресія, лут, досягнення, пов'язані з ворогами.
Для автоматизації використовуємо Unity Test Framework в режимі Play Mode з тестами, що охоплюють:
- Критичні game-loop сценарії (спавн → бій → смерть → respawn)
- Інвентар та крафтування при граничних значеннях
- Збереження та завантаження з різними версіями даних
- Мережеві события (через mock Photon-клієнта або Mirror NetworkManager в offline-режимі)
Тести запускаються через Unity Cloud Build або локальний CI (Jenkins, GitHub Actions) на кожен коміт в main/develop. Якщо набір з 200 тестів проходить за 8 хвилин — прийнятно. Якщо за 40 хвилин — потрібно розділити тести на швидкі (smoke) та повільні (full regression), запускати за графіком.
Для мобільних платформ регресійний прогін додатково проходить на реальних пристроях через Firebase Test Lab або фізичну device farm — емулятор не відтворює OpenGL ES/Vulkan-специфіку та не тестує тепловий throttling.
Пріоритизація та обсяг
Не кожен bug-fix вимагає повного регресійного прогону. Використовуємо матрицю ризику: наскільки зміна торкається спільних систем (EventBus, SceneManager, SaveSystem)? Якщо чинили тільки UI-widget одного екрана — достатньо smoke + специфічна для екрана регресія. Якщо менялась SaveSystem — повний прогін обов'язковий.
Важливий артефакт — regression baseline: збережені стани гри для кожного типового сценарію. Це дозволяє почати тест не з початку гри, а з потрібної точки — економить години ручного тестування.
Після кожного релізу патча оновлюємо regression pack: баги, знайдені в цьому циклі, стають новими тест-кейсами. Так набір зростає та охоплює реальні регресійні ризики, а не гіпотетичні.
| Масштаб | Орієнтовний час прогону |
|---|---|
| Smoke regression (50–80 кейсів) | 2–4 години |
| Partial regression (scope of impact) | 1–3 дні |
| Full regression pack | 3–7 днів |
| Automated CI regression (кожен білд) | 15–60 хвилин |
Вартість формування regression pack та настройки CI розраховується після аналізу проекту.