Всем привет! Я Head of QA в компании Scalable Solutions. Так как компания разрабатывает высоконагруженную платформу для управления цифровыми активами и онбордит преимущественно middle+ и senior специалистов с глубокими знаниями трейдинга, финансов и high-load разработки, команды внутри компании строятся по компонентному принципу. Расскажу, как мы выстроили наболевшее кросс-командное взаимодействие между такими командами и ускорили релизный флоу на 20%.
Несмотря на то, что мы являемся классической продуктовой компанией, команды разделены не по продуктовому признаку, а по компонентному. Благодаря чему, с одной стороны, нам удалось сформировать действительно сильные команды с носителями глубинных, специализированных знаний. Но, с другой стороны, роли внутри команд достаточно изолированы, и разные наборы хард-скиллов и экспертизы накладывают свои ограничения. Например, я не могу безболезненно переместить тестировщика из команды backend в команду frontend, или обратно.
Это и привело к тому, что встал вопрос эффективной оркестрации внутри QA команд и управления кросс-командным взаимодействием. Что, в конечном счете, конечно отразилось на релизном флоу.
Релизный флоу
До изменений наш релизный флоу выглядел так:
Под каждую фичу мы делаем три основных документа – BRS, SRS, QAP.
BRS, Business Requirements Specification – это бизнес-требования по фиче. В них описана бизнес-логика самой фичи, для кого мы ее разрабатываем и какую задачу решаем. Также в каждой BRS есть пользовательские сценарии.
Ниже пример BRS по фиче Hidden order [“Скрытый ордер”]. Обычно он используется для того чтобы скрыть заявку с большим объемом покупки или продажи актива, которая при обычной видимости может существенно повлиять на биржевую цену. За написание бизнес требований у нас отвечает Feature Owner (далее – FO).
SRS, Software Requirements Specification – технические требования по фиче. Например, как и какие команды взаимодействуют друг с другом, по какому протоколу, какие данные будут передавать. Если команда, которая работает над фичей, использует графический интерфейс, то в SRS должны быть нарисованы макеты разрабатываемой фичи. За написание SRS отвечает Feature Architect.
QAP, Quality Action Plan – набор кейсов, по которым FO будет принимать фичу у команд. За написание QAP отвечает FO.
После того, как документы описаны и зааппрувлены всеми хедами разработки, мы переходим к реализации фичи.
Когда первая команда заканчивает с разработкой и тестированием своей части фичи, она передается второй команде. Вторая команда проводит интеграцию/разработку/тестирование и передает следующей команде. И так до тех пор, пока все компонентные команды, которые участвуют в разработке фичи, не пройдут по этому флоу. FO валидирует фичу, и она отправляется в релиз.
Проблемы релизного флоу
Итак, кажется все очень даже неплохо – документы, аппрувы, приемочные кейсы. Но по факту в таком процессе мы сталкивались со следующими сложностями:
Проблемы со стороны QA:
Тестирование требований начинается только после разработки. То есть в QA команды приходят уже реализованные разработчиками задачи с требованиями. Но, как мы знаем, в требованиях могут содержаться ошибки.
Поиск ответственной за баг команды отнимает немало времени. Однако не потому что команды шифруются, а потому что не всегда понятно, какие кейсы уже были протестированы другими командами.
Отсутствие переиспользования тестовых артефактов. В рамках тестирования одной фичи QA команды подготавливают похожие наборы тестовых данных. Но по причине изолированности и узкой специализации команд они не могли передавать эти данные друг другу.
Проблемы со стороны FO:
Из-за большого количества фичей написание QAP занимает много времени.
Валидация фичи происходит после разработки всеми командами. В нашем случае это сильно удлиняет релизный флоу из-за большого количества интеграционных вопросов.
Подготовка тестовой среды также сильно специфична из-за сложности продукта и объема интеграций между командами. То есть одновременно свои компоненты тестируют разные команды, и это повышает риски затирания, изменения или удаления данных.
Системный QA в обновленном релизном флоу
Для организации эффективного кросс-командного взаимодействием между QA командами и сокращения релизного флоу мы ввели роль системного QA. Это позволило снять нагрузку в виде написания приемочных кейсов с FO и ускорить написание кейсов, ввести промежуточное тестирование компонента фичи перед тем, как она уйдет в следующую команду, а также переложить на системного QA трудоемкую работу по подготовке тестового окружения с учетом всех нюансов и требований команд к интеграциям и тестовым данным.
То есть системный QA стал связующим звеном между техническими и бизнес-требованиями к каждой фиче и продукту в целом.
Онбординг системного QA
Чтобы системный QA понимал полный релизный цикл, ему необходимо понимать как устроен конкретный релизный цикл в каждой из команд (в каждой он свой). Поэтому в рамках онбординга системный QA проводит в каждой команде 2-3 недели, за которые он релизит минимум одну задачу. В среднем такой онбординг занимает около 3 месяцев.
Результаты перестройки
Теперь мы тестируем требования BRS/SRS от feature owners и feature architects. Чем раньше мы находим баги, тем дешевле это обходится бизнесу.
Появился кросс-командный QA спейс, где к каждой фиче прикрепляется тестовые артефакты – бизнес требования, технические требования, приемочные кейсы, кейсы других команд, тестовые данные. Это существенно помогло всем QA командам быть в едином контексте и эффективно переиспользовать данные.
Ускорили процесс локализации багов благодаря тому, что у системного QA есть наборы тест-кейсов от всех команд.
Так как системный QA занимается написанием приемочных кейсов для каждой команды, это выступает отличной подсказкой для ускорения и улучшения качества тестирования.
Процесс интеграции стал безболезненным, так как фича валидируется по приемочным кейсам после каждой из команд.
Сняв существенную часть нагрузки с FO, ускорилась приемка фичей и подготовка интеграционного стенда с тестовыми данными.
Все это суммарно ускорило релизный флоу на 15-20%, а количество багов уменьшило почти вдвое, так как теперь мы их отлавливаем как на стадии написания требований BRS и SRS, так и в ходе интеграций команд в рамках разработки фичи.
Ещё по теме:
Тестирование финтех бэкенда: как мы дошли до 20 тыс. тест-кейсов
Телеграм-канал Scalable Insights, где мы делимся аналитикой и инсайтами в new fintech