Как подготовить мобильную игру к тестированию

Когда новичок в студии слышит «подготовить игру к тесту», он часто думает, что достаточно нажать Build и скинуть APK тестировщикам. На практике это верный способ потратить дни на разбор хаотичных баг-репортов и пропустить критические проблемы. Грамотная подготовка превращает тестирование из лотереи в воспроизводимый, быстрый и полезный для разработки процесс.

Зачем вообще готовить игру перед тестом

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

• запускается ли игра на целевых устройствах;
• не ломаются ли ключевые сценарии;
• выдерживает ли проект слабые смартфоны;
• удобно ли играть на маленьком экране;
• не мешают ли интерфейс, реклама, покупки и сеть основному геймплею.

Для мобильных проектов особенно важно проверять разные операционные системы, размеры экранов и слабые устройства — именно там чаще всего всплывают проблемы с производительностью и интерфейсом. В нашей практике был случай, когда на среднем Android-смартфоне с нестандартным соотношением сторон кнопка «Играть» наполовину уезжала за пределы экрана, а на флагманах всё выглядело идеально. Без подготовки тестировщики просто не обратили бы на это внимание.

Что нужно решить до первого теста

Перед тем как отдавать игру тестировщикам, нужно зафиксировать базовые правила. Иначе обратная связь будет хаотичной, и вы утонете в попытках понять, что именно пошло не так.

1. Определите цель теста

Разные тесты решают разные задачи. Если не сформулировать цель, команда часто проверяет «всё подряд» и не успевает проверить главное. Вот типичные форматы, которые мы используем в студии:

• smoke-тест — проверить, что билд запускается и базовые экраны работают;
• функциональное тестирование — пройти основные сценарии игры;
• регрессия — убедиться, что старые функции не сломались;
• эксплораторное тестирование — поиск неожиданных проблем;
• проверка производительности — FPS, память, загрузка, нагрев;
• проверка совместимости — разные устройства и версии ОС.

Например, после крупного рефакторинга системы сохранений мы ставили цель — регрессия всех сценариев с прогрессом. Без этого тестировщики могли бы уйти в проверку новых фич, а старые баги вылезли бы уже у игроков.

2. Зафиксируйте, какие устройства и версии ОС поддерживаются

Нужно заранее определить:

• минимальную версию Android/iOS;
• список целевых устройств;
• разрешения экранов и соотношения сторон;
• минимальные требования по памяти и процессору;
• какие устройства считаются приоритетными для проверки.

Это особенно важно для мобильной игры на Unity: UI, производительность и даже поведение сцен могут сильно отличаться на слабых и старых телефонах. Мы как-то раз не зафиксировали минимальную версию Android, и тестировщики начали проверять на устройствах с API 21, где часть наших плагинов просто не работала. День был потерян впустую.

3. Подготовьте понятную сборку

Для теста нужен не просто APK или IPA, а сборка с понятной маркировкой:

• номер версии;
• дата и время сборки;
• ветка или коммит;
• тип сборки: development или release;
• список известных ограничений.

Если тестировщик не понимает, что именно он ставит, потом сложно связать баг с конкретным билдом. У нас был случай, когда три разных билда назывались «test_build.apk», и мы потратили полдня, выясняя, в каком из них сломалась загрузка ресурсов.

Какой билд отдавать на тестирование

Для ранних проверок обычно подходит development build: в нём проще смотреть логи, ловить ошибки и искать причины нестабильности. Ближе к релизу полезно проверять и более «боевую» сборку, чтобы увидеть реальное поведение приложения на устройстве. Важно не забывать, что development-сборка может включать отладочные флаги, которые слегка меняют производительность, поэтому окончательные тесты всегда проводим на release-подобном билде.

Практический ориентир

Важно: тестовая сборка должна быть максимально похожа на реальную, но при этом оставаться удобной для диагностики. Иначе вы увидите «идеальный» билд, а в релизе всплывут другие проблемы. Мы обычно держим две конфигурации: одну с расширенными логами для внутренних тестов, вторую — максимально приближенную к тому, что уйдёт в стор.

