Home

Задача любого тестировщика — проверять продукт на соответствие установленным требованиям и своевременно отлавливать любые баги и ошибки. В идеальных условиях или небольших проектах эта схема работает безотказно. Но в ситуациях, когда над продуктом работает несколько команд разработки, в релизы попадает по 30–70 задач, а обновления выкатываются каждую неделю, фокуса тестировщиков может просто не хватить. В таких условиях не обойтись без Quality Gates.

Меня зовут Юлия Садовникова. Я старший специалист по тестированию в команде Core Android компании ОК. В этой статье я расскажу о Quality Gates в ОК и о том, как QA может не просто тестировать, а реально влиять на проект и процессы.

Как устроено тестирование в ОК

ОК — крупная российская соцсеть, которой ежедневно пользуется 38 млн пользователей по всему миру. Android‑приложение ОК доступно уже более 10 лет и за это время скачано более 100 млн раз.

В ОК выделено три направления тестирования:

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

• Команда автоматизации. В зоне их ответственности — разработка и улучшение фреймворков для автоматизации, обучение, реализация тулов и настройка окружения для тестирования.

• Core команды. Отвечают за качество всего продукта на своей платформе (iOS, Android или mobile web), подготовку и выпуск релизов, контроль процессов, написание автотестов на своих платформах, а также проведение ревью. В каждой Core команде у нас по 2 тестировщика, которые дежурят по очереди — неделя через неделю. Это позволяет переключаться на другие активности, пока напарник(‑ца) выпускает релиз (работа с поддержкой, тестирование задач, автоматизация).

В ОК есть Quality Gates как для продуктовых команд, так и для самого продукта.

Примечание: Quality Gates — заранее определенные этапы, во время которых проект проверяется на соответствие необходимым критериям для перехода к следующему этапу. Цель Quality Gates — обеспечить следование набору определенных правил и практик, чтобы предотвратить риски и повысить качество проекта.

Quality Gates для процессов в команде

Для продуктовых команд Quality Gates реализованы с применением нескольких практик.

• Кик‑оф встречи для продуктовых проработок. Позволяют учитывать имеющуюся экспертизу и закладывать фундамент для тестовой документации.

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

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

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

Quality Gates для продукта

В контексте продукта контроль качества и соответствия требованиям обеспечивают:

• Автоматизация на всех платформах (API, Web, MobWeb, IOS, Android).

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

• Мониторинг ошибок 24/7. Дает возможность следить за всеми ошибками на графиках, оперативно обнаруживать инциденты и реагировать на них.

Релизные циклы или история о стабильности

Релизный цикл ОК стабилен более 7 лет — на каждый релиз приходится от 30 до 70 задач, а обновления выходят раз в неделю (не считая фиксовых релизов).

С 2019 года, когда я пришла в команду Core Android, процесс строился следующим образом:

• было три основные ветки, в которые могли заливаться разработчики: develop, stable (ветка для регресса и фиксов после него) и release;

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

• код фриз происходил автоматически утром (8:00) в среду;

• на полный регресс приложения и все тесты выделялось 3 дня;

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

• использовалась схема раскатки приложения в Play Market 0.01–5–20–100%.

Схематично релизный цикл выглядел примерно следующим образом:

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

Столкновение с реальностью и выстраивание новых гейтов

В моей Core Android команде, как и других, работало два тестировщика. Но в 2020 году мой напарник решил уйти из компании, и все процессы остались на мне. К тому моменту у нас уже были:

• Unit‑тесты;

• UI‑тесты (около 640 шт);

• Lint‑рулы для переводов и основных сборок;

• Upgrade‑тесты (тесты обновления).

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

Первая гипотеза

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

• Реже релизы — значит, в них будет попадать больше задач.

• Больше задач — потенциально больше крешей.

• Больше регресс — больше время выпуска фиксивого релиза.

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

• Раскатка приложения на пользователей займет более недели.

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

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

Соответственно, от идеи с увеличением релизного цикла мы отказались.

Вторая гипотеза

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

Так, ранее под регресс попадали:

• минимальная версия (5.0 — в 2020 году, 7.0 — в 2025 году);

• максимальная версия (10.0 — в 2020 году, 15.0 — в 2025 году);

• самая популярная версия;

• промежуточные версии (7.0–8.0 — в 2020 году);

• планшетная версия.

При этом регресс у нас занимал несколько дней — с 8:00 среды до вечера пятницы, и время его окончания не было строго определено. Из‑за этого могли возникать проблемы — например, фиксы могли влить в ветку stable в пятницу, вплоть до окончания рабочего дня, несмотря на то, что релиз уже проверен и почти готов к выпуску. Выпуск самого приложения занимал примерно 1,5 часа.

Чтобы снизить нагрузку на тестировщиков и уйти от существующих недостатков, было решено оставить регресс только для:

• минимальной версии;

• самой популярной версии;

• планшетной версии (раз в 2 недели).

Смоуки и различия начали проверять на максимальной и промежуточной версиях.

Более того, вместо относительно свободного формата проведения регресса были установлены более четкие правила:

• Ввели строгое время окончания регресса — 14:00 пятницы. Все задачи в stable ветке должны быть протестированы и влиты до этого времени.

• После 14:00 производится отвод веток и дальнейшие работы.

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

Новые правила для разработчиков

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

Для этого изначально был проведен глубокий анализ текущего состояния.

Push напрямую в ветки

