На этой планете время идёт быстрее. Здесь мы и будем тестировать
Привет, Хабр! Меня зовут Вика. В СберТехе я занимаюсь разработкой продукта Platform V Works: Test Data Management (TDM). Инструмент помогает QA генерировать необходимые синтетические тестовые данные по клику, а не обращаться к смежным командам и тратить на это время. Менеджерам TDM помогает сокращать time‑to‑market продуктов, поэтому лететь на другую планету ради тестов больше не придётся. В этом материале я расскажу, как мы поняли, что нам нужен отдельный инструмент для генерации, какие показатели у нас были в начале пути и к чему пришли сейчас. Поехали!
Продуктовый пролог. Вспомнить всё и ещё кое-что
Вспомните ваш последний большой проект. Сколько времени занял цикл тестирования? Здорово, если уложились в час. Иногда числа могут быть совсем грустными, даже когда качество кода хорошее. Например, у одной из наших команд подготовка данных для тестирования релиза занимала два месяца. В энтерпрайзе так бывает, хотя положительные примеры, конечно, тоже есть.
По мере усложнения сервисов время от начала разработки до выпуска релиза может увеличиваться из‑за роста количества проверок. За измерение временного промежутка отвечает метрика Cycle Time — на неё обратили внимание в первую очередь, но нужно идти глубже. В нашей специфике есть большая доля задач, которые приходится делать с определённой периодичностью. Циклично повторяющиеся активности принято делить на приносящие (value added) и не приносящие ценность (non value added).
Активности, которые не приносят ценность, рекомендуется исключить, либо оптимизировать, если исключить нельзя.
Сначала мы опросили тестировщиков в компании. Выяснили, что 20% от общего времени тестирования релиза занимает подготовка тестовых данных. Согласитесь, это внушительная доля.
Какие шаги мы вкладываем в «процесс тестирования»
Генерация тестовых данных.
Актуализация тестовой модели и прохождение кейсов новой функциональности.
Регресс.
При тестировании важно моделировать реальные условия работы продукта и выявлять потенциальные ошибки на ранних этапах, поэтому подготовку тестовых данных убрать из процесса нельзя.
Далее нужно было подтвердить гипотезу о необходимости отдельного инструмента. Мы хотели оптимизировать подготовку тестовых данных, поэтому определили две большие группы респондентов: тестировщики и смежные команды, к которым приходят запросы по подготовке данных от тестировщиков. Мы провели интервью и все проблемы респондентов промаркировали через призму бережливого производства.
Бережливое производство (lean manufacturing) — это концепция управления и оптимизации бизнес‑процессов для максимальной ориентированности на рынок и учета мотивации каждого сотрудника.
Какие виды потерь бывают в концепции бережливого производства
Избыточное производство — лишняя функциональность, которой никто не пользуется, или неэффективные способы работы.
Избыточное ожидание — когда слишком много времени уходит на ожидание решений, ресурсов или информации.
Лишние запасы — аналитика, которая не пошла далее в работу или эксплуатацию.
Транспортировка — передача по производственному процессу с потерями во времени.
Лишние движения людей — суета без полезной работы.
Дефекты — ошибки или несоответствия в продукте или коде.
Ненужная обработка — работа над задачами, которые не ведут к результату или вообще не нужны. Пример over engineering: когда задача уже сделана, но продолжаешь что‑то «допиливать», например, на будущее, на всякий случай.
Нереализованный потенциал сотрудников — недоиспользование специалистов или ограничение в орг. структуре, которое не позволяет специалисту выполнять работу.
Столкновение с бездной пользовательского опыта
Рабочий процесс тестировщика по подготовке тестовых данных включает в себя:
Написание инструкций о подготовке тестовых сущностей: какие данные нужны, в каком объёме, с какими атрибутами, к кому необходимо обратиться за генерацией.
Хранение тестовых данных в командном пространстве для возможности обратиться к ним в любой момент.
Собственные автоматизированные скрипты генерации тестовых данных.
Наденем шапку QA‑специалиста продуктовой команды, которая разрабатывает систему отправки уведомлений клиентам. Задача — протестировать отправку уведомлений. Чтобы начать работу, необходимо получить тестовые данные клиентов с разным набором атрибутов. Например, если у них выбран способ уведомлений «пуши» или «почтовая рассылка».
В нашем примере разберём принцип отправки уведомления — подтверждения принятой заявки на выпуск карты. Тестовые данные, которые нам нужны: банковский клиент с оформленным договором на выпуск карты. Генерация такого типа клиента ранее занимала около одного рабочего дня.
Test Data Management создаёт синтетику (тестовые данные) на тестовом полигоне при помощи ранее заведенных в систему генераторов.
Немного терминов
Тестовый полигон — развёрнутая среда, в которой можно будет проводить интеграционное тестирование системы. Преимущество синтетических тестовых данных в том, что они доступны для обращения из любой системы, которая есть на полигоне. Это позволяет проводить сквозное тестирование.
Генератор — это сущность системы TDM, содержащая в себе логику генерации тестовых данных. Поскольку мы создаем синтетику, генерация осуществляется при помощи обращения в систему, которая является владельцем логики по работе с этими данными.
Когда для подготовки тестовой сущности необходимо обращение в несколько систем, тестировщик может создать цепочку из нескольких генераторов, что обеспечит связность синтетических данных.
На схеме ниже показана цепочка генерации необходимых данных на тестовом полигоне. Это нужно для создания банковского клиента с оформленным договором на выпуск карты и последующего тестирования отправки уведомлений:
Генераторы в этой цепочке полностью автоматизированы. Тестировщику остаётся только сформировать цепочку генерации под свой запрос и нажать на кнопку «Сгенерировать». Внедрение TDM помогло оптимизировать время подготовки таких тестовых данных с одного дня до одного часа.
Согласно концепции бережливого производства, где акцент сделан на рационализацию бизнес‑процессов, при ручной подготовке тестовых данных мы сталкиваемся с тремя видами потерь.
Актуальные виды потерь
№1. Лишние действия тестировщиков
Для тестирования релиза необходимы синтетические данные, которые можно создать при помощи нескольких генераторов, поскольку бизнес‑логика распределена между разными командами. Звеньев в цепи становится больше — растёт общее время генерации данных и трудозатраты тестировщика.
Задача по оформлению карты (по созданному ранее клиенту) требует заполнения около сотни полей, которые ещё предстоит где‑то получить. У тестировщика начинается квест по созданию, поиску доступов и информации по всем необходимым полям.
№2. Долгое ожидание и простои
Из‑за увеличения количества звеньев появляется зависимость от смежных команд: нужно пройти по всему маршруту вручную и убедить людей помочь подготовить данные или выдать доступ.
Время ручной подготовки синтетики сильно возрастало в моменты высокого спроса — мы упирались в физические ограничения смежных команд на обработку всех входящих запросов. Смежные команды вынуждены были вводить SLA.
Кроме этого, мы можем встретиться с нестабильной работой смежных систем: тех. окна, аварии. Можно «нарваться» на невозможность сгенерировать необходимые данные в момент запроса. Так появляется потребность в тщательном планировании периода с учетом возможностей других команд. Это еще одна зависимость и потенциальная точка отказа.
№ 3. Недостаточное раскрытие потенциала сотрудников
Монотонность и ощущение бесконечной повторяемости рабочих задач часто демотивирует сотрудников. Это влияет на качество работы, увеличивает отток кадров, затраты на поиск новых кандидатов и адаптацию.
Отсутствие в автоматизированном CI/CD-конвейере этапа генерации тестовых данных вынуждало тестировщиков тратить из двух недель тестирования около восьми часов на подготовку тестовых данных. Это работа, которая не развивает компетенции сотрудника.
Как Test Data Management борется с потерями и что умеет
Заведение новых генераторов тестовых данных
Инструмент дает возможность командам создавать генераторы тестовых данных для смежных систем — больше не нужно ждать ответов коллег. Для этого необходима информация о входных, выходных параметрах, настройках генератора (например, количество возможной одновременной генерации тестовых данных, если система ограничена по RPS).
Витрина данных как справочник возможных генераторов тестовых данных
Внутри Test Data Management есть собственная витрина данных. Она предоставляет сотрудникам описание генераторов: что именно создаем, какие данные нужны, что получим в итоге. Кроме этого, с TDM мы можем мониторить стабильность генераторов и получать актуальные статусы их доступности: активен, временно недоступен, неактивен.
Мы, как в хранилище, накапливаем инструкции, которые описывают, что система должна сделать в конкретном шаге подготовки тестовых данных. Это помогает сформировать цепочку генерации в нужном виде под запрос тестировщика.
Если необходимого генератора не нашлось, можно оставить запрос на создание нужного.
Компоновка и шаблонизация цепочки генерации тестовых данных
Заведенные в систему генераторы можно связывать между собой, как детали из разных конструкторов. В нашем примере с уведомлениями мы использовали сразу три генератора. Их подключение в последовательную цепочку обеспечивает единый сценарий подготовки тестовых данных.
Предиктивная генерация тестовых данных
Наша система может на основании истории запросов за конкретный период заранее сгенерировать тестовые данные в цикличных задачах. Когда данные понадобятся, тестировщик получит их без задержки. Это ускоряет работу QA и дает уверенность в том, что синтетика всегда в наличии — простоев не будет.
Встраивание в автоматизированный конвейер
С TDM можно взаимодействовать по Public API. После настройки цепочки генерации тестовых данных команда может встроить этап подготовки синтетики в свой CI/CD‑ конвейер.
Заключение
Test Data Management не существует в вакууме, а является частью Platform V Works. Чтобы команды QA работали эффективнее, мы также разработали ряд инструментов для управления сценариями, для нагрузочного тестирования и создания автотестов.
Преимущества от работы с Test Data Management лучше видны на примерах из реалий энтерпрайза, когда подготовка релиза затрагивает сразу несколько команд. Инструмент полезен не только для разработки в банковском сегменте. TDM можно адаптировать под любой сложный пайплайн и избежать упомянутых видов потерь, а также полетов на другие планеты, чтобы выиграть время на подготовке синтетики.
Как мы говорили ранее, внедрение инструмента в среднем сокращает процесс тестирования на 20%. Для нас важен не только факт ускорения time‑to‑market продуктов, но и снижение количества ручных операций. Высвобождение времени наших сотрудников для раскрытия их потенциала. TDM помогает автоматизировать коммуникации со смежными командами и не зависеть от их времени отклика, загруженности и приоритетов.
P.S. Если для вашего процесса тестирования такие проблемы не характерны, расскажите о вашем опыте в комментариях.
