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

Требования читают в начале, а не перед подачей

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

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

Но есть и требования, затрагивающие фундаментальные системы игры:

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

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

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

На этом этапе стоит:

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

Главный принцип: сначала сделать риск видимым, затем принимать решение о сроках, scope и составе ближайших спринтов.

За два месяца: найдите самые дорогие проблемы

Первые недели подготовки не стоит тратить на последовательный прогон checklist сверху вниз.

Сначала полезнее найти требования, исправление которых потенциально может занять больше всего времени.

Проверьте ключевые системные сценарии на реальном console build. Не ограничивайтесь Editor или основной ПК-сборкой. Именно на этом этапе обычно становятся заметны проблемы, связанные с platform layer, input, сохранениями и особенностями жизненного цикла приложения.

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

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

Типовые причины отказа предсказуемы

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

Чаще это повторяющиеся сценарии:

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

Поэтому хороший certification QA — это не просто обычное прохождение игры.

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

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

За месяц: переходите от разработки к стабилизации

Примерно за месяц до планируемой подачи scope проекта должен становиться значительно стабильнее.

Это плохое время для крупных механик и архитектурных экспериментов.

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

Иначе возникает типичная ситуация: QA тестирует один release candidate, разработчики продолжают добавлять изменения, а через несколько дней команда фактически проверяет уже другую версию продукта.

Для сертификации это особенно опасно.

Release candidate должен быть конкретным и воспроизводимым билдом, а не постоянно движущейся целью.

Внутренняя проверка до внешней

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

Перед submission необходимо провести собственный полный certification pass.

Для этого удобно выделить отдельный билд и пройти checklist примерно так же, как его будет проверять внешняя сторона:

Требование.

Статус проверки.

Условия теста.

Результат.

Шаги воспроизведения проблемы.

Ответственный за исправление.

Статус повторной проверки.

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

Если проекту нужна отдельная команда тестирования, имеет смысл подключать QA и тестирование игр ещё до формирования финального release candidate, а не после того, как все изменения уже заморожены.

По возможности сертификационную проверку должен проводить не только разработчик системы, которую он проверяет. Человек, много месяцев работающий с конкретным функционалом, знает его привычное поведение и часто автоматически избегает сценариев, которые реальный пользователь или certification tester попробует без колебаний.

Особое внимание уделите:

• профилям;
• reconnect контроллера;
• suspend/resume;
• сохранениям;
• системным диалогам;
• сетевым ошибкам;
• переходам между аккаунтами;
• поведению после потери соединения;
• выходу из игры;
• восстановлению после ошибок.

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

Закладывайте время на повторную подачу

Самая опасная ошибка планирования — поставить submission вплотную к публичной дате релиза и считать, что первая проверка обязательно завершится одобрением.

Даже хорошо подготовленная команда может получить замечания.

Проблема не в самом отказе. Проблема возникает, когда в roadmap нет времени на исправление, регрессионное тестирование, подготовку нового release candidate и повторную подачу.

Поэтому в графике необходимо заранее оставить хотя бы полноценное окно для дополнительной итерации.

Если оно не понадобится — команда получит дополнительное время на полировку.

Если понадобится — маркетинговый план и дата релиза не начнут разрушаться из-за нескольких технических замечаний.

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

Последние недели: не исправляйте всё подряд

После внутреннего certification pass почти наверняка появится список замечаний.

Здесь особенно важна приоритизация.

Не каждый найденный дефект должен блокировать submission. Команда должна разделять:

Certification blockers — нарушение конкретного требования платформы.

Release blockers — проблема, способная сломать игру или критический пользовательский сценарий.

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

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

Попытка исправить перед submission вообще всё зачастую делает release candidate менее стабильным. Каждая поздняя правка создаёт новый риск регрессии.

Поэтому на финальном этапе важнее контролируемость изменений, чем количество закрытых задач.

После сертификации работа не заканчивается

Успешная сертификация первой версии — это не конец процесса.

После релиза появятся патчи, обновления, DLC, изменения платформенных SDK и новые требования. Если первая подготовка к submission была разовой кампанией с таблицами на локальных компьютерах и ручными действиями, следующий релиз заставит команду пройти тот же путь заново.

Поэтому всё, что удалось формализовать при первой подаче, стоит сохранить:

• certification checklist;
• набор тестовых профилей;
• инструкции для QA;
• сценарии проверки;
• build pipeline;
• историю замечаний;
• правила release branch;
• список платформенных терминов;
• процесс формирования release candidate.

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

Именно поэтому портирование и сопровождение консольного релиза — это не только задача перенести код на другое устройство. Сюда входят platform integrations, QA, оптимизация, подготовка сборок и работа с замечаниями до стабильного релиза.

Чек-лист за два месяца до подачи

Если свести процесс к короткому плану, он выглядит так:

За 8 недель

разобрать требования площадки;

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

За 6 недель

закрыть самые дорогие технические проблемы;

• подготовить console build для регулярного QA;
• начать систематический прогон требований.

За 4 недели

стабилизировать scope;

• ограничить крупные изменения;
• сформировать release branch;
• начать полный внутренний certification pass.

За 2–3 недели

исправить certification blockers;

• выполнить регрессионное тестирование;
• заморозить release candidate;
• перепроверить checklist.

Перед submission

убедиться, что отправляется именно проверенный билд;

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

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

Если вынести требования площадки в backlog заранее, регулярно проверять console build, подключить QA до content lock и оставить время на дополнительную итерацию, процесс становится намного предсказуемее.

NoPanic Studio подключается к разработке игр для консолей и портированию существующих проектов на разных этапах: от технического аудита и подготовки platform layer до QA, оптимизации release candidate, сертификации и поддержки после запуска.

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