Привет! Меня зовут Евгения Воропаева. Я занимаюсь тестированием в PIMS-команде СберМаркета. Мы разрабатываем внутреннюю систему для отдела контента и производства. Проект существует уже 2,5 года и за это время PIMS рос и развивался, приходили и уходили люди, менялись подходы к работе, внедрялись новые практики. Методом проб и ошибок мы выстроили процессы в команде тестирования, которые считаем оптимальными. Хочу поделиться результатом, к которому мы пришли и надеюсь, наш опыт будет вам полезен.
Что такое PIMS?
Для начала хочется рассказать, что такое PIMS. Кому-то эта аббревиатура может быть знакома благодаря модному чайному напитку, который можно найти в одноимёном кафе в Москве. Но в нашем случае PIMS или Product information management system — это система для централизованного управления большими массивами данных о товарах.
В СберМаркете PIMS — это инструмент для создания контента: карточек товаров, каталога категорий, фильтров и справочников для создания контента.
Мы создаем функциональность, которая экономит время, деньги и ускоряет работу наших коллег из отдела контента. Достигается это через следующий функционал:
PIMS DOCS (замена Excel и Google Sheets) — программа с помощью которой заводятся карточки товаров в табличной форме.
Автомэтчинг офферов и товаров. Нейросеть находит товар, подходящий офферу. Например ищет воду «Святой источник. Негазированная» среди других товаров.
Автокатегоризация офферов. Нейросеть определяет, к какой категории относится оффер. Например, относит воду «Святой источник. Негазированная» к категории «Вода питьевая», а не «Вода газированная» или «Соки и нектары».
Автогруппировка офферов. Нейросеть группирует одинаковые офферы от разных ритейлеров.
Оценка стоимости выполненной работы. Алгоритмы рассчитывают выплаты подрядчикам, что приводит к 1 часу в день экономии времени руководителя команды контент-менеджеров.
Сейчас в СберМаркете 2,6 миллионов товаров и 13 500 категорий, которые обрабатываются через созданные нами системы. Так что объём задач, на котором мы учились выстраивать процессы — приличный :)
Процессы в кросс-функциональной команде PIMS
Перед тем как перейти к описанию процессов, которые мы построили в тестировании, дам небольшой обзор общего флоу:
Разработка происходит итерационно, обновления поставляются через версии.
Бизнес-требования и функциональные требования описываются аналитиком.
Реализация требований происходит силами дизайнера, frontend-разработчика, backend-разработчика и тестировщика.
Подготовка версии к выпуску и деплою происходит силами релиз-инженера (backend-разработчика) и тестировщика.
Мы работаем по Scrum. Для оценки задач используем стори поинты от 1 до 21, а задачи размещаем на Scrum-доске. Для таск-трекинга используем Jira. Колонок на доске много, быстро пробежимся по каждой из них:
Backlog содержит список задач, который необходимо сделать для создания или улучшения продукта.
To Do содержит задачи, которые необходимо сделать в ближайший спринт.
In Progress — задачи в разработке.
CR (Code Review) — процесс проверки и анализа кода другим разработчиком.
Need Fixing — в эту колонку попадают задачи, требующие устранения ошибок.
Ready For Test — задачи, готовые к тестированию.
In Testing — задачи, проходящие процесс тестирования.
Acceptance — задачи, требующие дополнительной приемки. Как правило приемка проводится аналитиком, дизайнером или продакт-менеджером и носит опциональный характер.
Ready For Release — задачи, готовые к релизу (то есть прошедшие этапы разработки, тестирования и приемки).
In Release — задачи, участвующие в регрессе.
Done содержит задачи из In Release, прошедшие регрессионное тестирование и выложенные на продакшн.
Итак, тестирование в PIMS
В тестировании мы работаем с задачами на этапах Ready for Test, In Testing, Ready For Release и In Release. Каждый этап имеет свои лимиты на максимально допустимое количество задач — так называемую «зеленую зону», которая говорит нам о том, что процесс разработки идет оптимально. Когда задачи накапливаются, и их становится больше чем допустимо, колонки загораются красным цветом — это сигнал, что нужно разгребать завал. «Гореть» может как одна колонка, так и несколько одновременно.
В тестирование попадают разные задачи: баги, проверка функционала новых фич, написание автотестов или составление документации. Задачи делятся на четыре блока:
В «Major» входят задачи, содержащие ошибки системы, которые блокируют часть процессов и воспроизводятся больше чем у одного пользователя. Как правило, сюда относятся ошибки с продакшена, требующие незамедлительного исправления.
«Цели спринта». Раз в спринт лидеры команд собираются на планирование, где фиксируют цели предстоящего спринта, чтобы вся команда понимала, какой инкремент по итогу должен получить продукт. Если нет задач в блоке «Major», то разработчик берет задачу из данного блока и движется сверху вниз.
В блок «Else» входят любые задачи из общего бэклога. Как правило это техдолг: задачи на RND, оптимизацию работы системы и баги.
В блок «QA» входят внутренние задачи тестировщиков (написание тестовой
документации, работа с автотестами). Берем в работу после завершения тестирования задач из блоков «Major», «Цели спринта» и «Else».
Документацию мы ведем в отдельном пространстве PIMS в Confluence. Там мы описываем работу с тикетами, инструкции по написанию баг-репортов, рекомендации по написанию тест-кейсов, отчеты по регрессам, инструкции по E2E тестам и прочее.
Непосредственное написание кейсов, тест-планов, а также запуск тест-ранов происходит в TMS Qase (удобная платформа для управления тестированием). Описанные тест-кейсы отправляем на ревью друг другу. Здесь нет четких правил: кто свободен, тот и смотрит. Если задачи на ревью скапливаются, можем тегнуть друг друга в рабочем чате, но, как правило, процесс ревью проходит быстро. После приемки одним из коллег мерджим описанный тест-кейс в основной тест-план и заводим в Jira задачу на автоматизацию.
Основной функционал нашего продукта автоматизирован как на стороне backend (unit-тестами), так и на стороне UI (E2E тестами):
Unit-тесты пишутся разработчиками в процессе выполнения задачи.
E2E тесты пишутся тестировщиками, как правило, после выпуска функционала. Список E2E тестов постоянно расширяется.
Когда задача протестирована и готова к набору в релиз, релиз-инженер в паре с дежурным тестировщиком набирают релиз-кандидат для регресса.
Как мы пришли к ежедневной релизной схеме?
Раньше регрессы проводились 2-3 раза в неделю и количество задач было достаточно большим. В регрессе участвовали 2-3 тестировщика и каждый тратил на регресс 1,5-2 дня, поскольку тест-ран был один и содержал большое количество ручных и автоматизированных тест-кейсов, которые также требовали ручной проверки в случае fail.
У этого подхода были проблемы:
Помимо временных затрат, были проблемы с простоями задач. Так, пока тестировщики участвовали в регрессе, задачи не тестировались, при этом разработка продолжалась, и в колонке «Ready for Test» могло скапливаться большое количество задач.
Готовые задачи, не попавшие в релиз-кандидат, также ждали своей очереди. Когда их включали, задачам требовался ребейз, который отнимал достаточно много времени у разработчиков. И метрика time to market (доставки фичи до прода) страдала.
Поэтому мы решили попробовать другую схему: начали выпускать задачи небольшими партиями и отводить на регресс системы время одного тестировщика.
На внедрение нового подхода к регрессу и обкатывание схемы ушло несколько недель. Также в ходе эксперимента был изменен подход к ручным тестам, которые проверялись каждый регресс. Вместо одного общего тест-рана появилось три: с backend, E2E и ручными тестами.
Backend и UI тесты стали запускаться в момент выкладки релиз-кандидата на тестовый стенд.
Ручной тест-ран представляет собой чек-лист проверок, которые затрагивают функционал, не требующий проверки каждый регресс. Поэтому ручной тест-ран создается не всегда, а только в том случае, если задачи, включенные в релиз-кандидат, могут его затронуть.
Как правило в релиз-кандидат включаются 2-3 средние задачи или до 5 мелких. При наборе тестировщик видит список задач, может оценить риски и сформировать версию исходя из того, что успеет протестировать за 1 день.
По окончании регресса дежурный тестировщик пишет отчет:
набор задач, участвующих в регрессе;
мердж реквест и версию актуального тега;
набор найденных багов;
ссылки на тест-раны;
релиз ноутс.
Для удобства членов команды был составлен график дежурств релиз-инженеров и дежурных тестировщиков, чтобы каждый понимал, когда настанет его очередь и кто ответственный.
Результаты
До внедрения новой релизной схемы жизненный цикл задачи был достаточно велик и достигал в некоторых случаях 30-45 дней, что негативно сказывалось на точности прогнозирования и оценке сроков выполнения задач. Теперь точность прогнозирования увеличилась: мы точно можем сказать, успеем или нет сделать фичу за двухнедельный спринт.
Медианное значение выполнения задачи сократилось до 4 дней (от момента разработки до статуса «Выполнена», то есть до выпуска в продакшен). Соответственно, и увеличилась скорость доставки ценности в бизнес.
На старте у нас было много опасений:
Как ежедневные регрессы скажутся на общей эффективности команды тестирования?
Не будет ли выгорания усталости от частых регрессов?
Справится ли один тестировщик с задачей, ведь повышается уровень ответственности и появляется страх, что можно что-то упустить?
Но в ходе экспериментальных недель мы выяснили, что новые процессы не влияют на качество работы и на общее настроение в команде. Мы сохранили возможность поменяться очередностью с коллегой или попросить о помощи включиться в регресс. Для нашей команды данная схема оказалась оптимальной.
Надеюсь, наши наработки окажутся для вас полезными и вы утащите себе какие-то из наших практик. Если будут вопросы — стучитесь в личку или пишите комментарии. Буду рада ответить на все возникшие вопросы!
Tech-команда СберМаркета завела соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.