Итак, вы решили провести AutoDay. А это значит, что вы хотите раз и навсегда целенаправленно сократить скопившийся технический долг и желательно надолго. 

Но подождите…

Что такое технический долг и откуда он берется?

Википедия даёт нам такое определение: 

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

Из названия ясно, что это что-то, оставленное на потом. И избежать техдолга достаточно сложно. Он всегда растёт.

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

Давление бизнеса

Бизнес часто хочет фичу уже сейчас или может быть даже вчера. В редких случаях через пару недель.

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

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

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

Круг замыкается.

Отсутствие процессов или понимания процессов

Сотрудник с небольшим опытом на проекте может неправильно понимать выстроенный процесс или не понимать его вообще.

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

Отсутствие тестовой документации

Например, до начала тестирования не составляется чеклист.

Тестировщик в процессе непосредственного тестирования проходит сценарии, полагаясь на свой опыт: «Это мы проверяем, это тоже проверяем. А это мы другими проверками перекроем. Это я вроде уже проверял. Ну ладно, нормально всё будет».

При таком подходе можно легко пропустить тестовые сценарии, которые необходимо пройти. Ещё интереснее такие сценарии автоматизировать.

Отложенный рефакторинг

Казалось бы, при чем здесь тестирование?

Но автотесты это тоже код. За ним тоже нужно следить. В идеале сразу писать весь код очень классно, понятно и актуально. Но как и любой код, код проекта автотестов тоже имеет свойство устаревать. 

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

Консервативные подходы к работе с техническим долгом

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

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

Устанавливаем техническую квартальную цель каждому тестировщику на проекте

В течение квартала каждый участник команды 20% своего рабочего времени посвящает выполнению технических задач. 

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

Долг по бизнес-фичам не берем в технический долг

Для всего, что не успели доделать в рамках задачи по тестированию, мы выбиваем время у бизнеса. В качестве аргументов выступают: 

• «Мы некорректно оценили время для тестирования и покрытия автотестами фичи».

• «Возникли непредвиденные обстоятельства или факторы во время выполнения задачи».

• «Нам обязательно нужно это сделать, иначе потом будут проблемы».

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

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

Личные цели

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

Почему всё вышеперечисленное не эффективно?

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

А технические цели разработчиков часто связаны с обновлением кода проекта, который не завязан на бизнес-логику. 

• Это может быть обновление версии Java. 

• Обновление версии Node.js. 

• Отказ от старых неподдерживаемых фреймворков и библиотек. 

• Рефакторинг кода.

• Исправление уязвимостей.

• Другие подобные работы, которые не связаны с бизнес логикой проекта.

Соответственно, всё, что разработчики исправят, тестировщикам нужно будет протестировать и раскатить на прод.

Б??óльшая часть технических целей тестировщиков как раз включает в себя тестирование задач разработчиков. Поэтому в техническое время технический долг тестировщиков сильно сократить не удаётся.

Во-вторых, бизнес приоритезирует бэклог команды.

Если у бизнеса есть горящие задачи, которые нужно разработать, протестировать и раскатить уже прямо сейчас, то бизнес не будет говорить: «Да, конечно, возьмем вот ту задачку по написанию тестов на тот модуль, с которым мы сейчас не работаем и который замечательно работает в проде».

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

В-третьих, личная цель — прекрасная вещь, но тут тоже есть проблемы.

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

Спасение от техдолга — это утопия. 

Есть хорошая статья про техдолг на Хабре:

Как техдолг может утопить команду, и что делать, чтобы этого не допустить

Существует миф, что один сильный программист может быть в 10 раз продуктивнее другого — ten-X develo...

habr.com

И если я её правильно понял, то регулярный мелкий стресс, которым и является техдолг, можно победить одним-двумя «волевыми усилиями»: взял, собрался, разгрёб хаос и сразу видишь результат. И ты спокоен как лев, поужинавший зеброй.

И таким стрессом (а на деле антистрессом) стал AutoDay.

Процесс подготовки и проведение

Сначала формальности. 

Automation day или AutoDay — ограниченная во времени активность для интенсивного и целенаправленного сокращения технического долга. В нашем случае, для сокращения технического долга по автоматизации тестирования.

Какие отличительные особенности у этого мероприятия?

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

• Это подготовленный бэклог технического долга. Подготовленный именно к этому мероприятию.

• Сиюминутное ревью кода от других участников AutoDay.

• Мотивация каждого участника подкрепленная конкурсной системой оценки и вознаграждения.

• Технический лидер доступен весь день. Его не нужно вылавливать между встречами или постоянно напоминать ему о себе.

Договорились с бизнесом и назначили дату проведения

Необходимо договориться с бизнесом и выделить время для работы с нашем техдолгом. 

А какие аргументы здесь могут помочь?

Главным аргументом было сокращение времени на тестирование и увеличение скорости поставок на прод. 

Абстрактная фраза вышла. Давайте её раскроем. 

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

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

Бизнес согласился.

Обновили и дополнили технический бэклог

Проверили задачи на актуальность. Неактуальные задачи актуализировали, отсутствующие задачи создали. 

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

Задачам присвоили лейбл, по которому их легко найти.

Подготовили регламент проведения мероприятия

В регламенте был описан порядок взятия задач в работу, правила проведения ревью кода, время начала и окончания AutoDay, правила присвоения баллов.

