Почему мы решили создать отдел кросс-системного тестирования

yeibjnihq-nbv6kv9dc1qggxooe.png

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

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

2ytw6tkq7dtwzrybptmvs70geuc.png

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

Поэтому интеграционные тесты уже не гарантируют безошибочной работы. Приведем пример: когда разработчики мобильного приложения выпускают релиз то, как максимум, выполняется проверка его совместимости с Bitrix (на котором работает сайт Эльдорадо). Это позволяет оценить работу только самого сервиса, но не дает никакой гарантии, что заказы будут выполнены, товары — предоставлены покупателям, а цены на выдаче будут соответствовать ценам в приложении и так далее.

На самом деле сложные процессы — это современная норма. Например, в М.Видео и Эльдорадо оформление онлайн-заказа требует участия 20+ систем. Со стороны клиента все выглядит просто: покупатель просто заходит в мобильное приложение или на сайт интернет-магазина, подбирает товар, кладет его в корзину и назначает доставку на ближайшую удобную ему дату. Курьер привозит товар в обозначенное покупателем время по указанному адресу.

nsydksxy1dksnvp8o0tly7rqyyw.png

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

Нужны ли отдельные тестировщики для кросс-системных тестов?


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

После выполнения своего этапа тестировщик N должен отчитаться тестировщику N+1 о том, что его этап выполнен. ребята обычно заняты своими делами — функциональными и интеграционными тестами, и процесс кросс-системного тестирования идет медленно.

o6chdhmbgmqncupfxn86iv8fte0.png

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

Если мы обнаруживаем на каком-то этапе проблему, то сразу возникает вопрос: «На чьей она стороне?». Например, тестировщик N+1 возвращает предыдущему специалисту ошибку. А тестировщик N возмущается: «При чем тут я и наша система?». Пока ребята разберутся, на чьей стороне возникла проблема, которую они искренне не считают «своей», может пройти несколько дней. В результате — сорванные сроки и необходимость постоянно пушить процесс.

dixqpllvbsu7ofbp4mufs-48p8o.png

Наконец, чтобы провести такой тест нужно запускать проект, подключать Project менеджера, периодически собрать в одном помещении 20 человек (по одному на каждую систему) и разбираться, в на чьей стороне возникает проблема при совершении очередного шага. Это очень трудозатратно, неэффективно и отрывает людей от работы, которую они небезосновательно считают основной.

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

Собственный опыт — ПРОМО-акции


Когда мы решились на это, большим плюсом стало наличие внутреннего опыта по кросс-системному тестированию. Еще в 2017 году мы начали внедрять новую практику сквозного тестирования, чтобы поддержать федеральные рекламные кампании бренда М.Видео. Компания постоянно проводит разные акции, например, «Твоя цена», «Купи телевизор, получишь подарок» и так далее.

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

2err4oxejey6pg3fjt3gtueomfm.png

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

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

Когда мы поняли, что компании необходим процесс полноценного кросс-системного тестирования и на других проектах, этот опыт оказался очень полезным. Особенно четко потребность в новом виде тестов прорисовалась в момент объединения М.Видео и Эльдорадо. У нас увеличилось количество комплексных и объемных изменений, возникла необходимость вести проекты сразу для двух брендов, количество продуктов и бэк-офисных систем, включенных в одно изменение, стало превышать 20.

Преимущества нового подхода


На сегодняшний день в департаменте кросс-системного тестирования работает три тест-менеджера и шесть тестировщиков, а в перспективе мы планируем на постоянной основе задействовать в кросс-системном тестировании для М.Видео-Эльдорадо порядка 40 человек.

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

jhwuqctpegjyg-aedx_yhqdielo.png

К середине 2021 года М.Видео-Эльдорадо поддерживает уже более 100+ продуктов и бэк-офисных систем/сервисов, и, соответственно, их развитием занимается 100+ команд. С каждой неделей программных компонентов становится все больше (все же мы живем в эпоху микросервисов), и изменения становятся практически непрерывными. В компании постоянно идет 5–6 масштабных проектов, влияющих сразу на десятки систем.

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

Если говорить о конкретных показателях, то нам удалось:

  • Повысить скорость подготовки тестовой среды, мастер-данных, тест-кейсов end2end практически в 2 раза;
  • Достичь роста качества тестирования на 15%;
  • Сократить расхождение планируемых и фактических затрат на разработку 20%;
  • Уменьшить трудозатраты на end2end тестирование на 10%;
  • Поднять взаимозаменяемость тестировщиков отдела на 50%;
  • Организовать централизованную систему управления подготовкой тестовой среды, прохождения тест-кейсов, работы с проблемами и дефектами в Jira

wvqqovitpwcfjscwmfj5c6rs91q.png

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

© Habrahabr.ru