Функціональне тестування ігор
Функціональне тестування гри — це не «пограти та знайти баги». Це систематична перевірка того, що кожен игровой сценарій працює відповідно до Game Design Document: механіки, UI-flow, інвентар, прогресія, збереження, мережеві взаємодії. Різниця між «пограли — все працює» та повноцінним функціональним тестуванням зазвичай проявляється при релізі, коли від гравців приходять повідомлення про сценарії, які команда ніколи не тестувала навмисно.
Що функціональне тестування насправді охоплює
Типовий приклад з практики: шутер із системою крафтування. Команда вручну перевірила основний flow — відкрив інвентар, скрафтив предмет, закрив. Все працює. При релізі виявилося, що якщо скрафтити предмет у момент, коли інвентар переповнений (99/100 слотів), а предмет крафту займає останній слот і одночасно є інгредієнтом — лічильник слотів йде в -1, і вся подальша сесія ламається. Це класичний граничний case на перетині двох механік, який знаходиться тільки при систематичному підході до тест-кейсів, а не при вільному дослідженні.
Функціональне тестування у розробці ігор охоплює кілька рівнів:
Геймплейні механіки — кожна механіка тестується окремо, потім у комбінаціях з іншими. Стрибок працює? Стрибок на рухомій платформі? Стрибок у момент отримання шкоди? Стрибок при нульовому HP?
UI та навігація — всі екрани, всі переходи, всі стани елементів (disabled, loading, error). Особливо важливо звернути увагу на переходи між сценами: якщо гравець натискає кнопку «в головне меню» у момент завершення матчу, обидві события можуть спробувати одночасно виконати LoadScene.
Збереження та завантаження — найбільш недооцінена область. Збереження посередині катсцени, завантаження на новому пристрої, міграція даних при оновленні версії. У Unity PlayerPrefs та JSON-serializers не мають вбудованої міграції версій — при зміні структури даних старі збереження просто не парсяться, і гра падає без зрозумілої помилки.
Мережеві сценарії для мультиплеєра: втрата пакетів, вихід гравця в середині матчу, reconnect, десинхронізація стану.
Інструменти та підходи
Для автоматизації функціональних тестів у Unity використовуємо Unity Test Framework (UTF) в режимі Play Mode Tests. UTF дозволяє писати тести, які запускаються всередину гаму сесії з повним доступом до компонентів сцени. Типовий тест на механіку крафтування виглядає так: створити інвентар з предвизначеним станом через фіксчур, викликати CraftingSystem.TryCraft(recipeId), перевірити Assert на стан інвентаря та повернутий результат.
Для UI-тестування використовуємо комбінацію UTF + Unity UI Test Helpers або кастомних обгорток над EventSystem.RaiseEvent. Ручне тестування UI через Selenium або Playwright не застосовується до ігрових інтерфейсів — потрібні інструменти, які розуміють Canvas, EventSystem та InputSystem від Unity.
Для мобільних платформ — Unity Remote для швидкої перевірки на пристрої без повної збірки, та реальні пристрої (не тільки емулятори) для верифікації специфіки платформи: жести, back-кнопка Android, переривання дзвінком.
Дефекти фіксуються в трекері (Jira, YouTrack) з обов'язковими полями: кроки відтворення, очікуваний результат, фактичний результат, версія білда, пристрій, скриншот або відео. Без цього відтворення бага на стороні розробника займає в 3–5 разів більше часу.
Як будується процес
Тестування починається ще до передачі білда: аудит GDD на повноту опису сценаріїв, складання тест-плану та тест-кейсів. Хороший тест-кейс прив'язаний до конкретного вимоги з документації — це дозволяє відслідковувати покриття.
Smoke-тестування нового білда: 15–20 ключових кейсів, які перевіряють, що нічого фундаментального не зламалось. Якщо smoke пройшов — повний регресійний прогін. Функціональне тестування нової фічі — окремо, з фокусом на інтеграційні кейси.
Фінальний етап перед релізом — certification testing: перевірка відповідності вимогам платформи (для Steam, App Store, Google Play, консолей — у кожної свої чеклисти). Це технічно теж функціональне тестування, просто з зовнішніми критеріями.
| Обсяг проекту | Орієнтовні терміни |
|---|---|
| Інді-гра, одиночна гра, до 5 механік | 1–2 тижні |
| Mid-core, мультиплеєр, 10–20 механік | 3–6 тижнів |
| Великий проект, кілька платформ | 2–4 місяці |
| Continuous testing (підтримка релізу) | за договором |
Вартість розраховується після аналізу GDD, кількості тест-кейсів та необхідного покриття.