Этот регламент мы заранее обсудили на общей встрече. Задали вопросы: «Что это значит? Зачем это нужно? Почему так, а не иначе?»

Сформировали предложения, которые пришли в голову. Какие-то предложения сразу зафиксировали и внесли в регламент, какие-то отложили на подумать. 

Создали канал для коммуникаций 

В нашем корпоративном мессенджере.

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

В канале мы могли быстро обмениваться вопросами и ответами. Кидали ссылки на ПРы, тегали ревьюеров. Предупреждали о том, что какую-то задачу хотим забрать и так далее. 

Установили стабильные версии сервисов на стенд

Чтобы не ловить лишние баги и быть уверенным в том, что тесты мы пишем уже по работающему в проде функционалу.

Также попросили разработчиков и других участников команд не перекатывать эти сервисы. В случае необходимости проверки можно было проводить на другом стенде.

Подводные камни

Конечно, без подводных камней не обошлось и нам пришлось также набить некоторые шишки. С чем мы столкнулись? 

Конфликты в PR

Это одна из важных вещей (первая из двух, об этом позже) в обратной связи — «Много конфликтов в пул реквестах». 

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

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

С одной стороны, это тоже опыт. С другой стороны, решение конфликтов съедает время.

Непогруженность в проект 

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

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

Очередность ревью PR

Ревью проводили по очереди. В итоге каждый участник AutoDay ревьюил одинаковое количество PR. 

За ревью тоже давали очки. 

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

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

После AutoDay возвращали всё обратно)

Нехватка времени на отработку замечаний и ревью кода в конце AutoDay

У любого мероприятия есть время окончания. Мы перестали брать задачи в работу за час до окончания AutoDay. Но не учли время, которое требуется на ревью кода и на исправление замечаний.

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

Пара PR так и не доехала до мастера.

Недостаточность аналитики и тестовых данных для автоматизации

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

Для некоторых проверок тестовые данные не были заранее подготовлены. Приходилось их готовить во время AutoDay. К сожалению, подготовка тестовых данных — не всегда быстрая задача. 

Предчувствую вопрос: «А вы что, не генерируете тестовые данные?». Да, мы не все данные создаём перед выполнением теста. Часть данных захардкожены на стенде и обновляются раз в квартал. В нашем случае это сделано для стабильности тестов, ибо генерация тестовых данных затрагивает несколько сторонних систем, которые не всегда бывают стабильными.

Неактуальные или неработающие тесты

Такие тесты на проекте тоже есть. Может и у вас тоже)

Нужно было разбираться: это мои доработки повлияли на работоспособность существующих тестов или они просто нестабильные? Времени отнимает много, особенно у тех, кто не погружен в проект.

Эта проблема повлекла за собой другую проблему.

Проблема, связанная с отчетами о прогонах

Казалось бы, написал автотест, залил ветку в удаленный репозиторий, запустил прогон и убедился, что все работает.

Что может пойти не так?

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

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

После окончания AutoDay потратили ещё время на то, чтобы некоторые доработки поправить или откатить, так как они блокировали удалённый запуск тестов.

И что же в итоге?

• Добились увеличения покрытия автотестами с 60 до 70%. Было написано около 100-120 E2E тестов.

• Закрыли 30% бэклога, подготовленного к AutoDay.

• Во время отладки новых тестов были обнаружены некритичные дефекты, которые мы зафиксировали в Jira.

В обратной связи писали о двух вещах больше всего (о конфликтах в PR уже рассказал выше):

«Никто не отвлекал от автоматизации». 

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

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

На основе обратной связи 

Мы доработали регламент проведения AutoDay для следующих мероприятий. Вынесли следующие пункты:

• Заранее готовить тестовые данные. А именно, учесть необходимость подготовки тестовых данных на этапе создания задачи.

• До начала AutoDay обновить все тесты. Пометить неработающие. Можно добавить задачи на починку таких тестов, если это уместно.

• К пул реквесту обязательно прикладывать отчет удаленного запуска автотестов.

• После autoday выделить полдня для ревью, исправления замечаний и закрытий всех пул реквестов.

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

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

• Подготовить задачи по разным частям проекта для минимизации конфликтов.

Конец.

---

Полезные статьи.

Как мы управляем техническим долгом аналитики

В рамках одного из первых проектов в Альфе мы с командой делали приложение по работе с группами плат...

habr.com

Техдолг — нельзя копить, закрывать

Технический долг по аналитике — это любая отсутствующая документация на функционал, который поставле...

habr.com

Задача прогнозирования дохода клиента, или Как избавиться от неприличных вопросов в заявке

Спрашивать о зарплате — неприличный вопрос. Конечно, если вас не спросили об этом на Патриках ?. Пр...

habr.com

Йо-хо-хо и бутылка типографской краски

Контекст, или Как пиратство вообще стало возможным На самом деле пиратство, возможно, никогда бы и н...

habr.com

Как сделать мультитул на VS Code

Если от IBM инструментов уже немного устал С вами на связи Артур Яхин, я из команды разработчиков ba...

habr.com

Пентест для самых маленьких на примере WinRAR

Эта статья предназначена для ИТ-специалистов, специалистов по информационной безопасности и всех, кт...

habr.com