Как закрыть весь техдолг автотестов за два дня «по-домашнему»

Когда я только села писать эту статью про QA Automation Day, у меня было хорошее настроение: «Не буду говорить о сложностях и страданиях, глубокой аналитики, а расскажу о том как у нас прошло гладко, без эксессов, именно так, как мы и намечали». Если бы…

Привет, меня зовут Яна, я технический лидер тестирования Платежей и переводов Альфа-банка и сегодня мне бы хотелось поделиться с вами интересным опытом, который, в перспективе, можно использовать и как добрую традицию. Речь пойдет о мероприятии под названием «QA Automation Day».

41d811b586f48d9353ba5abaaceabcc3.png

Сначала была боль

Сначала было слово наша изначальная проблема…Заключалась она в бэклоге, а точнее, в его большом объеме. Что же там объемного?

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

Мы должны быть уверены, что мошенники не могут с помощью своего токена получить данные другого клиента банка. Задача не из простых!

Собравшись с коллегами на анализ решения данной задачи быстро посчитали, что имея в прямом пользовании около 30 микросервисов мы перейдем черту за 150 тестовых сценариев, требуемых для анализа, воспроизведения и автоматизации. А до конца месяца их нужно срочно автоматизировать.

Вроде мало? Можно быстро закрыть. Ведь у нас 30 боевых единиц профессиональных QA. Это по 5 ендпоинтов на человека, минимум. 

Однако есть пара нюансов…

№ 1. Один ендпоинт может иметь несколько потенциально уязвимых данных, требуемых проверки. Это увеличивает общий объем работы.

№2. Тестировщики распределены по бизнес-командам и выполняют свои непосредственные обязанности — проводят функциональное тестирование поставляемого функционала и поэтому не могут срочно приступить к нашей потребности в закрытии технического долга. Другими словами — они заняты. Условно, один QA может взять одну «задачу» в виде эндпойнта в день. Итого получаем 150 условных дней на закрытие.

№3. Покрыть автотестами уязвимые данные ни аналитик, ни разработчик не могут. Нет, конечно, могут, но им придется на одну задачу убить один день, без учета времени на обучение. В этом варианте получаем дней гораздо больше, чем 150.

Масштаб проблемы нам был ясен.

Итак, у нас было два стула варианта: закрывать бэклог в «свободное время» (несколько месяцев) или как-то закрыть бэклог за один раз. 

На самом деле вариантов не было — закрывать бэклог в свободное время мы не можем, нам нужно сделать все это за один раз. 

Прекрасная идея, но возникает нюанс — как собрать всех в одном месте?

Тестировщики не могут прямо сейчас приступить к этим задачам, если они, опять же, заняты в своих командах. А дополнительных ресурсов и людей, которые могли бы закрыть срочную техническую потребность на стороне не найти — нужен опыт и знания коллег, работающих в платежах и переводах. Время поджимает, нам понадобятся все силы коллег в течении нескольких дней для покрытия такого объемного технического долга.

И здесь мы вспомнили про багатон

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

1aa1835a11432fe1023bb99dbb0795b3.png

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

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

7ea5a4ca95270917180f429f216d6d0a.png

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

503600b45d15cf9f38006a9a978bda3a.png

Итак, игра была объявлена!

Но запланировать мероприятие и получить бюджет не равно провести мероприятие. Это только самые первый и маленький шаг к победе над задачей! Здесь начинается самое интересное.

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

c49c0fee7a74008781e8ffa8a9041ec4.png

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

Итак, пойдем сверху вниз.

  • Формирование бюджета. Ну, здесь все просто, начальство согласовывало нам призовой фонд, который я оставлю секретом.

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

  • Бэклог. Список ендпоинтов мы имели на руках, но надо было привести его в такой формат, чтобы коллегам было удобно брать еднпоинты в автоматизацию, а нам после считать результаты. Ничто лучше, чем таски в Jira на специальной доске не могло подходить для такой наглядности.

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

  • Игровая механика. Описали свод правил и процесс работы во время «автодня».

  • Согласование дня проведения. Мы понимали что за один день уложиться нереально и смогли убедить коллег выделить тестировщиков на два дня подряд. Честно скажу, я не верила, что такое получится. Однако, удалось. Но этот момент я затрону еще раз чуть позже.

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

Как таковой «рекламной кампании» не было, но, тем не менее, о мероприятии узнали соседние дирекции, оценили идею и присоединились к нам. Лиды QA провели аналогичные работы для своих дирекций и были готовы присоединиться к нашей активности в намеченные даты.

В списке пункты выглядят идущими друг за другом, но все эти «этапы» шли параллельно (что добавляло сложностей) Одним самым сложным для нас, организаторов, была аналитика.

Аналитика, что ты делаешь, прекрати

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

А вот нееееет!

А вот нееееет!

Но я не могу держать это в себе, честно. Это было больно.

В чем же боль? Как уже было упомянуто бизнес согласился отпустить тестировщиков всего на два дня. Задача — покрыть все ендпоинты автотестами, и за два дня без предварительной аналитики это невозможно сделать. Представьте себе, что мы соберем людей, дадим им список всего лишь из 150 ендпоинтов, они потратят неделю на их изучение и только потом смогут написать на них автотесты. Не нужно даже считать, чтобы понимать, что в два дня такую работу не уместить.

