Подписаться
Читать в телеграм
С какими проблемами могут столкнуться разработчики при использовании Scrum?
Что дает формализация тестов?
Как анализ работы с дефектами позволяет ускорить выпуск релизов?
Начало проекта
Наш совместный с «М.Видео» проект по модернизации разработки ПО для интернет-магазина ритейлера стартовал 2 года назад. Причин для его запуска было несколько.
Во-первых, использовавшаяся на тот момент методология Scrum подразумевала работу по модели спринт. Командам разработки приходилось ждать, пока все закончат свою часть продукта, — только после этого можно было запускать тесты.
Во-вторых, тестирование проводилось на основе таблиц, в которые заносились параметры действий или данных, а также ожидаемый и фактический результаты. Заполнять таблицы приходилось вручную, и время тестирования растягивалось.
Кроме того, тестировщики писали тесты без единообразной структуры, поэтому провести проверку мог только тот, кто ее подготовил. В итоге работа отдела зависела от действий конкретного сотрудника.
Наконец, взаимодействие между разными командами и подрядчиками не было регламентировано: единой схемы приемки работы не существовало, поэтому новые релизы порой «простаивали» до трех дней, прежде чем их интегрировали в структуру интернет-магазина.
Переход на подходящую методологию
Главным этапом, трансформировавшим процесс разработки, стал переход со Scrum на Kanban. Изменение методологии позволило нам экономить в среднем 3 дня при выполнении регрессионного тестирования. Раньше тесты, необходимые для выпуска релиз-кандидата, запускались лишь после того, как все 5 команд сдавали результаты работы. На практике после получения результатов еще 2–3 дня уходило на стабилизацию мастер-ветки и решение конфликтов.
Автоматизация тестирования
Вторым шагом в процессе модернизации разработки стала автоматизация тестирования. Всего было создано около 900 сценариев проверки работоспособности сайта, они запускались один за другим. Чтобы оптимизировать тестирование, мы сгруппировали эти сценарии по приоритетности.
Блокеры — это сценарии, которые должны работать при любых обстоятельствах, даже если случилась авария. Они обеспечивают базовые функции интернет-магазина «М.Видео». В числе блокеров — механизмы покупки товаров, применение скидок, авторизация, регистрация пользователей.
Критически важными считаются еще около 300 сценариев — например, возможность выбирать товары с помощью фильтров. Работу таких функций нужно строго контролировать, так как дефекты в итоге приводят к потере пользователей.
Мейджор-сценарии включают множество неполадок разной степени важности для пользователя. Например, к категории мейджор относятся корректность верстки и отображения форм и т.д.
Минор-сценарии содержат функции, отсутствие которых посетитель может не заметить. В их число входят описания специальных акций, автоподсказки к паролям в личном кабинете.
В первую очередь мы занимались блокерами и критически важными сценариями. В ходе проекта удалось автоматизировать 95% блокеров, а уровень автоматизации остальных сценариев достиг примерно 50%. С чем это связано? Дело в том, что иногда встречаются сценарии, не поддающиеся автоматизации или требующие большой подготовительной работы. Например, это возможность позвонить в банк и отменить заявку на кредит, необходимость связаться с отделом продаж и отменить заказы. Такие действия сложно полностью автоматизировать.
Автоматизация коснулась не только регрессионных тестов, проводимых после финальной сборки компонентов. Она затронула и smoke-тесты, которые проводятся для блокеров после каждого объединения разработок разных команд с основной веткой. Суммарная экономия времени составила несколько дней.
Формализация тестов
Чтобы упростить подготовку к тестированию, сценарии перевели из табличной формы в нотацию Gherkin. Этот подход позволяет прогонять тесты вне зависимости от конкретных данных, а также помогает новому тестировщику брать любые работы, так как все тесты представлены в едином формате.
Это очень важно, потому что над проектом работают 5 команд, в каждой — минимум 2 тестировщика. Раньше каждый из них писал тесты в свободном формате и мог поддерживать только свои сценарии. Переход на Gherkin помог перевести на язык скриптов большинство сценариев и создать базовые элементы, такие как «авторизация», «корзина», «оплата». Теперь тестировщики могут собирать сценарии как конструктор. Это экономит время, ведь новые сценарии создаются не с нуля, а на базе уже готовых блоков, представленных в виде автотестов.
Проверка связей
Еще один элемент автоматизации, который позволил нам экономить ресурсы и время, — выделение функциональных блоков. Связав модули, которые могут влиять друг на друга, мы выделили тесты в функциональные блоки. Это позволяет исключить ситуации, когда добавление функциональности, скажем, в клиентской части приводит к сбоям в другой сфере — например, в бизнес-системах.
Наличие функциональных блоков, таких как «личный кабинет», «покупка», «каталог», помогает автоматически подбирать тесты для проверки связанных модулей после каждого обновления. Разработчики получили возможность проверять после объединения с мастер-веткой работу не только блокеров, но и предметных сценариев, в которые вносятся изменения.
Кроме того, стало проще поддерживать тесты. Например, если что-то поменялось в личном кабинете либо в процедурах оформления заказа и доставки, не нужно перетряхивать всю регрессионную модель — функциональные блоки позволяют сразу увидеть элементы, которых коснулись изменения. Благодаря этому сократились затраты на поддержание тестового набора в актуальном состоянии.
Отдельная проверка стендов
Возможность проверять работоспособность стендов стала еще одним аргументом в пользу автоматизации. Раньше после нескольких часов прогонки регрессионных тестов могло оказаться, что стенд находится в неработоспособном состоянии. В результате дополнительное время уходило на отладку и повторные прогоны.
Для решения этой задачи было подготовлено 15 API-тестов, проверяющих конфигурацию стендов. Такие тесты не связаны с функциональностью и не зависят от версии сборки, их назначение — проверить интеграционные точки, критически важные для прохождения сценариев.
Предварительное тестирование позволило существенно сэкономить время, потому что в сценарии входят тесты, требующие от специалиста многочасовой работы. Когда тесты, состоящие, например, из 150 шагов, запускаются на нерабочем стенде, временные потери колоссальны.
Отслеживание жизненного цикла дефектов
В процессе автоматизации тестирования был создан механизм отслеживания жизненного цикла любого дефекта. Это помогло ускорить выпуск релизов.
Процесс работы над каждым дефектом выглядит так: нашли инцидент, взяли его в работу, завершили ее, передали на тестирование, протестировали, закрыли.
Сценарий, обнаруживающий критические дефекты, после анализа добавляется в регрессионный набор. Таким образом обеспечивается моментальная обратная связь для получения информации о состоянии продуктива или пилота. А добавление сценария проверки по дефекту значительно экономит время тестировщиков.
Наряду с этим мы стали отслеживать эффективность работы в ретроспективе, составив таблицу, в которой указывались номер релиза, число дефектов, блокеров и других сценариев, а также количество успешных исправлений (резолюций).
Количество невалидных резолюций показывает эффективность работы. Например, если 15 из 40 дефектов невалидны, значит, тестировщики впустую тратят не только свое время, но и время разработчиков, занимающихся исправлениями. После анализа ситуации была внедрена и признана успешной процедура ревизии багов более опытными тестировщиками перед отправкой в разработку.
Сейчас эффективность работы отдела оценивается непрерывно. Все дефекты анализируются сразу; если это технически возможно, каждый новый тест регулярно запускается в автоматическом режиме.
Взаимодействие и наставничество
Глубокий ретроспективный анализ тестирования также помог выявить нехватку компетенций и улучшить качество подготовки специалистов. С этой целью мы ввели систему оценки знаний сотрудников по теории и проекту.
В дополнение к этому потребовалось оптимизировать кадровые процессы, поскольку с внедрением средств автоматизации изменилась структура команд разработчиков (например, число команд увеличилось с 5 до 7), а также появилась новая локация для сотрудников.
Расписанный по дням план адаптации нового сотрудника помог сэкономить несколько дней при подготовке специалистов перед включением их в процесс тестирования или разработки. Среди прочего были формализованы практика наставничества и принципы поддержки регулярной обратной связи по прохождению каждого этапа подготовки.
Результаты проекта
Изначально перед проектом стояли задачи по увеличению частоты релизов и сокращению числа дефектов, но итоги превзошли наши ожидания.
Выстроенный процесс автоматизации дал возможность нарастить количество автоматизированных тестов, а постоянный анализ дефектов позволил командам разработки и тестирования оптимально расставить приоритеты и ускорить создание тестовых сценариев.
Если говорить о цифрах, то через 2 года длительность регрессионных тестов сократилась с 10 до 4 дней, состав команды ручного тестирования уменьшился на 50%, а время выхода новых функций на сайте сократилось с 30–35 до 25 дней.