Что проверить в Unity-проекте перед отдачей в тест

Unity-проекты имеют свою специфику, и даже мелкая оплошность в настройках может испортить весь тест. Вот что мы обязательно проходим перед тем, как отдать билд.

Сборка и запуск

Проверьте базовые вещи:

• игра устанавливается без ошибок;
• стартует с холодного запуска;
• не зависает на загрузке;
• доходит до главного меню;
• корректно работает выход и повторный запуск;
• не ломается при сворачивании и возврате.

Особенно коварны ситуации, когда билд собирается с неверными настройками сжатия ассетов или с отключёнными сценами. Однажды мы забыли добавить сцену загрузки в Build Settings, и игра падала сразу после старта на всех устройствах, кроме того, на котором собирали.

Сохранения и прогресс

Обязательно протестируйте:

• создание нового профиля;
• загрузку сохранения;
• переход между сценами;
• поведение после перезапуска игры;
• сохранение после прерывания сессии.

Для мобильной игры это критично: пользователь может свернуть приложение в любой момент, получить входящий звонок или закрыть игру во время загрузки. Если сохранение не отрабатывает в таких сценариях, игроки теряют прогресс и уходят. Мы всегда проверяем сохранение на моменте, когда игра свёрнута и выгружена из памяти системой — на слабых устройствах это случается постоянно.

Интерфейс

Проверяйте:

• читаемость текста;
• размеры кнопок;
• попадание элементов в безопасные зоны;
• поворот экрана, если он поддерживается;
• масштабирование на разных диагоналях;
• отсутствие обрезанных элементов.

На телефонах с нестандартным соотношением сторон интерфейс часто «плывёт» быстрее всего. В Unity особенно важно проверять Canvas Scaler и привязки элементов — то, что красиво выглядит на 16:9, может разъехаться на 19.5:9 или на устройствах с вырезом.

Управление и геймплей

Нужно пройти:

• первый запуск и туториал;
• основной игровой цикл;
• паузу и продолжение;
• проигрыш и повтор;
• награды, бонусы и прогрессию;
• критические ветки, которые игрок проходит чаще всего.

Не ограничивайтесь «счастливым путём» — проверьте, что происходит, если игрок нажмёт паузу в середине анимации получения награды или выйдет из игры во время туториала. Такие сценарии ломаются чаще, чем хотелось бы.

Минимальный набор устройств для теста

Если проект пока небольшой, не обязательно сразу собирать огромный парк телефонов. Но базовый набор нужен, и он должен отражать реальную аудиторию, а не только флагманы разработчиков.

Хорошая стартовая матрица

• один слабый Android;
• один средний Android;
• один современный Android;
• один iPhone актуального поколения;
• одно устройство с нестандартным экраном, если интерфейс сложный.

Для мобильных игр разумно начинать с устройств, которые отражают реальную аудиторию, а не только с «флагманов». Важны разные чипсеты, объёмы памяти, размеры экрана и возраст устройств. Мы обычно берём пару бюджетных Samsung или Xiaomi, которые популярны у нашей аудитории, и один старый iPhone — например, iPhone 8.

Что должно попасть в матрицу

• разные версии Android/iOS;
• низкий и средний уровень производительности;
• маленький и большой экран;
• разные соотношения сторон;
• устройства с разной плотностью пикселей;
• устройства, на которых игроки действительно будут запускать игру.

Не стоит проверять только на том, что лежит на столе у программиста. Если ваша целевая аудитория — владельцы бюджетников, а вы тестируете на прошлогоднем флагмане, вы рискуете пропустить критические проблемы с производительностью.

Производительность: что проверять до теста

Мобильная игра может выглядеть нормально на мощном телефоне и разваливаться на бюджетном. Поэтому до передачи на тест важно посмотреть:

• FPS в тяжёлых сценах;
• загрузку процессора и графики;
• потребление памяти;
• скачки памяти и сборку мусора;
• длительность загрузок;
• нагрев устройства;
• просадки после долгой сессии.

