Функціональне тестування ігор: від GDD до готовності до релізу

Чому граничні сценарії — головна проблема геймплейного тестування? — функціональне тестування ігор

Ми верифікуємо кожну механіку, UI-флоу, стан інвентарю, прогресію, збереження та мережеві взаємодії. Це не просто пошук багів, а системний підхід. Наш досвід показує: команди, які замовляють повне функціональне тестування, скорочують кількість post-release інцидентів на 40–60%. При цьому регресійні прогони виконуються в 6–12 разів швидше завдяки автоматизації.

Приклад із практики: шутер із системою крафту. Команда вручну перевірила основний флоу — відкрив інвентар, скрафтив предмет, закрив. Усе працює. На релізі з'ясувалося: якщо скрафтити предмет у момент, коли інвентар переповнений (99/100 слотів), а предмет крафту займає останній слот і одночасно є інгредієнтом — лічильник слотів іде в -1, і сесія ламається. Це класичний граничний кейс на перетині двох механік, який знаходиться лише при системному підході до тест-кейсів.

Які шари ігрової системи ми перевіряємо?

Функціональне тестування в геймдеві охоплює кілька шарів:

• Геймплейні механіки — кожна механіка тестується ізольовано, потім у комбінації. Стрибок працює? Стрибок на платформі, що рухається? Стрибок у момент отримання урону? Стрибок при нульовому HP? Таких комбінацій може бути більше 50 на одну механіку.
• UI та навігація — всі екрани, переходи та стани елементів (disabled, loading, error). Особлива увага до переходів між сценами: якщо гравець натискає кнопку «в головне меню» в момент завершення матчу, обидві події можуть спробувати зробити LoadScene одночасно. Ми автоматизуємо до 200 таких кейсів за проєкт.
• Збереження та завантаження — збереження посеред катсцени, завантаження на новому пристрої, міграція даних при оновленні версії. У Unity PlayerPrefs та JSON-серіалізатори не мають вбудованої версійної міграції — при зміні структури даних старі збереження не парсяться, і гра крашиться. Ми перевіряємо 15+ типів збережень.
• Мережеві сценарії для мультиплеєра: втрата пакетів, вихід гравця, реконнект, десинхронізація. В середньому 300 тестів на один мережевий протокол.

Як автоматизація функціональних тестів скорочує час прогону?

Для автоматизації використовуємо Unity Test Framework (UTF) з Play Mode Tests. UTF дозволяє писати тести з повним доступом до компонентів сцени. Типовий тест на механіку крафту: створити інвентар із визначеним станом через фікстуру, викликати CraftingSystem.TryCraft(recipeId), перевірити Assert на стан інвентарю. Як зазначено в Unity Test Framework guide, play mode tests емулюють фізику та анімації в тестовому середовищі.

Для UI використовуємо комбінацію UTF та Unity UI Test Helpers. Для мобільних платформ застосовуємо Unity Remote для швидкої перевірки на девайсі без повної збірки та реальні пристрої (не лише емулятори) для верифікації жестів, back-кнопки та переривань.

Дефекти фіксуються в трекері (Jira, YouTrack) з полями: кроки, очікуваний результат, фактичний результат, версія білда, пристрій, скріншот. Без цього відтворення займає в 3–5 разів більше часу. За проєкт ми обробляємо в середньому 500–800 дефектів.

Автоматизація скорочує час регресійного прогону в 6–12 разів, а покриття граничних сценаріїв збільшується в 2–3 рази.

Що входить у роботу?

Ми надаємо повний набір deliverables:

• Тест-план із прив'язкою до вимог GDD (в середньому 200+ тест-кейсів на проєкт).
• Набір автоматизованих тестів (якщо застосовно).
• Звіт про покриття тест-кейсів (досягаємо 95–100%).
• Логи всіх знайдених дефектів із детальними кроками відтворення.
• Підсумковий звіт із рекомендаціями.

Як будується процес тестування?

1. Аудит GDD — до передачі білда аналізуємо документацію на повноту опису сценаріїв.
2. Розробка тест-плану — для кожної механіки мінімум 3 тест-кейси (щасливий шлях, граничний, помилковий).
3. Smoke-тестування — 15–20 ключових кейсів за 2 години.
4. Повний регресійний прогін (ручний + автоматичний).
5. Функціональне тестування нової фічі з фокусом на інтеграцію.
6. Сертифікація платформ — перевірка за чеклистами Steam, App Store, Google Play, консолей.

Орієнтовні терміни

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

Тестування та QA

Ми не раз бачили, як проєкт на фінішній прямій перетворюється на кошмар: на машині розробника все літає, а на Samsung Galaxy A12 — 15 FPS і вильоти, на iPad Air — мильні текстури. Без вибудуваного QA-процесу тестування ігор стає лотереєю. Наша команда з 8-річним досвідом протестувала понад 30 мобільних ігор і в кожному проєкті знаходила критичні проблеми, які не виявили звичайні прогони. Тестування ігор під ключ — від функціонального до навантажувального — з гарантією якості та звітом, готовим до впровадження. Оцінимо ваш проєкт за 3 дні — зв'яжіться з нами.

Як автоматизувати тестування в Unity?

Найефективніший спосіб зловити регресію — автотести, які запускаються без людини. У Unity це Unity Test Framework (UTF) на базі NUnit. Два режими.

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

Приклад:

[UnityTest]
public IEnumerator PlayerTakeDamage_HealthReduces()
{
    var go = new GameObject();
    var health = go.AddComponent<HealthComponent>();
    health.Initialize(100);

    health.ApplyDamage(30);

    yield return null;

    Assert.AreEqual(70, health.CurrentHealth);
}

