Привет, Хабр! Меня зовут Илья, работаю инженером по обеспечению качества в Т-Банке. Пишу автотесты на Kotlin, занимаюсь ручным тестированием и стараюсь улучшать процессы в команде.
Недавно мой коллега рассказал об общих принципах и подходах при работе с техническим долгом QA. А я поделюсь шагами, которые помогли нашей команде улучшить повседневную работу.
За последние несколько месяцев мы внедрили алгоритм управления техническим долгом, который привел к заметным изменениям. Расскажу о нашем опыте, кейсах и метриках, которые помогли команде справляться с техническим долгом эффективно.
Что такое технический долг в QA
Представьте, что бывают такие обстоятельства: проект стремительно растет, бизнес настаивает на быстром внедрении новых фич, разработчики как с конвейера передают задачи в тестирование. QA в это время пытается удержать шаткий баланс между качеством и скоростью. Именно в таких условиях почти незаметно начинает накапливаться технический долг.
В тестировании это проявляется в отложенных задачах, которые вроде бы не требуют немедленного внимания, но постепенно превращаются в настоящую проблему. Рефакторинг тестов, создание автотестов для существующих функций, нагрузочное тестирование, улучшение процессов — все это часто остается «на потом».
Может показаться, что такие задачи не слишком критичны. Но чем дольше они откладываются, тем сильнее страдает не только качество продукта, но и сама команда. Осознав проблему накопленного технического долга, мы сделали первый шаг на пути к его сокращению. И поставили себе цель: внедрить инструменты для предотвращения его дальнейшего роста.
Основные причины накопления технического долга
После определения границ техдолга QA мы искали ответ на вопрос, что приводит к его накоплению, и вот к чему пришли.
Существенные изменения бизнес-процессов. Наша команда занимается актуализацией данных клиентов банка по требованиям федерального законодательства и государственных органов.
Сейчас у нас больше десяти процессов, которые непрерывно улучшаются и развиваются. А еще непрерывно появляются новые процессы. Из-за этого и начинают копиться задачи по техдолгу QA, особенно по рефакторингу тестов.
Недостаточный ресурс тестирования. На протяжении полугода в команде был только один QA-инженер. Приоритет отдавался бизнес-задачам, а техдолг накапливался. Это логично: при ограниченных ресурсах на улучшения просто не остается времени.
Отсутствие сформированного процесса работы с такими задачами. Когда в команде нет четких правил и подходов к управлению техническим долгом, такие задачи чаще всего откладываются или забываются. Например, задачи на рефакторинг тестов или внедрение новых автотестов редко включаются в итерационный план, если не имеют прямой связи с текущими бизнес-целями. Без формализованного подхода к планированию и распределению задач техдолг не получает должного внимания.
Решения для работы с техническим долгом
Увеличение ресурсов команды. Нужно объективно оценить, хватает ли текущей команды для выполнения поставленных задач в срок. Если оказывается, что ресурсов достаточно, можно сразу улучшать процессы. А если есть дефицит, то рациональным решением будет привлечение дополнительного QA. Это не столько способ решения проблемы, сколько предпосылка для стабильного и регулярного управления техническим долгом.
Стратегия распределения задач. Благодаря увеличению количества QA появилась политика распределения ресурсов. В команде используется стратегия разделения задач между QA: если один занят бизнес-задачами, то другой QA берет в работу задачи по техдолгу. Такой подход хорош еще и тем, что благодаря регулярной смене деятельности работа не превращается в однообразную рутину.
Обязательное пополнение бэклога техническими задачами. Еженедельно отслеживаем метрику задач, закрытых командой за итерацию, анализируем динамику и устанавливаем количество задач по среднему значению закрытых за предыдущие итерации.
В команде есть договоренности об обязательном включении технических задач в планирование каждой итерации. Мы придерживаемся такого распределения:
20% задач — технический долг;
10% — баги;
70% — бизнес-задачи.
Так гарантируется включение задач по техническому долгу в каждую итерацию. Для нас выбранные пропорции действенны, так как задачи по техдолгу выполняются без ущерба для бизнеса.
Автотесты параллельно с разработкой. В этом помогает процесс «Три амиго» после груминга задач из нового эпика. QA готовит артефакт, в котором содержится список тест-кейсов для автоматизации, и демонстрирует участникам встречи. После согласования список сразу отправляется в работу.
Обычно автотесты готовы до окончания разработки, что положительно влияет на lead time задачи. Разработчик обнаруживает и исправляет баги перед переводом задачи в тестирование.
Привлечение разработчиков к техдолгу QA. Прибегаем к этому пункту нечасто: только если задача требует быстрого выполнения, а QA заняты другими неотложными делами.
Например, автотесты в CI/CD работали нестабильно, что не давало ни одному пайплайну успешно завершиться. Весь ресурс тестирования был занят важными бизнес-задачами. Чтобы не тормозить релизы, разработчик команды устранил ошибки в flaky-тестах.
Регулярный мониторинг метрик. Анализируем:
количество созданных и закрытых задач;
время выполнения задач;
преобладающий тип техдолга.
Метрики помогают команде понимать, насколько эффективно мы движемся. Покажу на некоторых из них, как помогло внедрение всех изменений в процесс разработки и тестирования.
Для нас преобладающий тип техдолга — автотесты, поэтому нагляднее всего будет показать эффект на них.
На следующем графике отображается количество всех задач в бэклоге:
Доля автотестов в течение последних месяцев снижается. Если бы смотрели на показатели месяцев посередине графика, то отметили бы именно постепенное снижение в течение всего периода.
На графике Created vs Resolved видна тенденция на улучшение динамики.
Выводы
Мы в команде понимаем: то, что работает сегодня, завтра может устареть. Поэтому наши командные соглашения остаются гибкими и готовы к адаптации под новые вызовы.
Внедрение даже базовых процессов и правил может кардинально изменить ситуацию в команде. Работа с техническим долгом становится менее хаотичной и более предсказуемой. Это не только улучшает процессы тестирования, но и помогает уверенно двигаться к сокращению техдолга и предотвращению его дальнейшего роста.
А как обстоят дела у вас? Если в вашей команде есть действенные и полезные решения по налаживанию работы с техдолгом QA — делитесь! Будет интересно почитать, что именно помогло.