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

За свой почти десятилетний опыт в тестировании я успел поработать в разных методологиях – от классического «водопада» до современного и эффективного 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, там мы рассказываем больше о профессиональном опыте наших инженеров и работе в Авито, а также анонсируем митапы и статьи.