Разделение ответственности между QA-инженером и разработчиком в Scrum-команде
Всем привет! Я Дима Солодов, инженер по тестированию в Авито. Тружусь в команде, разрабатывающей инициативу по привлечению новых пользователей в продукты Авито.
За свой почти десятилетний опыт в тестировании я успел поработать в разных методологиях — от классического «водопада» до современного и эффективного Agile, а именно — по Scrum.
У автоматизации тестирования в 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, там мы рассказываем больше о профессиональном опыте наших инженеров и работе в Авито, а также анонсируем митапы и статьи.