Оказалось, что у нас был разрешен push напрямую в ветки develop/stable/release (без создания merge‑реквеста). Это проблема не была подсвечена ранее и потенциально могла превратиться в катастрофу (спойлер: и даже иногда превращалась). Поэтому было принято решение оставить возможность пушить напрямую в ветку только определенному списку дежурных разработчиков и core QA — для остальных при push напрямую будет ошибка.

Дежурные разработчики не предупреждены о возможных фиксах

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

Чтобы свести к нулю подобные риски, была придумана система апрувов от дежурных, в рамках которой дежурный разработчик автоматически добавляется во все merge‑реквесты, направленные в ветки stable и release, а апрув дежурного становится обязательным для мерджа.

В Bitbucket это теперь выглядит следующим образом: при создании merge‑request автоматически добавляется reviewer — разработчик, который дежурит на этой неделе.

Затрагивание чужих разделов

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

Чтобы исключить такую возможность и сопутствующие ей риски, мы добавили в проект файл с ответственными разработчиками за каждый модуль (их должно быть два) и сделали обязательным хотя бы один аппрув от мейнтейнеров, если задет чей‑то раздел.

На практике это работает следующим образом:

• Билд система при создании автоматически добавляет ответственных в merge‑реквест.

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

Соответственно, без согласований merge‑реквест не может быть залит.

Новые правила для всех

От проблем и оптимизации в части задач разработчиков я перешла к общей оптимизации релизных процессов.

Работа с тестами

В 2020 году у нас уже было реализовано сообщение в Jira и Bitbucket с полезной информацией о билдах. В нем были отчеты о прогонах автотестов, прикрепленные билды, ссылки на merge‑реквест и другие данные.

У нас была вся информация, но в условиях отсутствия строгих регламентов пользы от нее было мало:

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

• UI‑тесты гонялись, но их могли не смотреть;

• UI‑тесты гонялись, но экспертизы на их анализ не хватало (например, если падали тесты в чужих разделах);

• UI‑тесты гонялись, но разработчики их игнорировали (как и этап тестирования).

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

Работа с ветками и версиями

Помимо прочего, я сталкивалась с необходимостью постоянно пинговать разработчиков для отвода веток — например, из Develop в Stable, из Stable в Release. Кроме лишних коммуникаций, это было сопряжено еще и с вынужденным ожиданием — на сборку и переключение разработчика между ветками могло уходить до 1,5–2 часов.

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

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

Для оптимизации в этом случае была написана отдельная джоба, в которой прописывались version code и version name.

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

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

Выкладка в сторы

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

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

Введение SLA на креши и баги

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

Поэтому было принято решение ввести SLA на креши разного типа. Теперь:

• Блокирующие креши (которые блокируют раскатку релиза) должны быть устранены за 1 день.

• Критические креши, которые не блокируют раскатку релиза, должны быть устранены в следующем релизе, то есть в течение 7 дней.

• Мажорные креши должны быть устранены в течение 30 дней.

• Минорные креши, которые задевают небольшой процент пользователей, должны быть устранены в течение 90 дней.

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

Отказ от стабильной ветки

В начале 2025 года мы отказались от стабильной ветки — это стало возможным благодаря масштабированию автоматизации на проекте. Так, если в 2019 году у нас было всего 640+ тестов, то к 2025 их число выросло до 1647. То есть мы полностью автоматизировали ручной регресс core команды. Это позволило нам практически безболезненно отказаться от ручного регресса.

Но чтобы такой отказ не спровоцировал деградацию процессов и всего продукта, мы:

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

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

• ввели SLA на фиксы смоук автотестов тестировщиками.

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

• оставили две основные ветки, в которые могут заливаться наши разработчики: develop и release;

• автоматический код фриз сдвинули на 12:00 каждой пятницы;

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

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

• Используется схема раскатки 0,01–5–20–100%.

Соответственно, изменилась и схема релизных процессов. Так, раньше у нас ветки и релизы могли накладываться друг на друга, а на регресс уходило много времени.

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

Примечание: Во время подготовки этой статьи наши процессы снова немного трансформировались — мы непрерывно работаем над их улучшением. Теперь наши раскатки приложения в Play market стали проходить по новым процентам: 0.01–5–20–99.99–100%. Это обусловлено тем, что мы хотим иметь возможность манипулировать раскаткой выпущенной версии, и, если необходимо, откатываться к прошлой. Но если ваша версия уже находится на 100% — ничего с ней сделать нельзя.

Итоги и планы на будущее

Проделанная работа подтверждает, что Quality Gates в релизных процессах — действительно полезный инструмент для нахождения проблем на более ранних этапах разработки и тестирования. Убедилась я и в том, что QA может не только тестировать свой продукт, но и эффективно оптимизировать процессы, в которых работает — я прошла через это лично. Например, благодаря работе над процессами, уменьшился Time to market и освободилось больше времени на написание автотестов.

Профит от проделанной работы особенно заметен в числах.

Но мы не останавливаемся на достигнутом и продолжаем комплексную оптимизацию. Так, в перспективе планируется реализовать и добавить:

• автоперевод тасок в статусе Commited в Resolved с выпуском релиз‑кандидата;

• автоперевод нерешенных задач в следующую версию с выпуском релиз‑кандидата;

• нотификации в личку, если в твоем PR завалился билд (часто видим это только на этапе тестирования);

• супермердж для core команды любого PR с обходом мейнтейнеров с нотификацией в чат;

• выкладку релиза с помощью бота.

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

А пока делитесь в комментариях используемыми практиками проверки проекта на соответствие требованиям и отсутствие багов.

Обсудить в форуме