Мы делили апельсин, много нас, а он один…
Привет! Я Слава, QA в мобильной разработке компании «СберЗдоровье». В прошлых статьях я рассказывал о наших процессах тестирования при активном росте команды и о разделении на фича-команды.
Сегодня я расскажу о том, как именно мы «делили» внутри наше приложение, как тестировали перекрёстные участки и немного подсвечу, что там у нас вообще с автоматизацией, так как в комментариях к прошлым статьям были вопросы по данной теме.
Как я уже писал ранее, мы разделились на продуктовые команды, за каждой из которых закреплен конкретный функционал нашего приложения, а также разработка новых фич, связанных с ним.
Наше приложение позволяет воспользоваться несколькими разными услугами, например,
Самостоятельная запись на очный прием в клиники.
Запись на телемедицинскую консультацию с онлайн-врачом
Удаленный мониторинг здоровья для пациентов с гипертонией, диабетом, коронавирусом и пр.
Вроде бы все просто – сколько услуг, столько команд. Но, помимо этого, у нас еще есть регистрация/авторизация в приложении (куда же без нее), медкарта, в которой отображаются все записи и заключения врачей, как очных, так и онлайн. Витрина товаров с разными наборами услуг, настройки приложения, интеграция со СберПраймом, а также интеграция всех этих услуг друг с другом, и отображение всей важной информации на одном, главном, экране (откуда-то же пользователь должен начинать поиск нужной услуги).
Так как же это все поделить, чтобы было честно и прозрачно?
Медкарту изначально разрабатывала отдельная сервисная команда, поэтому здесь изменений минимум. Теперь это такая же отдельная фича-команда – eMedcard.
Дальше телемедицина . Тут, вроде бы, тоже все просто. Технических разработчиков, кто изначально писал код этой фичи, перевели в новую команду – Telemed, дали им менеджера и привлекли QA из веб-команды телемедицины, которая существовала ранее – эти ребята уже хорошо знают функционал на вебе, поэтому проверить качество этого раздела в мобилке им будет не сложно.
Чтобы воспользоваться какой-либо услугой, пользователь должен ввести соответствующий промокод, либо оплатить ее. Каждый наш продукт состоит из нескольких услуг, например, из консультаций с терапевтом и окулистом. Купив такой продукт, юзер получает возможность проконсультироваться с этими специалистами, однако другие специальности он должен оплатить отдельно или купить другой продукт, в который они входят. Все эти покупки, проверка оплаты, промокодов требуют немало времени и внимания, поэтому для этого была создана отдельная команда – B2C.
Во время консультации врач может предложить пациенту сдать анализы для уточнения диагноза или иных целей. В нашем приложении есть возможность записаться на сдачу анализов в удобной для пользователя лаборатории. За эту фичу, как и некоторые другие, отвечает команда Medproducts.
ЗОЖ-курсы представляют собой отдельный раздел со статьями, заданиями и тестами, поэтому логично, что этим будет заниматься фича-команда – Wellness.
Умный мониторинг представляет собой отдельный крупный раздел приложения. Он достаточно обособлен от других фич и ему так же нужна своя команда – RGS-devices.
Самая первая фича, которая была разработана в нашем приложении – это запись на прием к врачам. С тех пор много чего изменилось и появилось, но этот раздел почти целиком остался прежним за много лет. И кто, как не старожилы, бывшие еще до деления на фича-команды, должны знать этот раздел лучше всех? Так и решили, что эта фича останется под присмотром тех, кто был в команде до прихода новых сотрудников. Кроме того, процесс регистрации/авторизации в приложении, домашний экран, настройки, профиль пользователя и прочие связующие механизмы нельзя оставлять без должного внимания. Все эти участки приложения поддерживаются командой Mobile Platform или, как мы сами себя называем, Core.
Итого, мы получили 7 фича-команд:
eMedcard (медицинская карта пользователя)
Telemed (онлайн-консультации, заключения и т.д.)
B2C (покупка, оплата, интеграция со СберПрайм)
MedProducts (запись на сдачу анализов)
Wellness (ЗОЖ-курсы)
RGS-devices (умный мониторинг)
Mobile Platform (запись на прием к врачам, главный экран и все остальное)
Фуух! Апельсин приложение делить закончили. Всем досталось понемногу. Но тут возникает волк подводный камень – смежные участки приложения. Кто их должен проверять: тот, кто их разработал или тот, на чьем экране они находятся? Например, у нас на главной странице есть такой элемент как «смарт-блок» – интерактивные карточки с важными событиями по типу «скоро начнется консультация с врачом», «направление на анализы», «напоминание о новом ЗОЖ-задании» и др. Некоторые из них ведут в родительский раздел, которым они были порождены. А некоторые – в совершенно другое место, куда юзер должен попасть по cjm.
Пожалуй, самый неоднозначный экземпляр – это карточка с рекомендациями, какие анализы сдать. Она создается после онлайн-консультации, когда врач выписывает направление. Находится на главном экране, а ведет на флоу записи в лабораторию. Те, кто внимательно читал описание наших фича-команд, заметят, что эта карточка является стыком 3 команд: Telemed, Mobile Platform и MedProducts. И кто из них должен ее тестировать?
Так исторически сложилось, что смарт-блок был разработан еще до деления на фича-команды, и после деления целиком достался команде Mobile Platform по наследству (находится он ведь на главном экране и является связкой между командами – все логично). Однако, с развитием фичей разных карточек в смарт-блоке стало много. И для генерации всех их типов нужно было частично пройтись по флоу разных команд. Иногда это требовалось несколько раз. В итоге, на генерацию этих карточек уходило в семь раз больше времени, чем на их проверку. Ну и почему бы не отдать эту проверку той команде, из раздела которой эта карточка генерируется, все равно ведь им этот флоу на регресс проходить, так пусть потратят немного времени на еще один элемент, зато сэкономят в семь раз больше времени своим коллегам. Тогда получается, что карточку с направлением на анализы лучше отдать команде телемедицины? Но и тут не все просто. Так сложилось, что для проверки флоу записи на анализы нужно направление. И это направление является единственной входной точкой. Без него QA из команды MedProducts не сможет проверить свою фичу с записью на анализы и ему все равно придется провести себе онлайн-консультацию, чтобы выписать это направление. Тогда зачем ребятам из телемедицины тратить время, пусть и немного, на проверку, которую будет проводить команда медицинских продуктов?
Получается, что универсального подхода нет. К каждому смежному элементу фичи нужно подходить с умом и анализировать, сколько времени будет затрачено у одной команды, сколько у другой, нужен ли этот элемент в дальнейшем флоу какой-то из команд. Однако, все равно остаются кейсы, которые не покрывают cjm фича-команд, а также кейсы, которые нельзя отнести ни к одной из них. Такие кейсы остаются на поддержке команды mobile platform, они, в свою очередь, успешно с этой поддержкой справляются.
Почти все время я в своих статьях рассказываю про ручное тестирование и умалчиваю про автоматизацию, из-за чего у многих возникает чувство, что у нас ее абсолютно нет. Это не так. Она у нас есть по обеим платформам: Android, iOS, однако, ресурсов на нее в разы меньше, чем на ручное тестирование – по одному человеку на платформу. На данный момент процент покрытия автотестами регрессионного набора составляет примерно 30% от общего числа кейсов. Это далеко от идеальных 100% и, поэтому автоматизация является нашей огромной зоной роста.
Раньше автоматизаторы покрывали тот набор, который был на аппиуме. Отмечу, что это были ключевые кейсы, потому что раньше приложение было небольшим по количеству фичей. Теперь же мы составили для них бэклог, основываясь на бизнес-ценностях и сложности ручных проверок. Чем важнее и сложнее тест-кейс, тем раньше его нужно автоматизировать.
Кроме автоматизации самих проверок у нас также есть автоматизация по созданию тест-рана. Джоба запускается в момент сборки релизной ветки в гитлабе и по ее завершении мы имеем сразу готовый билд и готовый прогон, в котором уже отмечены автоматизированные кейсы.
В дальнейшем мы планируем подключать к автоматизации своих manual QA и растить из них так называемых fullstack QA. Дело это непростое, ведь нужно подготовить обучающую литературу, воркшопы, какое-никакое менторство, выделить на это все это часть рабочего времени и т.д. Такая сложность нас не пугает. Нам есть куда расти и куда развиваться.
За небольшой цикл из трех статей мы обсудили вопросы, решение которых потребовалось при масштабировании команды нашего медицинского супераппа в связи с ростом одновременно выпускаемой в релиз функциональности.
Выводы хоть и простые, но, как и многое в этом мире, сложно имплементируемые в жизни
Найм и расширение штата команды - решение временное
Важно прозрачно определить границы зон ответственности продуктовых команд до трансформации
Нужно заранее договориться, кто отвечает за "серую" зону функциональности и объединяющие элементы сквозных сценариев
Кросс-функциональные команды идут рука об руку с T-shape и Fullstack QA
Автоматизация сокращает время этапов контроля, но до нее нужно пройти организационные изменения: сначала регламент - потом автоматизация.
О том, что у нас получится и не получится как с автоматизацией, так и с другими аспектами трансформации я расскажу в будущих статьях. До связи!