Сайт находится в состоянии доработки. Извиняемся за неудобства.

x
© 1995-2020 Компания «Инфосистемы Джет»
№5-6 (297) / 2019
Программное обеспечение

Как ускорить Time-to-Market с помощью автоматизации тестирования: опыт «М.Видео»

Автор
Александр Садыков Начальник отдела тестирования компании "Инфосистемы Джет"

337

0

12

0

3

С какими проблемами могут столкнуться разработчики при использовании Scrum?

 

Что дает формализация тестов?

 

Как анализ работы с дефектами позволяет ускорить выпуск релизов?

 

 

Начало проекта

 

Наш совместный с «М.Видео» проект по модернизации разработки ПО для интернет-магазина ритейлера стартовал 2 года назад. Причин для его запуска было несколько.

 

Во-первых, использовавшаяся на тот момент методология Scrum подразумевала работу по модели спринт. Командам разработки приходилось ждать, пока все закончат свою часть продукта, — только после этого можно было запускать тесты.

 

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

 

Кроме того, тестировщики писали тесты без единообразной структуры, поэтому провести проверку мог только тот, кто ее подготовил. В итоге работа отдела зависела от действий конкретного сотрудника.

 

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

Переход на подходящую методологию

 

Главным этапом, трансформировавшим процесс разработки, стал переход со Scrum на Kanban. Изменение методологии позволило нам экономить в среднем 3 дня при выполнении регрессионного тестирования. Раньше тесты, необходимые для выпуска релиз-кандидата, запускались лишь после того, как все 5 команд сдавали результаты работы. На практике после получения результатов еще 2–3 дня уходило на стабилизацию мастер-ветки и решение конфликтов.

Автоматизация тестирования

 

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

 

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

 

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

 

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

 

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

 

В первую очередь мы занимались блокерами и критически важными сценариями. В ходе проекта удалось автоматизировать 95% блокеров, а уровень автоматизации остальных сценариев достиг примерно 50%. С чем это связано? Дело в том, что иногда встречаются сценарии, не поддающиеся автоматизации или требующие большой подготовительной работы. Например, это возможность позвонить в банк и отменить заявку на кредит, необходимость связаться с отделом продаж и отменить заказы. Такие действия сложно полностью автоматизировать.

 

Автоматизация коснулась не только регрессионных тестов, проводимых после финальной сборки компонентов. Она затронула и smoke-тесты, которые проводятся для блокеров после каждого объединения разработок разных команд с основной веткой. Суммарная экономия времени составила несколько дней.

График 1. Регрессионные тесты

Формализация тестов

 

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

 

Это очень важно, потому что над проектом работают 5 команд, в каждой — минимум 2 тестировщика. Раньше каждый из них писал тесты в свободном формате и мог поддерживать только свои сценарии. Переход на Gherkin помог перевести на язык скриптов большинство сценариев и создать базовые элементы, такие как «авторизация», «корзина», «оплата». Теперь тестировщики могут собирать сценарии как конструктор. Это экономит время, ведь новые сценарии создаются не с нуля, а на базе уже готовых блоков, представленных в виде автотестов.

Проверка связей

 

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

 

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

 

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

Отдельная проверка стендов

 

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

 

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

 

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

Отслеживание жизненного цикла дефектов

 

В процессе автоматизации тестирования был создан механизм отслеживания жизненного цикла любого дефекта. Это помогло ускорить выпуск релизов.

 

Процесс работы над каждым дефектом выглядит так: нашли инцидент, взяли его в работу, завершили ее, передали на тестирование, протестировали, закрыли.

График 2. Типичный жизненный цикл дефекта

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

График 3. Модицифицированный жизненный цикл дефекта

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

 

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

 

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

Взаимодействие и наставничество

 

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

 

В дополнение к этому потребовалось оптимизировать кадровые процессы, поскольку с внедрением средств автоматизации изменилась структура команд разработчиков (например, число команд увеличилось с 5 до 7), а также появилась новая локация для сотрудников.

 

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

Результаты проекта

 

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

 

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

 

Если говорить о цифрах, то через 2 года длительность регрессионных тестов сократилась с 10 до 4 дней, состав команды ручного тестирования уменьшился на 50%, а время выхода новых функций на сайте сократилось с 30–35 до 25 дней.

Следите за нашими обновлениями

Кластерные СУБД

Причем, если раньше кластеризация БД имела целью, прежде всего, создание высоконадежной и отказоустойчивой системы, то теперь, наряду с требованиями к надежности, все чаще преследуются цели распределения нагрузки по серверам, повышения производительности и масштабируемости систем, создания специализированных информационных «решеток» (grid) для параллельной обработки баз данных.

Как изменится ритейл в 2020 году

Какие тренды характерны для отечественного ритейла, и как мировые гиганты справляются с вызовами рынка

Обзор решений по защите от таргетированных атак

Обзор представляет решения Anti-APT от ведущих производителей: FireEye, Trend Micro Deep Discovery, Check Point SandBlast, Kaspersky Anti Targeted Attack Platform (KATA)

Спасибо!
Ваш материал отправлен.
Мы с вами свяжемся
Предложить
авторский материал
Спасибо!
Вы подписались на обновления наших статей
Подписаться
на рубрику






Спасибо!
Вы подписались на обновления наших статей
Оформить
подписку на журнал







Спасибо!
Вы подписались на обновления наших статей
Оформить
подписку на новости







Спасибо!
Вы подписались на наши новости.
Оформить
подписку на Новости
Спасибо!
Ваша заявка отправлена.
Мы с вами скоро свяжемся.
Задать вопрос
редактору

Оставить заявку

Мы всегда рады ответить на любые Ваши вопросы

* Обязательные поля для заполнения

Спасибо!

Благодарим за обращение. Ваша заявка принята

Наш специалист свяжется с Вами в течение рабочего дня