Привет, Хабр! На связи Александр Муравьев, Release Manager в Garage Eight. Я отвечаю за то, чтобы мобильные релизы выходили вовремя и без сюрпризов — вместе с QA, Android- и iOS-командами. В этой статье расскажу, как за квартал мы перестроили процесс предрелизного тестирования и что из этого получилось.

Каким был обычный день релиза раньше 

Мы используем двухнедельный цикл разработки, в среду на второй неделе планируем Code Freeze, а в четверг начинаем предрелизное тестирование. Раньше это был практически главный этап, когда мы искали и находили проблемы. В тестах почти всегда участвовали человек 10–12 — кто-то из QA, кто-то из разработки, кто-то из смежных команд — просто потому, что «нужно еще раз проверить эту фичу». Все вместе мы находили 8–10 дефектов, часть из которых были критичными и мажорными. 

Дальше мы запускали стандартную цепочку: дефект → исправление → полный ретест. Работа затягивалась до понедельника или вторника. В результате сдвигалось начало следующего спринта, ведь несколько человек из команды были заняты багами и ретестами из предыдущего релиза. 

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

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

Почему процесс, который формально работал, перестал справляться

Во второй половине 2025 года у нас уже были базовые элементы release management: документация, понятные статусы для начала и завершения тестов, критерии Quality Gate, Code Freeze по расписанию, календарь релизов. С точки зрения процесса всё выглядело как надо.

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

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

Что мы поняли, когда разобрались в причинах

Мы выделили две главные проблемы: 

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

• У нас не было обязательного подтверждения, что команда провела достаточно тестов до того, как отправить изменения в релизную ветку. Из-за этого часть дефектов впервые всплывала только во время общей предрелизной проверки. 

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

Что мы изменили

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

Перенесли Google Play Review на более ранний этап

Раньше часть критичных проблем всплывала во время Google Play Review, уже после предрелизных тестов: например, приложение зависало дольше чем на пять секунд, команда исправляла это и запускала дополнительный цикл проверки. В итоге мы тестировали один и тот же релиз дважды.

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

Ввели обязательное подтверждение тестирования до Code Freeze

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

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

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

Подключили QA Community к ревью тестов

Мы стали регулярно пересматривать предрелизные тестовые сценарии силами QA Community. Идея простая: человек из другой команды проходит сценарий, не зная деталей и особенностей конкретной фичи. Если он получает ожидаемый результат, значит, тест написан понятно и действительно проверяет то, что нужно. Такая «перекрестная» проверка помогает, когда сценарий плохо проработан или не учитывает все возможные варианты.

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

На этом этапе ярко проявился принцип клиентоцентричности. Нашими «клиентами» в релизном процессе были разработчики и QA, поэтому важно было, чтобы изменения помогали им: например, высвобождали время или облегчали работу. 

Усилили Quality Gates и контроль rollout

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

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

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

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

Как изменились дни релизов

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

Мы стали тестировать и раскатывать релизы именно тогда, когда запланировали, не затрагивая следующие спринты.

Изменилось и техническое качество: crash-free rate за квартал вырос с 99,23 до 99,66%. Причем для этого не потребовались стабилизационные релизы и хотфиксы.

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

Что мы пока не решили

Было бы нечестно представить это как историю с законченным хеппи-эндом. Рост crash-free rate до 99,66% — хороший результат, но не потолок. В третьем квартале этого года мы начали внедрять автотесты и автоматизировать часть релизных действий в CI/CD. Об этом расскажу в будущих статьях.

А вот что у нас пока в планах:

• системно работать с повторяющимися багами, потому что пока мы только реагируем на них по факту;

• закрыть оставшийся технический долг;

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

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

Весь кейс показал, что принципы компании отлично работают на практике: 

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

• фокус — выбрать главное;

• целеориентированность — оценить результат;

• клиентоцентричность — учитывать время команд;

• непрерывное улучшение — двигаться дальше после первого результата. 

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

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