Если эти места не проверить заранее, тестировщики будут ловить уже не баги, а симптомы перегруженного проекта. Мы обычно запускаем профайлер Unity на слабом устройстве и смотрим, нет ли аномальных всплесков аллокаций в основном цикле.

На что особенно смотреть в Unity

• слишком тяжёлые текстуры;
• большое количество draw calls;
• дорогие эффекты и частицы;
• тяжёлые тени и освещение;
• частые аллокации в коде;
• неограниченные циклы обновления;
• лишняя работа в Update.

Отдельная головная боль — настройки Quality Settings. На слабом устройстве может неожиданно включиться высокое качество теней или сглаживание, потому что вы не настроили уровни под конкретную платформу. Проверьте, что для каждого уровня качества заданы адекватные параметры, и что игра действительно переключает их в зависимости от железа.

Логи и отладка: почему это экономит дни

Без логов баг часто превращается в догадку. Хорошая тестовая сборка должна позволять быстро понять:

• где произошла ошибка;
• при каких действиях;
• на каком устройстве;
• в какой версии;
• был ли это краш, зависание или ошибка логики.

Мы в студии добавляем в билд специальный отладочный экран, который показывает номер версии, идентификатор сессии и позволяет экспортировать логи в файл. Это спасает, когда тестировщик не может внятно описать проблему.

Что стоит добавить в сборку

• понятный номер билда;
• запись логов;
• stack trace для исключений;
• информацию об устройстве и версии ОС;
• идентификатор игровой сессии;
• флаг окружения: test, staging, release-like.

Наличие идентификатора сессии позволяет связать логи с конкретным запуском игры, даже если тестировщик перезапускал приложение несколько раз. Это сильно ускоряет разбор крашей.

Как подготовить список тест-кейсов

Тест-кейсы не должны быть слишком длинными, но обязаны покрывать главное. Мы обычно составляем их в виде таблицы с приоритетами, чтобы в первую очередь проверялись критические пути.

Базовый набор сценариев

• установка и первый запуск;
• вход в игру;
• туториал;
• базовый игровой цикл;
• победа и поражение;
• сохранение и загрузка;
• пауза;
• настройки;
• реклама или магазин, если они есть;
• повторный запуск после закрытия приложения.

Хороший тест-кейс содержит

• начальное состояние;
• шаги;
• ожидаемый результат;
• фактический результат;
• приоритет;
• устройство;
• номер билда.

Это снижает количество бесполезных отчётов вроде «что-то сломалось на третьем уровне». Когда тестировщик видит чёткую структуру, он быстрее заполняет баг-репорт и не упускает детали.

Типовые ошибки перед тестированием

За годы работы мы наступили на все эти грабли, поэтому перечислю самые частые.

1. Отдают недособранный билд

В сборке нет нужных ассетов, локализации, иконок или экранов. Тестировщик тратит время впустую, а вы получаете отчёты о том, что «ничего не работает». Всегда проверяйте, что все сцены добавлены в Build Settings, а ресурсы правильно упакованы.

2. Не фиксируют версию

Потом невозможно понять, в какой сборке появился баг. Мы всегда вшиваем номер версии и хеш коммита прямо в билд и отображаем на экране загрузки или в углу меню.

3. Проверяют только один телефон

Такой подход почти гарантирует, что часть проблем вылезет уже у игроков. Даже если у вас всего пара устройств, обязательно проверьте на слабом и на среднем.

4. Не отделяют критические и некритические баги

В итоге команда тонет в мелочах и пропускает падения и блокеры. В тест-кейсах всегда проставляйте приоритеты, чтобы тестировщики знали, за что хвататься в первую очередь.

5. Не тестируют сворачивание и прерывания

На мобильных это одна из самых частых причин нестабильности. Игрок может ответить на звонок, переключиться в мессенджер или просто выключить экран — игра должна корректно восстановиться.

6. Проверяют только «счастливый путь»

Игроки редко действуют идеально. Нажимают назад, сворачивают игру, теряют сеть, входят в магазин не вовремя и ставят паузу в неожиданный момент. Обязательно проверяйте негативные сценарии — они ломаются чаще всего.

Пошаговый чек-лист перед передачей на тест

