Что пишут в блогах

Подписаться

Онлайн-тренинги

Что пишут в блогах (EN)

Разделы портала

Про инструменты

.
Кто такой кросс-системный тестировщик и почему он не должен быть «agile»?
30.06.2021 00:00

Оригинальная публикация



Методология agile вносит свои правила в процесс тестирования ПО, и каждая команда самостоятельно разрабатывает, проверяет и деплоит свои сервисы. Однако в сложных системах, когда для поддержки бизнес-процесса необходима слаженная работа десятков сервисов, возникает потребность в дополнительном уровне тестирования. Поэтому мы в «М.Видео — Эльдорадо» создали специальный отдел кросс-системного тестирования. О том, как он формировался, чем занимаются кросс-системные тестировщики и каким образом организованы процессы тестирования, читайте здесь.

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


Четыре пилотных проекта

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

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

Чтобы наладить эту работу, было решено запустить ряд пилотных проектов. Первым был проект тестирования промо-акций, которые наши коллеги тестировали на регулярной основе. Этот пилот позволил нам приступить к формированию базы знаний отдела (в Confluence было создано 137 страниц методических рекомендаций), а сотрудники начали работать с типовыми инструкциями — а значит стали более взаимозаменяемыми.



Второй пилотный проект был организован полностью на базе и ролевой модели нового подразделения. Мы тестировали процесс формирования цифровых кодов товаров. Проект под названием Digital Content 2.0 продолжался 5 месяцев. Он затрагивал 15 систем, а для его реализации было разработано 114 тест-кейсов. В ходе этого пилота мы пришли к необходимости централизованного управления тестовыми средами и мастер-данными проектов и у нас была создана группа специалистов, поддерживающих работу всех команд в тестовой среде.



Третий пилотный проект MarketPlace выполнялся уже полностью самостоятельно, без участия подрядчика. Наша команда провела тестирование 15 систем, совместная работа которых позволила реализовать продажу товаров маркетплейса Goods на сайте «М.Видео». Было разработано еще 209 тест-кейсов, но самое главное — мы создали общий верхнеуровневый шаблон процесса кросс-системного тестирования, который можно было использовать на новых проектах.

В ходе MarketPlace мы начали вести тест-кейсы в Jira, собирать в удобной форме отчеты и статистику.



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

Четвертый пилот, после которого наша работа перешла в новое качество — это тестирование мобильного приложения «Эльдорадо». Тестирование под названием Eldo Mobile стало продуктовым — то есть его заказчиком выступил не Projet Manager, а Product Owner. И хотя на этапе трехмесячного пилота мы протестировали только 16 связанных систем, новый подход позволил спланировать кросс-системное тестирование для каждого нового релиза мобильного приложения.

Работа подразделения кросс-системного тестирования сегодня


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



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

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

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

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

Качества кросс-системного тестировщика

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

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

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

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

Наконец, тестовая среда может оказаться перегруженной. Поэтому тест-менеджеры сами должны быть крепкими PM и справляться с планированием буквально «на лету».

Тестирование продуктов

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

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

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

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

Результаты работы нового подразделения

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

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

Новая методика добавила прозрачности в работу всех команд и позволила повысить QA. Непрерывное накопление экспертизы и кросс-системная аналитика позволяют все более точно прогнозировать, какие изменения в одних системах могут повлиять на работу других систем.

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

P.S. Наша команда расширяется. Нам нужны талантливые тестировщики. Если вы такой, добро пожаловать на борт!

Обсудить в форуме