Как мы тестируем наши игры внутри команды

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

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

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

Что именно мы считаем тестированием

Внутри команды мы не валим всё в одну кучу. Тестирование разбито на уровни, чтобы не ждать от одного прогона ответов на все вопросы сразу. Вот как мы это классифицируем:

Как у нас устроен процесс

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

1. Сначала тестирует тот, кто меньше всего вовлечён в фичу

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

2. Один тест — одна цель

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

3. Тестирование идёт по ступеням

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

Типичная последовательность выглядит так:

1. Проверка сборки после изменений.
2. Быстрый прогон ключевых сценариев.
3. Сессия по одной проблемной зоне.
4. Повторный тест после фиксов.
5. Сравнение результатов с предыдущей версией.

Как готовим билд к тесту

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

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

Мини-чек-лист перед запуском

Этот чек-лист висит у нас на доске. Пропуск любого пункта почти гарантирует, что тестовая сессия пойдёт насмарку.

• Билд открывается без вылета.
• Меню запускается.
• Управление работает на клавиатуре и геймпаде, если это важно.
• Сцена загрузки не зависает.
• Сохранение создаётся и читается.
• Критические кнопки не ведут в пустые экраны.
• Логи пишутся и доступны после сессии.

Что мы смотрим в первую очередь

Не все баги одинаково опасны. Мы всегда начинаем с того, что может заблокировать игроку путь дальше. Остальное — потом.

Приоритет 1: блокеры

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

Приоритет 2: ошибки, которые портят понимание

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

Приоритет 3: баланс и темп

Когда базовая логика уже держится, мы начинаем смотреть: не затянут ли первый час, не слишком ли быстро игрок получает всё сильное, есть ли провал между обучением и «настоящей игрой», можно ли пройти уровень слишком легко или, наоборот, только на удаче. Это уже тоньше, но без этого игра не зацепит.

Кто участвует в тестировании

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

Как мы собираем обратную связь

Общие впечатления бесполезны. После теста мы задаём конкретные вопросы, которые вытаскивают реальные проблемы:

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

Такие вопросы помогают быстро понять, это проблема дизайна, UI, баланса или формулировки.

Плохие вопросы

• Ну как?
• Нормально?
• Понравилось?
• Было интересно?

На них обычно получаются вежливые, но бесполезные ответы.

Хорошие вопросы

• Что ты ожидал получить после этой кнопки?
• Где ты подумал, что игра закончилась?
• В какой момент ты перестал понимать цель?
• Что мешало сделать следующий шаг?
• Какую механику ты бы отключил первой?

На такие вопросы мы получаем точки для правок, а не вежливые отмазки.

Как фиксируем результаты

Если результаты теста остаются в разговорах, считай, что тестирования не было. Мы сразу переводим наблюдения в рабочие задачи. Обычно запись выглядит так:

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

Формат удобной записи бага

Такой формат у нас в Confluence, и он реально экономит время: разработчик сразу видит, что случилось, где и как повторить. И тому, кто чинит, и тому, кто потом перепроверяет, не нужно додумывать.

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

1. Тестируют свои любимые сценарии

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

2. Не меняют точку зрения

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

3. Слишком рано спорят о вкусе

Пока механика не работает, споры о цвете кнопок или «красивости» анимации бессмысленны. Сначала чиним логику и функциональность, потом обсуждаем подачу. Иначе правки вкуса замаскируют реальные баги.

4. Путают баг и неудобство

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

Когда внутреннего тестирования уже мало

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

Практический процесс, который можно забрать себе

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

Еженедельный цикл тестирования

1. Собрать свежий билд.
2. Определить одну главную цель сессии.
3. Дать игру человеку, который меньше всего вовлечён в фичу.
4. Не подсказывать первые 10–15 минут.
5. Записать, где игрок тормозит, ошибается и задаёт вопросы.
6. Разделить проблемы по приоритету.
7. Исправить критичное.
8. Перепроверить после фикса.

Что обязательно делать после сессии

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

Короткий чек-лист внутреннего теста

• Билд запускается и доходит до игры.
• Понятна первая цель.
• Все основные кнопки работают.
• Есть выход из ключевых экранов.
• Сохранение не ломается.
• Игрок не может застрять без подсказки.
• Интерфейс не требует знания внутренней логики.
• После фикса старая проблема действительно исчезла.
• Новые баги не появились в соседних системах.

Вывод

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

FAQ

Как часто нужно тестировать игру внутри команды?

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

Кто должен первым играть в новый билд?

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

Сколько проблем нормально находить за один тест?

Столько, сколько можно реально обработать. Лучше 5 критичных и понятных, чем 30 разрозненных без приоритета. Мы обычно ставим лимит: не больше 10–15 пунктов, иначе сессия превращается в деморализующий список, который никто не разберёт.

Нужно ли тестировать даже маленькие изменения?

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

Что важнее: баги или удобство?

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