Разделение ответственности между QA-инженером и разработчиком в Scrum-команде

2024-12-26 13:00 Статьи QA

Всем привет! Я Дима Солодов, инженер по тестированию в Авито. Тружусь в команде, разрабатывающей инициативу по привлечению новых пользователей в продукты Авито.

За свой почти десятилетний опыт в тестировании я успел поработать в разных методологиях – от классического «водопада» до современного и эффективного Agile, а именно – по Scrum.

У автоматизации тестирования в Scrum-командах есть ряд особенностей, с которыми приходится сталкиваться или же вовсе преодолевать их при работе над улучшением продукта. Об этом и пойдёт речь в данной статье.

Для начала – разберёмся с базовыми понятиями. Scrum – один из самых популярных фреймворков Agile-манифеста, подразумевающий наличие кроссфункциональной и самоорганизованной команды, итеративно работающей над «поставкой» пользователям продуктового инкремента.

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

Особенности работы с задачами в Scrum

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

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

Организация работы в команде

Обычно усовершенствование продукта требует вмешательства на разных уровнях – от изменений на бэкенде и в базах данных до клиентских правок на фронтенде. При этом визуально представить покрытие автотестами этих изменений нам помогает «Пирамида тестирования».

В общем и упрощенном виде пирамида может выглядеть так:

Видим несколько уровней автоматизации, при этом, к примеру, у нас в Авито на уровне пользовательских сценариев почти каждая из платформ (а у нас их четыре: Android, iOS, Web, Mobile web) имеет свой фреймворк автоматизации.

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

И тут нам на помощь приходит разделение ответственности по написанию автотестов внутри команды. А наличие в кроссфункциональной команде всех функций разработки даёт великолепную возможность для этого.

Как это может выглядеть? Те, кто хорошо пишут код, занимаются технической реализацией автотестов. А обдумыванием и формированием тестовых сценариев для автоматизации занимается QA-инженер, обладающий необходимыми компетенциями в тест-дизайне.

На практике обычно QA-инженер берёт на себя одну или две платформы, на которых может сам писать автотесты. А остальные платформы «закрывают» разработчики, которые и пишут сам код продукта для этих платформ.

Кто и когда обсуждает реализацию?

Возникает логичный вопрос – а кто и в какой момент определяет, какие тесты на каком уровне будут написаны?

В Авито мы активно практикуем встречи 3 Amigos и груминги задач (Product Backlog Refinement, PBR), на которых формируем продуктовые критерии приёмки с приёмочными тестами и описываем на какой платформе какие изменения нужно сделать. После этого – самое время «раскидать» приёмочные тесты по пирамиде, чтобы в дальнейшем автоматизировать их.

В общем виде процесс планирования работ по автоматизации может выглядеть так:

Вопросы, помогающие понять, на каком уровне пирамиды какую проверку автоматизировать:

можно ли эту проверку сделать на более низком уровне пирамиды (например, на уровне unit-тестов)?
будет ли эта часть кода меняться в дальнейшем? Возможно, её достаточно проверить один раз и даже вручную, чем тратить ресурсы на автоматизацию;
какие из продуктовых пользовательских сценариев мы считаем критичными для покрытия автотестами именно на e2e-уровне?

Когда приёмочные тесты распределены по пирамиде, необходимо зафиксировать всё в задачах, чтобы спланировать работу на спринты. После этого можно приступать к реализации.

Кто и когда пишет автотесты?

Момент реализации автотестов зависит от того, применяется ли в команде ATDD (Acceptance Test-Driven Development). Если применяется – то в спринт берётся автоматизация как проверок на нижних уровнях пирамиды (unit-тесты и интеграционные тесты), так и автоматизация пользовательских сценариев на e2e-уровне, что впоследствии помогает проверить продукт на соответствие заявленным требованиям в рамках того же спринта.

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

Важно понимать, что при работе по Scrum помимо продуктового инкремента, мы должны обеспечивать ещё и необходимый уровень качества продукта. И тут мы сталкиваемся с одной из частых сложностей: продукт хочет как можно быстрее выдать изменение пользователям и как можно меньше ресурсов на это потратить. Здесь начинаются «торги» – взять ещё одну продуктовую задачу на разработку или задачу на автоматизацию? Ведь спринт всегда ограничен по времени и ресурсам.

