У нас T-shape, а у вас?

Привет! Я Женя, ведущий автоматизатор, QA-Lead и лидер профессии по направлению QA. Эта статья о том, как мы развили инженерную культуру, повысили масштабируемость команды и ускорили поставку.

Расскажу о нашем опыте использования практики T-shape, она же практика DevOps.В статье акцентирую внимание на плотной коллаборации QA и DEV инженеров в рамках работы над быстрой и качественной доставкой бизнес-ценности клиенту.

В эксперименте участвовало пять команд —  более 30 человек, которые работают над сервисом с входящей нагрузкой более 3 млн запросов в день.

С чего мы начинали

В нашем направлении большой поток задач от бизнеса, плюс высокий темп развития архитектурных решений. Мы постоянно и активно работаем над ускорением поставки продукта, гибкостью и масштабированием команды под актуальные цели. Для улучшения поставки мы решили попробовать практику T-shape.

Если обратиться к гуглу, то T-shaped специалист –  человек, который стал экспертом, как минимум, в одной области, но при этом разбирается во многих других и может свободно поддерживать общение с другими специалистами на базовом уровне. Мы решили не ограничиваться одним T-Shape специалистом, а внедрить практику на уровне всей команды.

У нас 6 QA, 19 разработчиков, лиды и аналитики. Работаем мы в основном с бэкенд приложениями для скоринга физлиц, под капотом — более 20 микросервисов с бизнес-логикой и различные вспомогательные тулы. Все наши приложения и тесты написаны на kotlin. Есть пара админок с фронтом, но в статье речь пойдет в основном об обеспечении качества на бэкенде.

Командная практика и ее целеполагание

Обеспечение качества — ответственность всей команды, но начать мы решили с изменения технического процесса в связке QA + Dev. Для себя определили T-Shape так: это командная практика, направленная на расширение смежных областей, в которых смогут полноценно взаимодействовать инженеры разных профессий — в нашем случае разработчики и QA.

Какие проблемы мы хотели решить:

• сложности с масштабированием команды. Долго и не всегда выгодно искать нового сотрудника, некому подхватить смежные процессы.

• наличие bottleneck на этапах разработки и тестирования 

• слабое погружение QA в процессы разработки, а DEV в процессы обеспечения качества

Какой результат мы хотели получить:

В целевом виде хотели сократить количество инженеров работающих над задачей. Если раньше над фичей работал и разработчик, и QA, то теперь полностью поставить фичу может один инженер. При этом сложные технические задачи берет на себя разработчик, QA берет на себя задачи средней сложности. Целевую картину можно отобразить в виде схемы: 

Политика командной практики T-shape

С целями мы определились, настало время описать политику практики, базовые правила, области ответственности инженеров и шаги по внедрению, а затем представить ее команде и согласовать.

Политика —  документ, в котором описаны практика и ее правила, требования и ответственность участников.

Базовые правила:

• Все члены команды отвечают за качество поставки своих бизнес-задач. Это значит, что мы не создаем узкое горлышко и не сливаем ответственность на qa

• Разработчик полностью знает процессы обеспечения качества продукта

• QA инженер полностью знает процессы разработки продукта

• каждый инженер (QA и DEV) может самостоятельно поставить фичу от начала разработки до релиза

Области ответственности QA:

• Отвечает за развитие и внедрение новых техник обеспечения качества, инструментов и помощь коллегам в области QA

• Контролирует обеспечение качества продукта в команде, подсвечивает недостатки процессов или технологий обеспечения качества и исправляет их, необязательно самостоятельно. Является основным драйвером и источником информации об обеспечении качества.

• Контролирует тесты по всей пирамиде тестирования

• Знает, для чего, как работают и как используются инструменты обеспечения качества (тесты по пирамиде, тестовые тулзы и тд.)

• Знает, какие тесты на что написаны и что они проверяют

• Ревьювит тесты по всей пирамиде

• Знает, как разрабатывается продукт

• Может полностью поставить качественно разработанную и отлаженную фичу

• Знает и улучшает процессы поставки Ci/CD

Области ответственности DEV:

• Отвечает за техническое развитие проекта и процессов разработки

• Отвечает за все аспекты качества продуктового кода и его поставку

• Знает и улучшает процессы поставки Ci/CD

• Полностью поставляет бизнес ценность на прод