Что мы сделали? На каждый потенциально уязвимый ендпоинт мы создали по задаче в Jira и приложили в каждую из них данные на воспроизведение. 

Дальше участник мог бы работать с задачей по такому алгоритму…

414942b074e69b2ea217c63d2aae09e6.png

Это скрин алгоритма из нашего манифеста Идеального Automation Day, каким он нам виделся. В принципе, он таковым он и вышел, ведь участникам во время мероприятия оставалось только перенести данные в фреймворк автотестов. И с такой задачей любой человек во время дня мог повторять одну итерацию: взял задачу — написал тест из документации — прошел ревью ПР.

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

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

В итоге, мы получили даже больше, чем 150 задач, всего лишь 230. «Как мы и хотели».

Яна, технический лидер направления тестирования Платежей и переводов Альфа-банка, 26 лет.

Яна, технический лидер направления тестирования Платежей и переводов Альфа-банка, 26 лет.

Итак — настал день X

Утром собрались со всеми участниками мероприятия и начальники и официально начали нашу гонку.

Я бы хотела подчеркнуть тот момент, что AutoDay в нашем понимании не был на уровне оффлайн-багатона или другого «модного» мероприятия. Мы планировали максимально эффективно провести этот день. А когда мы эффективно работаем? Когда нам удобно и никто не отвлекает. Отчасти поэтому  мероприятие и проводилось в онлайн формате, чтобы участвовало максимальное количество человек. 

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

У нас всё прошло «по-домашнему».

 Мы просто созвонились в Альфа-Толк (как в «Зуме»), раздали задачи и погнали.

Здесь должен быть скрин окна в Альфа-Толк со всеми участниками для наглядности, но его нет, поэтому мем.

Здесь должен быть скрин окна в Альфа-Толк со всеми участниками для наглядности, но его нет, поэтому мем.

Чтобы обеспечить драйвовую атмосферу и быстро решать возникающие вопросы организаторы спрятались остались в комнате Альфа-Банк и в течение всего мероприятия дежурили и отвечали на все вопросы.

Участники, конечно, могли как сидеть с нами в общей комнате, либо же приходили с вопросами, а в остальное время работали как им удобно.

До сих пор я вспоминаю прошедшие дни с улыбкой, хоть и было тяжело. Мы почувствовали себя большой дружной командой, семьей, которая весело и активно решала приятные задачи, а не работала (спасибо готовым задачам).

В течении дня, я следила за статусами задач и анонсировала ребятам. Так как у нас не был прикручен Burndown Chart (была обычная канбан-доска, ребят, настроить всё не успели) то я могла лишь отображать ребятам график перехода задач по статусам.

3641a520898dc215f04c37657b073779.png

Что на скриншоте:

  • Зеленое — завершенные задачи. 

  • Оранжевое — ToDo.

  • Фиолетовое — In Progress

  • Синее — Review.

Как вы понимаете, около сотни задач уже было закрыто на начало мероприятия, этому поспособствовало наше раннее обучение — после воркшопов мы раздали ребятам задачи на «разгонку», которые и отражены завершенными на графике

В конце дня мы объявили об окончании дежурства, однако участники разошлись отдыхать чуть позже (на графике видно, что после 8 вечера еще кто-то решал задачи), так как результаты суммировались за весь календарный день.

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

Что было дальше?

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

Во время проведения мероприятия ребята обращались к нам с нетривиальными случаями, с которыми столкнулись во время более подробного изучения потенциально уязвимых ендпоинтов. Все таки при анализе более 200 ендпоинтов организаторы могли что-то да пропустить. Так и случилось — мы выяснили что несколько ендпоинтов невозможно покрыть автотестами в текущей реализаици нашего тестового фреймворка, и нам придется искать обходные пути уже после завершения всех остальных работ.

Но самым вкусным считаем то, что мы обнаружили 6 багов с высоким приоритетом и исправили в самые короткие сроки.

Меньше чем через неделю мы объявляли наших победителей и раздавали призы, будучи увереными в том, что в нашем направлении больше не имеется IDOOR уязвимостей и при будущих поставках мы будем отлавливать их появление!

Вот такая прекрасная сказка, друзья

Давайте сделаю какие-то выводы:

  • Можно провести хакатон, багатон, и прочий «тон» без внешней мишуры, «по-простому».

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

  • Альфа-Банк любит и поддерживает массовые инициативы внутри IT! Только благодаря поддержке Бизнеса и коллег мы смогли такое организовать. Я рада, что мы показали что мы настоящая команда!

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

Из негативного — ребята отозвались об идее «двух дней автоматизации». Два дня подряд показались некоторым утомительными, и если бы они хотели повторить, то в формате «одного дня». Хотя такого шага от нас потребовал объем технического долга, мы были с ними согласны. И если рискнем повторить, обязательно учтём!

И в конце хотела бы оставить хвалебные отзывы участников Автодня.

83afcce5645af85012d19e479a9c86f4.pngfdbe1c42282db7234bd159c90d62518a.png

Спасибо, если у вас был опыт участия или организации подобных мероприятий, поделитесь опытом: что можно было бы сделать лучше, а что получилось хорошо)

© Habrahabr.ru