Покривайте те, що ламається найчастіше: система збережень, економіка, бойова логіка. 100% покриття не потрібне — достатньо критичних шляхів. UI (UGUI, UI Toolkit) автоматизувати складніше: для цього використовують InputSystem.QueueEvent або Appium на мобільних платформах. Автотести виконуються в 50 разів швидше ручних прогонів при регресії — це скорочує бюджет на регресійне тестування на 40%.

Чому профілювання на реальному пристрої критичне?

Тести не ловлять проблеми продуктивності. Для цього потрібен профілювальник на цільовій платформі. Unity Profiler — стартова точка. Ключові кроки:

1. Профілюйте на пристрої, а не в редакторі — Editor додає оверхед. Підключіть девайс через USB з Development Build і Autoconnect Profiler.
2. Дивіться Main Thread і Render Thread окремо. Типові проблеми:
   • Physics.FixedUpdate >2ms — складна фізика
   • Canvas.BuildBatch на кожному кадрі — зайві Dirty виклики UI
   • GC.Collect — виділення пам'яті в гарячому шляху (всередині Update)
3. Використовуйте ProfilerMarker для локалізації:

using Unity.Profiling;

static readonly ProfilerMarker k_PathfindMarker = new ProfilerMarker("Pathfinding.Calculate");

void UpdateAI()
{
    using (k_PathfindMarker.Auto())
    {
        // pathfinding code
    }
}

Memory Profiler (пакет com.unity.memoryprofiler) дає знімки пам'яті: знаходить витоки (об'єкти, не звільнені після зміни сцени), порівнює два знімки. Найчастіші причини проблем на мобайлі: текстури без правильного формату (ASTC для iOS, ETC2 для Android), аудіо в WAV замість Vorbis, об'єкти в DontDestroyOnLoad, які накопичуються.

Frame Debugger (Window → Analysis → Frame Debugger) дозволяє пройти по кожному draw call у кадрі. Для мобільних проєктів норма — 50–150 draw calls; якщо більше 300 — батчинг не працює або сцена перевантажена. Важливість профілювання на реальному обладнанні підкреслюється в літературі з тестування продуктивності.

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

Функціональне та регресійне тестування

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

Інструменти управління: TestRail, Qase, Zephyr. Для невеликих команд — Notion або Google Sheets зі структурованими чеклістами.

Тестування на реальних пристроях

Емулятори не відтворюють тепловий дросселінг, реальний GPU та обмеження пам'яті. Мінімальний набір — 20+ пристроїв усіх сегментів:

Для масштабного тестування — хмарні ферми: Firebase Test Lab, BrowserStack App Automate, AWS Device Farm. Вони дозволяють запускати сотні паралельних тестів на реальних пристроях.

Навантажувальне тестування (мультиплеєр)

Мета — знайти деградацію сервера до релізу. Інструменти: k6 (WebSocket/HTTP API), Gatling (складні сценарії зі станом). Для специфічних протоколів пишуть кастомний stress-клієнт на Go або C#.

Параметри перевірки:

• Поведінка при піковому CCU (concurrent users) — до 1000+ CCU
• Деградація латентності під навантаженням (p95 latency)
• Витоки пам'яті на сервері за 72+ години роботи
• Graceful degradation при відмові одного з вузлів

Краш-репортинг та моніторинг

Після релізу QA продовжується через моніторинг. Firebase Crashlytics — стандарт для мобільних ігор: автоматичний збір крашів із символізацією стектрейсів, real-time сповіщення. Sentry — для серверних компонентів і WebGL. ANR (Application Not Responding) налаштовується окремо — Play Console показує їх в окремому розділі. Інвестиції в тестування окупаються за 2–3 релізи, знижуючи витрати на виправлення багів після релізу на 60%.

Що входить у нашу роботу

• Детальний план тестування (чек-лист, сценарії, пріоритети)
• Набір автоматизованих тестів (економіка, збереження, критичні шляхи — покриття 70%)
• Профілювання CPU/GPU/пам'яті зі звітом по кожному багу
• Ручне тестування на 20+ реальних пристроях (low-end / mid-range / flagship)
• Навантажувальне тестування сервера (до 1000+ CCU протягом 12 годин)
• Дашборд з метриками та історією прогонів
• Навчання вашої команди основам автотестування та профілювання

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

Процес роботи

1. Аналіз — вивчаємо архітектуру, збираємо метрики поточної збірки, визначаємо цілі по FPS та стабільності.
2. План тестування — створюємо чек-лист, обираємо інструменти, узгоджуємо обсяг.
3. Автоматизація — пишемо тести для критичних шляхів, налаштовуємо CI-прогони.
4. Ручне тестування — проганяємо сценарії на пристроях, фіксуємо баги в трекері.
5. Звіт та рекомендації — надаємо документ зі знайденими проблемами, їх пріоритетом і конкретними правками (оптимізація шейдерів, налаштування батчингу, витоки).

Наші метрики

• 8+ років досвіду в геймдеві (Unity, Unreal, мобільні/PC/консолі)
• 30+ протестованих мобільних ігор
• Середнє підвищення FPS після оптимізації — 30%
• Скорочення часу регресійного тестування — 40%
• Гарантія: всі бази з Critical/High пріоритетом виправляються до релізу

Типові помилки в QA-процесі

• Тестування лише на флагманах — більшість гравців на mid-end і low-end.
• Відсутність автотестів для економіки та збережень — вони ламаються при будь-якому рефакторингу.
• Пропуск навантажувального тестування сервера — гра виходить, набирає 10k DAU і сервер лягає.
• Регресія тільки перед мажорними релізами — критично перед кожним публічним оновленням.

Замовте тестування ігор під ключ. Ми оцінимо ваш проєкт за 3 дні та запропонуємо план з гарантією результату. Пишіть — розберемо вашу збірку безкоштовно.