Как ускорить релизный флоу с помощью одного системного QA

Всем привет! Я 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