Этот чек-лист мы используем в студии перед каждым тестовым циклом. Он помогает ничего не забыть и не тратить время на хаос.

До сборки

• определить цель теста;
• зафиксировать список целевых устройств;
• выбрать версию ОС и минимальные требования;
• подготовить список критических сценариев.

Перед выпуском билда

• проверить запуск игры;
• проверить главный экран;
• пройти основные игровые сценарии;
• убедиться, что сохранения работают;
• проверить интерфейс на нескольких разрешениях;
• посмотреть логи и ошибки;
• проверить производительность на слабом устройстве.

Перед отправкой тестировщикам

• пронумеровать билд;
• описать, что именно изменилось;
• указать известные проблемы;
• дать инструкцию по установке;
• приложить список приоритетных проверок;
• подготовить форму для отчётов и баг-репортов.

Как организовать баг-репорт

Хороший баг-репорт должен отвечать на пять вопросов:

• что произошло;
• где произошло;
• на каком устройстве;
• как повторить;
• что ожидалось вместо этого.

Мы используем простой шаблон, который заполняется за пару минут. Чем проще форма, тем больше полезных отчётов вы получите.

Удобный шаблон

• устройство и версия ОС;
• версия сборки;
• шаги воспроизведения;
• ожидаемый результат;
• фактический результат;
• частота;
• скриншот или видео;
• логи, если есть.

Что особенно важно перед внешним тестом

Если игру увидят внешние тестировщики или ограниченная аудитория, нужно дополнительно проверить:

• стабильность после установки;
• поведение без интернета;
• корректность рекламы и покупок;
• восстановление сессии после сворачивания;
• отсутствие критических блокеров;
• адекватную работу на слабых устройствах.

Для Google Play и похожих платформ полезно заранее пройти внутреннее и закрытое тестирование, чтобы не выпускать сырой билд в широкую аудиторию. Мы всегда сначала запускаем закрытый трек на 50–100 человек, собираем краш-репорты и только потом идём в открытый тест.

Вывод

Подготовка мобильной игры к тестированию — это не формальность, а отдельный этап разработки. Чем лучше вы определите цель теста, список устройств, структуру билда, базовые сценарии и формат баг-репортов, тем быстрее найдёте реальные проблемы и тем меньше времени потеряете на хаос.

Если коротко, хороший тестовый билд для мобильной игры должен:

• запускаться без сюрпризов;
• иметь понятную версию;
• быть проверен на целевых устройствах;
• показывать логи и ошибки;
• покрывать основные игровые сценарии;
• учитывать слабые телефоны и разные экраны.

FAQ

С какой проверки начать, если времени мало?

Начните со smoke-теста: запуск, главное меню, первый игровой сценарий, выход и повторный запуск. Это минимальный набор, который отсекает совсем уж битые билды. Если smoke не пройден, дальше тестировать бессмысленно.

Сколько устройств нужно для первого теста?

Для старта достаточно 3–5 устройств, если они покрывают слабый, средний и сильный сегмент, а также разные размеры экранов. Главное — чтобы среди них были реальные представители вашей аудитории, а не только то, что есть под рукой у разработчиков.

Нужен ли development build для тестирования?

Да, на ранних этапах он удобнее для диагностики, логов и поиска ошибок. Ближе к релизу нужен ещё и билд, близкий к боевому, потому что в development-сборке могут быть включены флаги, которые слегка меняют поведение и производительность.

Что проверять в первую очередь на слабом телефоне?

FPS, память, нагрев, загрузки, UI и стабильность после долгой сессии. Слабые устройства часто выгружают игру из памяти при сворачивании, поэтому обязательно проверьте восстановление сессии и сохранения в таких условиях.

Почему один и тот же билд ведёт себя по-разному на разных устройствах?

Потому что отличаются версия ОС, чипсет, объём памяти, графика, экран и фоновые ограничения системы. Даже на двух Android-смартфонах с одинаковой версией ОС могут быть разные прошивки и политики энергосбережения, которые влияют на работу игры. Именно поэтому тестирование на одном устройстве никогда не даёт полной картины.