• Полностью ревьювит продуктовый код и тесты

• Самостоятельно сопоставляет упавшие тесты с продуктовым кодом и может локализовать проблему

• Контролирует процессы разработки фичи на всех этапах

• Знает, какие тесты и на что написаны по всей пирамиде тестирования

• Пишет и правит тесты по всей пирамиде тестирования

• Проводит тест-спецификации задач

Шаги внедрения T-Shape

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

• разносим тесты по пирамиде

• стабилизируем тесты с помощью моков, чтобы не зависеть от нестабильных интеграций

• дорабатываем CI — делаем все проверки обеспечения качества в едином пайплайне и обязательными для прогона.

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

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

DEV инженеры погружает QA в процессы разработки для повышения экспертизы:

• QA проходит курс по стеку разработки

• QA вместе с разработчиком реализует одну задачу 

• Выделяется поток простых тасок для QA с учетом нагрузки

Результаты в метриках

Политику описали. На внутренних митапах рассказали про обеспечение качества и разработку. Разрабы попробовали писать все тесты, а qa —  код.

Теперь на постоянной основе у нас DEV пишут тесты, а QA кодят бизнес-фичи. Но что мы получили в итоге? Сработала ли наша практика? На эти вопросы нам помогут ответить две вещи: метрики и фидбек от ребят.

Начнем с метрик, как самых объективных показателей. Мы выделили следующие:

Теперь давайте посмотрим на конкретные графики по этим метрикам.

  

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

После внедрения практики в марте, мы видим устойчивый тренд на улучшение. При этом продуктивность команды увеличилась.

Резюмируя по метрикам:

1. Есть положительный эффект по снижению development cycle time на 70% потока

2. Качество не только не снизилось, но и показало положительную динамику

3. Инженеры стали лучше перформить

Фидбек от участников внедрения. Мы проводили встречи с QA и DEV, обсуждали практику, собирали мнения.

Лиды: отметили рост скорости поставки и рост технических навыков у QA.

DEV: из плюсов выделили, что теперь не нужно ждать подтверждений от qa и процесс не замыкается, появилась возможность самому влиять на тесты и обеспечение качества в целом. Из минусов — сложновато въезжать в некоторые аспекты QA, не хватало документации. Этот аспект мы быстро закрыли.

QA: части ребят, примерно 1/3, было сложно погружаться в разработку, потому что привыкли писать тесты по шаблону и тестировать руками. Многие обрадовались, что они пишут бизнес-код и сами поставляют фичи — это же так почетно! Еще ребята отметили, что они стали лучше разбираться в коде.

Заключение

Резюмируем, что получилось.

Было:

• замедления на этапах тестирования или разработки, в зависимости от баланса команды

• много вовлеченных людей на одну фичу, что долго и дорого

• слабая погруженность DEV в процессы QA и QA в процесс разработки

Стало

• снизили зависимость от специфический знаний ограниченного числа инженеров (busfactor)

• сделали команду более гибкой к масштабированию

• убрали этап тестирования из флоу, теперь обеспечение качества внедрили в разработку

• QA стали больше участвовать в развитии обеспечения качества, предлагать идеи, шарить практики, продумывать направления обеспечения качества

• у QA стало появляться больше пруфов для роста по грейдам

• бизнес отнесся положительно к изменениям, потому что пропускная способность увеличилась

• команда продолжает расти в людях, в том числе и QA, но теперь каждый член команды более эффективен

• уменьшили количество инженеров, участвующих в разработке фичи

• разработчики теперь полноценно участвуют в обеспечении качества

• улучшились объективные показатели

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

Негативные аспекты.Ничего идеального в мире нет, в этом и прелесть. И при внедрении этой практики не обошлось без отрицательных аспектов.

Мы столкнулись с:

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

• сопротивлением от консервативных ребят и ребят которым сложно было погружаться в новую, хоть и смежную область

• множеством вопросов, как мы автоматизируем проверки, чтоб не тестировать руками. Ручное тестирование разрабам мы не передали, поэтому появилось много поинтов к автоматизации. Например: во всех сервисах ввели выделенные сценарные тесты, написали автоматические инструменты тестирования и тд.

И в заключение хочу сказать самое главное: не бойтесь экспериментировать, ведь это путь к постоянному совершенствованию!