Всем привет! Меня зовут Иван, я QA-инженер релизной команды в inDriver. В этой статье расскажу о том, как мы сократили время регрессионного тестирования релизной сборки мобильного приложения и релизный цикл до одной недели, с какими проблемами столкнулись и как их решали.

Ранее мы рассказали, как и почему перешли от хаотичных релизов к еженедельному выпуску нашего приложения на iOS и Android. Ниже поделюсь, как при этом мы уменьшили время проверки релиза с 3-4 дней для одной из платформ до 4 часов на проверку сразу двух платформ.

Предыстория

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

На тот момент релизные циклы составляли 2 недели. В команде было 3 QA-инженера, которые еженедельно в течение 2-3 дней фуллтайм проверяли релизную сборку одной из чередующихся платформ. Помимо проверки релиза, мы активно занимались налаживанием релизного процесса, написанием документации, онбордингом новичков и актуализацией тест-кейсов в TMS.

У такого подхода был ряд минусов:

• Дефект мог быть обнаружен только на 2-3 день проверки, что оттягивало срок его фикса и увеличивало общий Time-to-Market (ТТМ).

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

• Длительная проверка релиза утомительна — «замыливаются» глаза, увеличивается вероятность пропустить какие-то дефекты.

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

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

Изменение процесса проверки релиза

В конце 2021 года, учитывая выявленные минусы, мы решили масштабировать релизную проверку на QA-инженеров из всех команд. А с начала 2022 года перешли к еженедельной проверке сразу двух мобильных платформ и отказались от TMS TestRail в пользу Qase, так как первый очень медленно работал, все время падал и регулярно доставлял всем боль:

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

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

• Все баг-репорты заводятся в первые 4 часа понедельника, соответственно, фиксы попадают в релизную сборку значительно раньше.

• Невозможность участия в проверке релиза пары QA-инженеров практически не сказывается на скорости проверки релиза.

• Время проверки релиза не занимает больше 4 часов — в течение такого промежутка значительно легче сохранять концентрацию и внимательность.

• На порядок увеличивается охват по девайсам.

• Какие-то очень специфичные новые фичи первое время проверяются их «владельцами» и постепенно раскатываются на всю команду.

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

• Appium.

• Kotlin, JUnit 5.

• Selenoid.

• Allure.

Что получилось

На данный момент UI-тестами покрыто около 30% от общего числа тест-кейсов из приемочного набора. Они запускаются сразу после среза на релизной ветке, а их результат в виде Allure-отчета отправляется ботом в Slack. По мере автоматизации тест-кейсы выводятся из пула релизного рана. Во время проверки релиза дежурный QA-инженер из нашей команды проходит упавшие тесты руками, и при необходимости заводит баг-репорт:

Чтобы держать тесты зелеными и заранее обнаруживать баги, они каждую ночь запускаются на dev-сборке. После этого дежурный QA на специальном дашборде заводит новые задачи на актуализацию тестов или баг-репорты. Также набор тестов может быть запущен любым желающим с помощью GitHub Actions:

В результате вышеуказанных изменений мы уменьшили время проверки релизной сборки с ~72 часов до 4 часов, не жертвуя качеством продукта.

Одна из проблем, с которой мы столкнулись — часовые пояса. Сотрудники сильно разбросаны по городам и странам (статья о том, как эту проблему решали в одной из команд inDriver), что усложняло одновременную проверку релиза. Но, так как в основном наши инженеры находятся в трех часовых поясах, мы просто решили максимально приблизить время проверки с учетом рабочего времени каждого. Например, в Алматы проверка релиза начинается с самого утра.

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

• Формировать списки тех, кто будет участвовать в релизе с учетом отпусков и отгулов.

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

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

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

• Отвечать на возникающие вопросы участников процесса и разрешать различные нестандартные ситуации.

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

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

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

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

Спасибо за то, что дочитали до конца. Если остались вопросы — прошу в комментарии.