Привет! Я Слава, QA в мобильной разработке СберЗдоровья. В прошлой статье я рассказывал о том, как менялись наши процессы тестирования за прошедший год, какие проблемы в связи с этим встречались, и как мы их решали.

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

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

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

Так как мы являемся mobile first-компанией, то примерно в сентябре-октябре 2021г. мы приняли решение изменить структуру и разделить две наши сервисные команды на продуктовые, в каждой из которых были бы свои разработчики, менеджеры и QA. Но где же взять людей для тестирования отдельных участков приложения, если нас и без того мало (в прошлой статье я говорил о том, что изначально нас было 4, а чуть позже стало 6 manual QA) ? «Украли» из веб-команд. Казалось бы, вот оно счастье — приложение декомпозировано, и на каждую команду свой тестер, а то и два. Но что же мы получили в итоге?

7 фича-команд, в каждой свои PM, QA, dev.
Половина новых QA пришли из web’а и не тестили мобилку ранее.
Люди привыкли работать по процессам своих старых команд, откуда они пришли.
Старая структура тест-модели, подходящая для двух сервисных команд оказалась неподходящей для множества фича-команд.

Отсюда можно выделить 3 новые проблемы, с которыми мы не сталкивались ранее

Наши текущие процессы не подходят для новой структуры.
Тестовая модель неудобна для работы большого числа фича-команд.
У половины QA нет экспертности в мобилке.

Стали решать по порядку.

Сперва приступили к перестройке тест-модели. Реструктуризации, так сказать. Каждой фича-команде завели папки в регресс- и смок-сьютах, а в них уже поместили необходимые кейсы. Ну а чтобы в красивый чистый регресс-набор не попадали драфт-кейсы, завели отдельное пространство с кодовым названием “Кандидаты в регресс”. Некий аналог develop-ветки в git’е. Кейсы лежат там до тех пор, пока не пройдут ревью, и не откроется фича-флаг в новом релизе приложения.

Окей, со сьютами решили, а что с прогонами? Первое время у наших новых коллег были сложности с созданием тест-ранов в ТМСке, чтобы прямо в них динамически отмечать результаты проверок. А если и создавали, то каждый делал в своем стиле. Хотя казалось бы, что сложного сделать по инструкции, которая уже описана? А одному человеку создавать руками прогоны на все 7 команд и следить за ними - тоже занятие гиблое, ведь он может уйти в отпуск или вообще уволиться, и кто тогда будет всем этим заниматься? Поэтому мы попросили автоматизаторов написать скриптик для генерации майлстонов с нужными тест-ранами и проставлением в них статуса «in-progress» для кейсов, которые покрыты автотестами, чтобы мануальщики не тратили на них свое время. Результаты автотестов выгрузятся в эти прогоны по завершении исполнения. Следующим шагом стала интеграция этого скрипта в наш CI. После чего при бранчевании релизной ветки скрипт запускался автоматически. Profit!

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

К чему мы пришли в итоге?

Время регресса сокращено с 4 дней до 1-3 (в зависимости от команды);
Актуальность тест-модели повышена с 80% до 93%;
За каждую часть приложения отвечает отдельный QA, что повышает экспертизу в ней;
Все участники работают по единому флоу;
Все тестовые прогоны запускаются автоматически и не требуют ручного вмешательства;
Драфтовые кейсы не перемешиваются с актуальными.

В этот раз я рассказал вам о том, что такое фича-команды, и с чем мы их едим. Какие проблемы в связи с этим были, и как мы их решили. Ставьте лайки, пишите комментарии, подписывайтесь на канал и бла-бла, ну, вы и сами знаете. Впереди еще много интересного, до связи!

Фича-команды — профит или балласт?