У нас 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 берет на себя задачи средней сложности. Целевую картину можно отобразить в виде схемы:
Схема взаимодействия 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 (время от начала разработки до релиза в часах)
Продуктивность команды (релизы / QA + DEV)
Внедрять практику мы начали в марте 2023 года. Видим, что до этого процесс поставки шел не очень гладко, были как замедления, так и успешные периоды, когда багов было меньше, а фичи попадали на прод быстрее.
После внедрения практики в марте, мы видим устойчивый тренд на улучшение. При этом продуктивность команды увеличилась.
Резюмируя по метрикам:
Есть положительный эффект по снижению development cycle time на 70% потока
Качество не только не снизилось, но и показало положительную динамику
Инженеры стали лучше перформить
Фидбек от участников внедрения. Мы проводили встречи с QA и DEV, обсуждали практику, собирали мнения.
Лиды: отметили рост скорости поставки и рост технических навыков у QA.
DEV: из плюсов выделили, что теперь не нужно ждать подтверждений от qa и процесс не замыкается, появилась возможность самому влиять на тесты и обеспечение качества в целом. Из минусов — сложновато въезжать в некоторые аспекты QA, не хватало документации. Этот аспект мы быстро закрыли.
QA: части ребят, примерно ⅓, было сложно погружаться в разработку, потому что привыкли писать тесты по шаблону и тестировать руками. Многие обрадовались, что они пишут бизнес-код и сами поставляют фичи — это же так почетно! Еще ребята отметили, что они стали лучше разбираться в коде.
Заключение
Резюмируем, что получилось.
Было:
замедления на этапах тестирования или разработки, в зависимости от баланса команды
много вовлеченных людей на одну фичу, что долго и дорого
слабая погруженность DEV в процессы QA и QA в процесс разработки
Стало
снизили зависимость от специфический знаний ограниченного числа инженеров (busfactor)
сделали команду более гибкой к масштабированию
убрали этап тестирования из флоу, теперь обеспечение качества внедрили в разработку
QA стали больше участвовать в развитии обеспечения качества, предлагать идеи, шарить практики, продумывать направления обеспечения качества
у QA стало появляться больше пруфов для роста по грейдам
бизнес отнесся положительно к изменениям, потому что пропускная способность увеличилась
команда продолжает расти в людях, в том числе и QA, но теперь каждый член команды более эффективен
уменьшили количество инженеров, участвующих в разработке фичи
разработчики теперь полноценно участвуют в обеспечении качества
улучшились объективные показатели
Еще команда показала одни из лучших результатов по поставке и качеству, что мотивировало ребят продолжать практику. QA и разработчики погрузились в работу друг друга и поставленные цели были достигнуты.
Негативные аспекты.Ничего идеального в мире нет, в этом и прелесть. И при внедрении этой практики не обошлось без отрицательных аспектов.
Мы столкнулись с:
сложностями в погружения в бизнес-код у QA, но не у всех. При найме стали сразу подсвечивать кандидатам необходимость писать продуктовый код.
сопротивлением от консервативных ребят и ребят которым сложно было погружаться в новую, хоть и смежную область
множеством вопросов, как мы автоматизируем проверки, чтоб не тестировать руками. Ручное тестирование разрабам мы не передали, поэтому появилось много поинтов к автоматизации. Например: во всех сервисах ввели выделенные сценарные тесты, написали автоматические инструменты тестирования и тд.
И в заключение хочу сказать самое главное: не бойтесь экспериментировать, ведь это путь к постоянному совершенствованию!
