Привет, Хабр! Меня зовут Александр, я — руководитель группы тестирования в мобильном приложении для продавцов «Ozon Seller». Общаясь с тестировщиками из разных компаний, часто слышу про одну и ту же боль — долгий регресс руками, который из раза в раз отнимает уйму времени, сил и мотивации.
Хочу поделиться с вами историей о том, как мы работали над улучшением релизного процесса и что из этого вышло. Думаю, что статья будет полезна для QA-специалистов, команд тестирования и в целом для команд, занимающихся мобильной разработкой.
С чего мы начинали
Три года назад у нас была похожая ситуация: регресс и смоук нашего приложения занимали 3-4 дня, автотесты только зарождались, а вся команда QA была в районе 10 человек, 6 из которых были задействованы в релизном процессе. Релизы выпускались каждые 2 недели, ну и ещё иногда хотфиксы, куда же без них.
Итого на тот момент наши трудозатраты составляли по 9-12MD (человеко-дней) на каждую платформу (iOS/Android) или в среднем 21MD суммарно на всю команду. Запомним это число как точку отсчёта.
И тогда мы решили подумать, а что можно с этим сделать и как оптимизировать процесс?
Разумеется, решили поискать универсальную таблетку на просторах интернета. Но в основном в технических статьях и на ресурсах, которые нам попадались, всё сводилось к одной идее — надо больше автотестов, тогда нагрузка на ручное тестирование уменьшится. И с этим, конечно, не поспоришь, но, чтобы выжать максимум, требовалось что-то ещё.
Но прежде чем переходить к основной части моей истории, хочу дать небольшое пояснение по терминологии, которую мы используем:
под регрессом в нашей команде подразумевается проверка приложения по основным критическим пользовательским сценариям плюс проверка импакта от задач, попавших в последний релиз; регресс проводим на тестовом окружении (примерно 60-90 кейсов);
под смоуком подразумевается проверка приложения на prod-окружении, направленная в основном на проверку обновления, авторизации, получения push-уведомлений, отправку метрик производительности (aka RUM-метрики), суммарно в районе 20-30 кейсов.
Мы понимали, что с одного захода идеальный процесс не придумать, поэтому решили двигаться поэтапно и начать с тех улучшений, которые можно внедрить максимально быстро и безболезненно. А дальше собирать статистику, обратную связь от команд и думать, куда двигаться дальше.
А теперь давайте по порядку расскажу про наш путь.
Этап номер один
Задались целью стабильно укладываться в 2 дня. При этом мы не хотели увеличивать количество QA, привлекаемых к релизному процессу, и важно было не потерять в качестве выпускаемых релизов.
Плюс дополнительно выиграть ещё 1 день в спринте для тестирования бизнес-задач.
Для начала выработали основные векторы для улучшений:
автотесты,
оптимизация тест-кейсов,
автоматизация ряда процессов.
Так у нас появились следующие изменения и улучшения:
встроенная в релизный пайплайн джоба с автотестами (как раз к этому моменту все команды успели написать автотесты на наиболее критичные проверки);
переработанные и улучшенные тест-кейсы в Allure (атомарные, простые, понятные, без лишней информации, бесполезных проверок и больших описаний);
первые сообщения о прогонах автотестов от бота с тегами релизных команд и ещё ряд небольших изменений рутинных процессов (например, убрали или передвинули встречи, на которые раньше приходилось ходить релизным командам параллельно с прохождением регресса).
В итоге релизную ветку стали отрезать в среду, а регресс и смоук проводить в четверг-пятницу. Попробовали несколько спринтов, убедились, что качество релизов не пострадало (собирали информацию по критичным багам и хотфиксам) и стали думать, а что же дальше? Как ещё можно улучшить процесс?
Этап номер два
Поставили новую цель — сократить релизные активности с двух дней до полутора.
Снова собрались с лидами команд тестирования, побрейнштормили, накидали идеи по улучшению, сгруппировали их в несколько векторов, а далее декомпозировали на отдельные задачи.
Направления для оптимизации остались, по сути, прежними.
1. Автотесты
На тот момент проект с автотестами продвинулся сильно вперёд: были автоматизированы все критичные проверки, автотесты стали стабильнее и прогонялись каждую ночь и на каждом мерж-реквесте, что позволяло нам своевременно отлавливать возникающие баги. С этого момента мы стали значительно больше полагаться на автотесты при тестировании бизнес-задач, техдолга, багов, а также при составлении тест-планов на регресс. Как результат — почти все автоматизированные тест-кейсы были убраны из ручных прогонов регресса.
2. Тест-кейсы
Посчитали, какое количество ручных проверок мы можем успевать проходить за отведённое время (1 рабочий день). Так появилось ограничение на количество постоянных кейсов на регресс от каждой команды (не более 20 кейсов). Команд у нас 4, соответственно, суммарно должно было получаться не более 80 постоянных кейсов плюс к ним добавлялись кейсы по импакту от задач, попавших в последний релиз.
Плюс снова провели ревью тест-кейсов, чтобы они стали ещё проще и понятнее, проходились без дополнительных уточнений и вопросов.
Сократили набор кейсов для смоука с 30 примерно до 20-25.
3. Процессы
В релизных командах осталось по 3 QA, но теперь на каждый релиз дополнительно стал назначаться отдельный человек, который занимался координацией релизных команд и процессов, — QA Release owner. Он же разбирал прогоны автотестов на релизной ветке, готовил стратегию тестирования и тест-планы в TMS (мы используем Allure), отписывался в общем канале по статусам и принимал решения, что делать при возникновении нештатных ситуаций.
Релизную ветку стали отрезать в среду ближе к концу рабочего дня, регресс проходил за четверг и утро пятницы, а смоук завершали примерно к 16-17 часам. Далее отправляли сборки в сторы на ревью, а в понедельник начинали поэтапную раскатку на пользователей.
Не могу сказать, что эта схема работала идеально: не всегда мы укладывались в полтора дня, да и, если посчитать суммарные трудозатраты, то легко понять, что выигрыш был незначительный.
Что немаловажно, все эти изменения и оптимизации не привели к ухудшению качества релизов: количество обращений от пользователей или хотфиксов осталось на прежнем уровне.
И угадайте, что было дальше? Правильно, мы снова собрались с лидами побрейнштормить =)
Этап номер три
Новая цель — релиз за 1 день и по 2 QA в каждой команде вместо 3-х.
По мере роста уровня компетентности сотрудника, скорость его работы выходит на плато и довольно сложно повышать её снова и снова, но можно попробовать оптимизировать и автоматизировать часть его работы, что непременно даст результат. На тот момент у нас уже был зрелый проект с автотестами, порядка 500 тестов на каждую платформу (тогда у нас были нативные АТ на Swift и Kotlin). Плюс мы стали активно использовать бота в корпоративном мессенджере, который, по сути, взял на себя часть работы QA Release owner’а и стал собирать промежуточные статусы по прогрессу, присылать отчёты по прогону автотестов и т. д.
Мы снова взялись за тест-кейсы регресса: провели ревью, немного их сократили, убрали те, что успели покрыть тестами. Плюс ещё немного оптимизировали проверки смоука: улучшили описание, конкретизировали некоторые проверки, убрали дублирующиеся проверки.
Как видите, мы не изобретали ничего нового, а просто улучшали то, что, в принципе, уже неплохо работало.
На выходе мы получили регресс порядка 35-50 и смоук — около 20 тест-кейсов. Ветку стали отрезать в конце рабочего дня в четверг, а релизный процесс полностью переехал на пятницу. Чаще всего мы стали укладываться в один день, и это был успех... Ну или почти успех.
Наверное, не бывает ничего идеального, вот и тут спустя время проявились некоторые недостатки.
Моральное давление на команды: времени впритык, стремимся уложиться в 1 день, и как результат — иногда смоук заканчивали довольно поздно, а это всё-таки вечер пятницы, и, конечно, не всем такой расклад понравится.
Мы не оставили себе практически никакого буфера на непредвиденное, а оно, естественно, периодически появлялось: то проблемы на CI, и нет нужных сборок, то какая-нибудь ручка пятисотит, то просто банально критичный баг, и его надо фиксить до выкатки релиза.
Сокращение релизных команд привело к тому, что мы стали проходить регресс и смоук не на всех поддерживаемых нами версиях ОС. И в какой-то момент это выстрелило: поймали критичный баг на 14-ом Андроиде, который к тому времени стал уже самым популярным у наших пользователей.
На тот момент наши суммарные трудозатраты стали составлять 5 с небольшим MD (1 день пятницы на пятерых QA и пару часов четверга, когда релиз-оунер готовил тест-планы). Напомню, что начинали мы с 21MD, и в плане трудозатрат проджект-менеджеры были в экстазе это был действительно хороший результат.
Но были нюансы, про которые я писал выше, а тут ещё и новая вводная подъехала: «А давайте релизить каждую неделю» =)
Этап номер четыре
И мы снова сели думать, как с этим жить.
Так как в прошлой итерации улучшений мы уже и так выжали практически максимум, то решили попробовать немного изменить подход:
увеличили количество людей в каждой команде до 5, что позволило максимально распараллелить прохождение кейсов, а значит теперь мы раньше можем находить баги и быстрее их фиксить, а также это позволило покрыть все основные версии ОС, которые мы поддерживаем;
стали отрезать релизную ветку в пятницу вечером, а значит у команд разработки появилось 5 полноценных дней в каждом релизном трейне;
сохранили фокус на автоматизации тестовых сценариев и минимизации ручных кейсов в каждый регресс;
изменили подход к оценке критичности багов: если баг не блокирующий и с ним можно пожить одну неделю, то необязательно фиксить его во время регресса.
Что мы имеем на текущий момент?
еженедельные релизы;
регресс и смоук проходят в понедельник с 10.00 до 15.00;
по 5 QA в каждой команде + QA Release owner;
двухдневная раскатка релизов на пользователей;
crash free rate 99.9%;
оценка приложения в App Store — 4.8, Google Play — 4.7;
совокупные трудозатраты команды QA на релиз — меньше 7MD;
количество хотфиксов уменьшилось, т. к. теперь плановые релизы чаще, и мы просто катим важные фиксы в плановый релиз, а не хотфиксим.
А что же дальше?
С таким подходом мы уже прожили 2 месяца, и пока полёт нормальный. Но уже сейчас мы продолжаем думать, что ещё можно улучшить и ускорить.
Вот некоторые идеи и планы:
в ближайшей перспективе у нас появится интеграция Jira+Allure, которая позволит автоматом собрать в один тикет и один тест-план все тест-планы из эпиков, попавших в текущий релиз;
продолжаем развивать автотесты и стремимся к тому, чтобы новая фича покрывалась тестами до релиза, а не после, как это происходит сейчас;
завершить автоматизацию рутины и убрать связующее звено релизных команд в виде QA Release owner’а, а значит, ещё больше снизить трудозатраты;
есть мысли полностью уйти от ручного регресса и оставить только небольшой смоук на prod- окружении, который будет занимать не более 2 часов.
И немного выводов
Если вы или ваша команда сейчас находитесь где-то в начале этого пути, то вот несколько общих рекомендаций:
не бойтесь перемен и экспериментов,
не пытайтесь сделать идеально с первого раза — скорее всего, всё равно не получится,
начните с быстрых и простых решений,
автоматизируйте тест-кейсы:
- начните с наиболее критичных проверок,
- не гонитесь за количеством, работайте над качеством,
- плохие и нестабильные тесты приносят больше вреда, чем пользы;автоматизируйте рутинные процессы:
- внедряйте автоматизацию на CI,
- используйте ботов и нотификации команд;оптимизируйте количество девайсов для регресса:
- опирайтесь на статистику по пользователям,
- подберите минимально необходимый, но не слишком избыточный набор девайсов,
- своевременно отказывайтесь от поддержки старых версий ОС, на которых осталось совсем мало пользователей,
- обязательно проводите регресс и смоук на самых популярных версиях ОС;опишите чёткие критерии критичного бага:
- помните о них, когда на регрессе найдётся баг и нужно будет принять решение фиксить его сразу или подождать до следующего релиза,
-то же самое касается принятия решения о хотфиксе;отбрасывайте то, что не работает, остальное — улучшайте,
собирайте обратную связь от команды.
Конечно, не всем подойдёт всё то, что сработало у нас, но, надеюсь, кому-то это поможет начать двигаться в сторону улучшений и наметить основные направления для оптимизации процессов.
Успехов на этом нелёгком пути, поменьше багов и побольше довольных вашим продуктом пользователей!