Привет! Мы тестировщики ЮMoney — Александр Туманов из команды Личного кабинета ЮKassa и Кирилл Жуков из команды АРМ-платформы.
В этой статье расскажем, как работаем с бэклогом задач для тестировщиков, какие трудности могут возникать и как с ними бороться. Статья будет полезна тем, кто сталкивался с проблемами приоритизации задач из бэклога.
Что такое бэклог
В процессе разработки ПО так называют список продуктовых задач, которые пока не сделали, но которые нужно выполнить в будущем. Над бэклогом с задачами работает менеджер проектов и команда разработки. Задачи оцениваются в рамках груминга (процесса оценки задач с командой) и планирования спринта (временного интервала, в течение которого команда выполняет заданный объём работы).
Внутри общего бэклога команды есть задачи для тестировщиков — от аналитики минорных багов до написания автотестов на функциональность системы.
С обновлением и развитием продукта, а также технологических требований бэклог задач меняется, становится более объёмным, из-за чего работа с ним может стать неэффективной. Тестировщики будут думать, какие задачи брать в первую очередь для поддержания и увеличения тестового покрытия и почему, а у проектных менеджеров появятся вопросы об объёмах работы тестировщиков в спринте.
Вот пример бывшего состояния Kanban доски команды ЛК с задачами:
В колонке «TO DO» — 21 задача, которую нужно выполнить. Применены настройки доски Kanban для фильтрации по текущему статусу задачи и по проектам или членам команды. Но всё же такой список недостаточно информативный: непонятно, какую задачу нужно выполнить в первую очередь и почему другие стоит отложить. Задачи могут быть разного плана: аналитика инцидентов, написание новых тест-кейсов, стабилизация автотестов и так далее.
Мы в команде Личного кабинета (ЛК) ЮKassa решили сделать приоритизацию задач бэклога тестировщиков — составить список по общим группам, собрав вместе задачи со схожими целями и направленностью.
Что нам даст такая приоритизация бэклога?
Задачи будут отсортированы по приоритетам. Важные и срочные можно будет выполнять в первую очередь.
Задачи будут разделены на группы по общему признаку. Мы сможем видеть похожие задачи.
Увеличится скорость покрытия автотестами фичей проекта.
Появится более удобный и понятный интерфейс с прозрачной приоритетностью списка задач тестировщиков для всей команды разработки.
За счёт всего этого ресурсы членов команды тестирования будут использоваться более рационально.
Чтобы составить общие группы приоритизации в команде ЛК ЮKassa, мы проанализировали задачи — зачем они нужны, какие к ним требования. При этом учитывали процесс планирования проектов. Мы работаем по Agile, в команде ЛК проекты выполняются последовательно и практически не пересекаются друг с другом.
В результате мы выявили список категорий, к которым относятся задачи.
Приоритизацию построили в следующем порядке:
Задачи на покрытие автотестами фичей, которые сейчас находятся в работе и ещё не выпущены в прод. Поставили эту категорию первой, так как smoke-автотесты подтверждают, что основной функционал новых фичей работает правильно перед релизом в прод.
Задачи на покрытие автотестами других непокрытых фичей. В команде могут существовать фичи и тест-кейсы, которые не покрыты автотестами.
Задачи на покрытие автотестами багов и инцидентов. Здесь предполагается покрытие автотестами неочевидных сценариев.
Задачи на стабилизацию автотестов. Это автотесты, которые уже существуют. Они нестабильные, но работают.
Задачи, требующие аналитики. Проблемы, которые требуют исследования различных кейсов, и процессы, по которым необходимы доработки.
Задачи на рефакторинг автотестов.
В зависимости от поступающих задач и целей команды в текущем спринте приоритеты выполнения задач могут меняться. Также список приоритетов может дополнятся — например, мы добавили активность по написанию инструкций для тестирования фичей или настройки тестовой среды.
Итак, у нас получился план приоритизации задач беклога. Теперь необходимо сделать это наглядно и отфильтровать задачи.
Вот как это может выглядеть:
Далее расскажем, с помощью каких инструментов можно сделать подобную фильтрацию.
В наших командах уже созданы отдельные Kanban-доски для тестировщиков, где выполнена фильтрация по ответственным за выполнение задач и созданы столбцы для отслеживания статусов задач. Эти настройки можно сделать в популярном приложении для управления проектами:
В левом меню проекта выберите «Boards in this project» и созданную Kanban-доску.
Затем в выпадающем списке «Board» выберите «Configure».
Произведите настройки в «Quick Filters» и «Columns».
Задачи можно объединить в общую тему по EpicLink. Это поле, в котором заложена перекрёстная ссылка на Epic задачи более высокого уровня. Для настройки фильтрации:
Перейдите в проект команды.
Выберите «Backlog» в меню.
А рядом с меню — «EPICS».
В раскрытом списке нажмите на значок «+».
В открывшемся окне «Create Epic» заполните поля «Summary» и «Epic Name». Нажмите «Create».
6. Созданный Epic добавится в конец списка, затем отобразится его номер. Нажатием на иконку «…» можно задать цвет заливки названия.
Таким образом мы создали категории приоритетов задач бэклога.
Теперь необходимо сделать отображение названий общих тем и сортировку по ним на доске. Для этого используем Swimlanes — это горизонтальная классификация задач.
Слева в меню выберите «Board in this project» и созданную Kanban-доску.
Затем в выпадающем списке «Board» выберите «Configure».
Слева в меню «Configuration» нажмите на «Swimlanes».
В поле «Name» укажите название приоритета, в поле «JQL» введите запрос «Epic Link» = №, где № — это id созданного ранее Epic. В конце нажмите «Add».
Панель готова.
Получившаяся приоритизация не обязательна — она может быть адаптирована под другие команды и категории задач. Например, как это сделала команда АРМ. ⬇️
Команда АРМ-платформы адаптировала опыт команды ЛК под свои процессы
Квартальные проекты команды АРМ-платформы атомарны, уникальны и бывают продолжительными. Мы решили, что каждый тестировщик может выбрать самый интересный для себя проект и быть ответственным за его автоматизацию. При этом ручное тестирование задач по всем проектам никуда не делось: тестировщики делают его независимо от того, чей проект выбрали для автоматизации. Нам важно сохранять экспертность каждого члена команды.
Мы начали использовать Swimlanes для группировки наших задач под покрытие автотестами квартальных проектов. Каждая панель создана для отдельного проекта, который мы в команде взяли в работу.
Структурирование задач по покрытию фичей автотестами демонстрирует, на каком этапе готовности находятся задачи, связанные с конкретным проектом, — так удобно отслеживать прогресс.
Аналогичным образом сортировка задач будет идти в Swimlanes — по конкретному Epic, созданному специально для автоматизации новой функциональности из квартального проекта.
Кстати, в самой задаче с типом Epic может быть расписан и зафиксирован план на покрытие функциональности автотестами. Также можно добавить обсуждения будущего покрытия сценариев, информацию по блокирующим либо важным техническим моментам и ссылки на документацию к проекту.
Помимо панелей под квартальные проекты, в команде АРМ-платформы выделили следующие панели:
SERV — задачи на написание тест-кейсов и автотестов по ключевым бизнес-процессам.
Блокировки — задачи, предполагающие починку автотестов, которые перестали проходить.
Озеленение — задачи по стабилизации или ускорению автотестов с низким процентом успешных запусков.
Другое — аналитика, задачи на написание документации для тестировщиков, задачи на покрытие определённых кейсов для старых либо новых фич не квартальных проектов и другие.
Пример организации структуры панелей в команде АРМ-платформы:
В итоге Epic и Swimlanes помогают создать доску с отсортированными по приоритету задачами, с понятным и удобным интерфейсом.
Вывод
После приоритизации командам стало намного проще работать с бэклогом. Приоритетные задачи и статус готовности теперь видны не только тестировщикам, но и проектным менеджерам. Мы стали более рационально использовать рабочее время и эффективнее строить приоритеты внутри команд. Работа с бэклогом тестирования стала более прозрачной, а ещё доска может выступать дополнительным аргументом за автоматизацию тестирования.
Надеемся, что наши схемы приоритезации и фильтрации бэклога помогут вам в работе ?
Задавайте свои вопросы в комментариях и откликайтесь на вакансии в отделе тестирования ЮMoney.