В Авито есть формализованное правило о минимальном покрытии unit-тестами кода на бэкенде. В случае, если покрытие кода недостаточное, изменение внедрить не получится, пока не будут написаны новые или же актуализированы и дополнены существующие unit-тесты.

Для остальных уровней пирамиды на уровне компании такого правила пока нет. Хорошая привычка в такой ситуации – брать отложенные в текущем спринте задачи по автоматизации в следующий спринт.

Аргументами за взятие задач по автоматизации могут быть:

наличие вовремя написанных автотестов уменьшает риски возникновения багов в продакшене;
новые изменения и доработки смогут быстрее попадать к пользователю за счёт уменьшения дорогих по времени и ресурсам ручных регрессионных проверок, ещё не покрытых автотестами;
откладывание задач по автоматизации растит технический долг команды, который всё равно придётся потом делать;
взятие продуктовых задач, вместо задач на автоматизацию, может провоцировать «бутылочное горлышко» на этапе тестирования, замедляя всю разработку в целом.

Значимым для понимая моментом является то, что в кроссфункциональной команде за качество продукта отвечает не только QA-инженер, а вся команда. Каждый участник может взять на себя часть автоматизации тестирования.

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

Как договориться насчет объединения ответственности?

Ответ на этот вопрос зависит от состава и возраста команды. Если это только что сформированная команда под конкретный проект, удобнее всего договориться «на берегу» о том, кто и в какой момент будет разрабатывать автотесты – менять уже готовые процессы всегда сложнее.

Если речь о сформированной команде с устоявшимися процессами, найти ресурс для автоматизации можно через регулярное выделение какой-то части из объёма спринта под автоматизацию, к примеру: 15-20% от объёма спринта.

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

Какие проблемы могут возникнуть при настройке процесса и как их решать?

Проблема: задачи на автоматизацию «не влезают» в спринты.

Решение:

обсудить в команде, все ли понимают ценность автоматизации? Самым эффективным способом будет основать свою позицию на данных – подсчитать время, которое регулярно тратится на ручное регрессионное тестирование и оценить объём работ, который нужен для разработки автотестов с их последующей поддержкой.
Хорошим подспорьем будет договорённость в команде в обязательном порядке брать в следующий же спринт задачи, которые не поместились в текущий спринт;
в случае, если накопилось много технического долга по автоматизации, выходом может стать технический спринт, в который не берутся продуктовые задачи, а выполняются задачи из технического долга. В Авито такое практикуем, например, в конце квартала/полугодия.

Проблема: уже ранее разработанные автотесты «падают» и/или «флакуют».

Решение:

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

Проблема: функциональность постоянно меняется, проводятся эксперименты (АБ-тесты), а на всех пользователей на продакшене функциональность не выкатывается и неизвестно, какой вид будет иметь финальная версия.

Решение:

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

Плюсы и минусы разделения ответственности

Плюсы:

есть возможность брать в спринты автоматизацию сразу на всех уровнях пирамиды, обеспечивая полное покрытие автотестами к концу спринта;
легче применять ATDD;
больше разработчиков вовлечено в процесс автоматизации тестовых сценариев, что повышает вероятность нахождения ошибок на ранних этапах;
отсутствие завязки на одном QA-инженере нагрузки по автоматизации и, как следствие, минимизация возникновения «узкого горлышка» при написании автотестов.

Минусы:

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

Заключение

Scrum-команды – это динамичные и гибкие команды, в которых реакция на изменения важнее следования изначальному плану. И обеспечивать необходимое качество продукта в таких условиях помогает разделение ответственности между участниками команды.

Что следует помнить, когда принято решение внедрить разделение ответственности:

за качество продукта отвечает вся команда, а не один конкретно взятый человек;
важно донести ценность и пользу автоматизации до всех инженеров, участвующих в написании тестов;
упростить внедрение разделения ответственности помогает формирование критериев приёмки и распределение проверок по пирамиде тестирования;

Больше о тестировании в Авито вы можете узнать из статей моих коллег:

Как ручному тестировщику стать автоматизатором?

Как и зачем мы написали 5000 интеграционных тестов за пару часов

Тестируем в микросервисах: TaaS и пять шлюзов качества

Что поможет настроить процесс работы с обращениями пользователей

А еще подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров и работе в Авито, а также анонсируем митапы и статьи.