Привет! Я Женя, ведущий автоматизатор, 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 берет на себя задачи средней сложности. Целевую картину можно отобразить в виде схемы: 

Схема взаимодействия QA и DEV
Схема взаимодействия QA и DEV

Политика командной практики 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 кодят бизнес-фичи. Но что мы получили в итоге? Сработала ли наша практика? На эти вопросы нам помогут ответить две вещи: метрики и фидбек от ребят.

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

Название

Формула

Влияние на поставку

Development Cycle time (время от начала разработки до релиза в часах) 70перц

Влияние на качество

динамика багов на проде к бизнес задачам

Влияние на продуктивность команды

(релизы / QA + DEV)

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

  

Динамика багов к фичам
Динамика багов к фичам
Development Cycle time (время от начала разработки до релиза в часах)
Development Cycle time (время от начала разработки до релиза в часах)
Продуктивность команды (релизы / QA + DEV)
Продуктивность команды (релизы / QA + DEV)

Внедрять практику мы начали в марте 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, но не у всех. При найме стали сразу подсвечивать кандидатам необходимость писать продуктовый код.

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

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

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

Комментарии (6)


  1. 1nd1go
    22.10.2024 08:54

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


    1. AnnaTeylor
      22.10.2024 08:54

      Про ревью сказано миллиард раз уже: дорого, плохо, вредно. Если смотреть в тему качества, то станет очевидным, что обеспечение выгоднее контроля. В этой статье про это как раз. https://hackernoon.com/code-review-its-bad-expensive-and-ineffective-in-most-cases
      В эпоху развитого CI/CD фраза "стоимость ошибки сильно возрастает, если она пролезла в прод" не так уж и сильна. Далеко не всякие ошибки хоть как-то влияют на стоимость. Отозвать партию дисков из магазинов было дорого. Сейчас обновление на проме делает скрипт за секунду, он уже есть готовый и единичный его вызов практически бесплатен.
      Если делать нормальный план откаты и в целом изменения небольшими кусками, которые можно откатить, то проблем не вижу.


      1. 1nd1go
        22.10.2024 08:54

        Я про ревью ничего не писал. Я писал про то что, когда тест приходит писать другой человек (не автор имплементации) - это увеличивает шансы на корректную валидацию ПО.

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


    1. evgeniy_mea Автор
      22.10.2024 08:54

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

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

      В некоторых командах, мы попробовали схему полного (без аналитика) участия инженеров (QA и DEV) в анализе. Пробовали на несложных задачах". То есть было прямое взаимодействие QA или DEV с заказчиком. В целом эта схема тоже показали неплохие результаты.


  1. Iknwpwd
    22.10.2024 08:54

    А если бизнес будет сам сразу кодить и тестить это же вообще квинтисенция эффективности


    1. evgeniy_mea Автор
      22.10.2024 08:54

      Было бы здорово)) Только бизнес это не команда поставки и у них другие задачи, направленные на исследования/анализ бизнес среды и генерацию прибыльных стратегий.

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

      Исполнять тестирование и разработку, может каждый из них.