Ви випустили патч, що виправляє баг з колайдером. Наступного дня — шквал скарг: у половини гравців не завантажується збереження. Виявляється, колайдер і система збережень залежали від одного ScriptableObject, а порядок ініціалізації компонентів змінився.
Ми називаємо регресійне тестування страховкою від таких сценаріїв. Без нього кожен реліз — лотерея. Наші інженери будують гібридну модель: автотести покривають детерміновану логіку (розрахунки шкоди, інвентар, прогресію, мережеві протоколи), а ручне тестування — візуальні та поведінкові сценарії. Такий підхід знижує кількість багів у продакшені щонайменше на 80% і скорочує час ручних перевірок на 40%.
Чому регресійне тестування ігор складніше, ніж у вебі?
У веб-додатку регресійний тест — запит до API та перевірка відповіді. У грі «зламалася анімація переходу при смерті персонажа» — значить, потрібно запустити сцену, увійти в бій, знизити HP, дочекатися тригера, перевірити, що Animation Controller перейшов у стан Death, Collider вимкнувся, UI смерті показався без артефактів. Повністю автоматизувати таке неможливо. Тому для візуально-орієнтованих проєктів ми використовуємо пропорцію 70% ручного та 30% автоматизованого тестування, для логіко-орієнтованих (стратегії, симулятори) — навпаки. Економія бюджету на регресії сягає 40% при грамотному гібриді.
Як зібрати regression pack для гри?
Основа — regression pack: набір тест-кейсів, що покривають критичні шляхи. Для кожного патча ми визначаємо scope of impact: які системи зачеплені? Якщо правився ІІ ворогів — тестуємо не лише ІІ, але й NavMesh, агресію, лут, досягнення, пов'язані з ворогами.
Для автоматизації використовуємо Unity Test Framework у режимі Play Mode. Тести охоплюють:
- Критичні game-loop сценарії (spawn → combat → death → respawn)
- Інвентар і крафт при граничних значеннях
- Збереження та завантаження з різними версіями даних
- Мережеві події (через мок 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-специфіку і не тестує тепловий тротлінг. Вартість регресії на мобільних можна знизити за рахунок пріоритезації smoke-тестів.
Покроковий план впровадження регресії
- Аналіз scope of impact — визначаємо, які системи зачеплені зміною.
- Формування regression pack — створюємо тест-кейси критичних шляхів.
- Налаштування CI — інтегруємо Unity Test Framework у пайплайн.
- Baseline save-файли — готуємо збережені стани для швидкого старту.
- Регулярні прогони — включаємо регресію в процес кожного білда.
Що входить у deliverables?
Ми створюємо інфраструктуру регресії, яка живе з проєктом:
- Регресійний pack у вигляді документованих тест-кейсів (Google Sheets/TestRail)
- Автоматизований CI з інтеграційними тестами
- Smoke suite для швидкої перевірки кожного білда (50–80 кейсів за 2–4 години)
- Baseline save-файли для ключових точок гри
- Регулярні звіти про покриття та результати прогонів
- Навчання команди з оновлення pack
Приклад matrix ризику: зміна лише UI-віджета — достатньо smoke + екран-специфічна регресія (1–2 години). Зміна SaveSystem — повний прогон обов'язковий (3–7 днів). Зміна EventBus — часткова регресія за scope (1–3 дні). Для детального аудиту зв'яжіться з нами.
Порівняння підходів: ручне vs автоматизоване
| Критерій | Ручна регресія | Автоматизована регресія |
|---|---|---|
| Швидкість прогону | Повільно (години/дні) | Швидко (хвилини) |
| Глибина перевірки | Висока (візуал, поведінка) | Низька (логіка, дані) |
| Вартість підтримки | Низька (немає коду тестів) | Висока (розробка та оновлення) |
| Краще для | Імерсивних сцен, UI, FX | Детермінованої логіки |
Орієнтовні терміни прогону
| Масштаб | Терміни |
|---|---|
| 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 окупається вже на третьому патчі — знижує кількість регресійних багів у продакшені на 80% і скорочує час ручних перевірок на 50%. Вартість формування pack та налаштування CI розраховується після аналізу проєкту. Ми оцінимо обсяг, складність систем і поточне покриття тестами за 1 день. Зв'яжіться з нами для консультації — отримайте попередній план та оцінку. Наша команда QA-інженерів з досвідом у геймдеві від 8 років гарантує результат.
Замовте аудит поточного регресійного покриття — ми знайдемо слабкі місця та запропонуємо план покращень.
Ми використовуємо регресійне тестування та Unity Test Framework як основні інструменти.