Будем честны, регрессионное тестирование — не самая увлекательная часть работы. От спринта к спринту его объем растет, а время на прохождение увеличивается. Но необходимость регресса очевидна — достаточно взглянуть постфактум на все «криты и неотложки», от которых мы уберегли пользователей в своем последнем релизе. Оптимизация (пока вынесем автоматизацию за скобки и вернемся к ней позже) кажется логичным решением, но перспектива пересмотра сотен или тысяч кейсов может отпугнуть.
Меня зовут Михайлов Михаил, я работаю руководителем отдела тестирования в команде Polymatica BI. Недавно мне пришлось привести в порядок регрессионное тестирование, что позволило сделать его компактным и эффективным. Оказалось, что несколько простых действий кратно сократят время, необходимое на приведение в порядок регрессионного прогона. В этой статье разберем пять ключевых шагов.
С чего начать?
Сейчас не открою Америку, но на старте надо проанализировать, где мы сейчас. Правильно заданные вопросы и тщательный сбор ответов на них — инвестиция, которая кратно окупится в обозримом будущем. Приведу несколько ключевых вопросов, которые вы дополните исходя из вашей ситуации и опыта работы.
Классификация кейсов (по критичности, функциональным модулям и т. д.). Как распределены кейсы в регрессионной библиотеке?
Полнота покрытия (какие сценарии есть, а каких не хватает?).
Обновляемость (какие тест‑кейсы устарели или дублируются?).
Это позволит наметить себе конечную цель по всем улучшениям.
На примере Polymatica:
оказалось, что ~ 30% кейсов нам в принципе не нужны, еще небольшой процент пора актуализировать;
по итогу количество кейсов сократилось в два раза и стало оптимальнее;
исходя из того, как мы выстроили проверки, время на прохождение полного регресса стало более гибким — но об этом чуть позже:)
Шаг 1. Mind map: карты не врут
Итак, мы успешно оценили то, что имеем, и, дав волю мечтам, решили, чего хотим. Пришло время сделать первый шаг и вместе с тем обзавестись картой, чтоб в путешествии чувствовать себя намного увереннее.
Mind map — незаменимый инструмент в оптимизации регрессии. Если вы еще не использовали их в тестировании — рекомендую. В двух словах — это визуальное представление приложения и его функциональности в виде блок‑схемы.
Независимо от размеров и сложности проекта (даже если вы знаете продукт досконально), mind map поможет:
выявить слабые места в тестовом покрытии,
наглядно увидеть связи между модулями,
структурировать регрессионные тесты, убрав дубли и неактуальные кейсы.
Я не считаю, что рационально ставить себе цель «зафиксировать на схеме каждый чих», достаточно переноса основных зависимостей, чтоб упростить дальнейшую оптимизацию регресса и (почти наверняка) открыть для себя новые сценарии и кейсы.
Без фанатизма: можно использовать чистую mind map или гибрид с пользовательскими флоу (особенно полезно для тестирования UX). Вести карту постоянно или обновлять раз в несколько спринтов — зависит от динамики изменений в продукте.
В нашей команде используем Figma, но для этой задачи подойдет любой редактор, в котором можно строить блок‑схемы (например, Miro, app.diagrams.net и тд). Поддерживать в актуальном состоянии желательно от релиза к релизу.
Шаг 2. Анализ падений: кто не падал, тот не вставал
Анализ частых падений — один из самых важных этапов оптимизации регрессии. Идея проста: выявляем наиболее проблемные места, которые чаще всего «сыпятся», и адаптируем тестовую стратегию.
Выбираем N прошлых версий (лучше 3–5 последних, но можно варьировать в зависимости от релизного цикла).
Проходимся по каждому регрессионному прогону, фиксируем все проваленные тест‑кейсы.
Падения, встретившееся более одного раза, считаем постоянным и отмечаем у себя, чтобы учесть в дальнейшем.
Дополнительно анализируем пропущенные тест‑кейсы (по тому же принципу) — так вы отсортируете часть неактуальных проверок или проверок, требующих доработки в предисловиях, шагах или где‑то еще.
Регресс — не единственный источник критичных багов, некоторых из них порой обнаруживают заказчики. К таким дефектам применяем тот же подход — берем нужное нам количество версий, рассматриваем каждый из багов, которому не повезло быть обнаруженным и зарепорченным, выводим тенденции, ищем повторяющиеся и все, что хотим фильтровать на своей стороне, и сохраняем для дальнейшей проработки.
Регулярно проводить такой анализ сложно, но даже разовая проверка поможет сделать регресс более точным и эффективным. Анализ частых падений — это маст‑хэв.
В Polymatica мы ведем кейсы в Test‑it и раз в спринт обновляем регресс на основе этого анализа.
Шаг 3. Глубина тестирования: на первый-второй рассчитайсь
Этот шаг является определяющим, поэтому предлагаю подойти к нему немного нестандартно. Представьте, что у нас есть книга «Маленький регресс» — краткая история без лишних деталей, только с ключевым сюжетом. По ней сняли два фильма:
полноценный фильм — расширенная версия книги, с дополнительными деталями и второстепенными персонажами,
ремейк — тот же фильм, но с еще большим количеством нюансов, которые не влияют на сюжет напрямую, но добавляют глубины.
Все это — книга, фильм и ремейк — об одном и том же, только в разном масштабе. Регресс работает так же: нам нужно уметь масштабировать тестирование в зависимости от времени, выделенного на предрелизный прогон. Все еще держите в голове пример из начала абзаца? В таком случае принцип, по которому я предложу разделить кейсы, вас не удивит.
Книга = smoke‑тестирование
Минимальный набор проверок: ключевые пользовательские сценарии и критические функции, без которых продукт просто не может работать. Без пройденного smoke‑прогона релиз не рекомендуется к выпуску.
Фильм = усеченный регресс
Smoke + дополнительные проверки, влияющие на пользовательский опыт (но не критичные для работы системы). Оптимальный баланс между скоростью и качеством.
Ремейк = полный регресс
Все кейсы, которые мы можем пройти за отведенное для этого время (и плюс оставляя хотя бы минимальное пространство для исследовательского тестирования).
Такой подход вместе с переприоритезацией, анализом частых падений и удалением неактуальных тестов (см. предыдущие шаги) поможет из разрозненного набора проверок сформировать структурированный и гибкий регресс‑набор.
Шаг 4. Автоматизация: как встроить в процесс?
Дисклеймер: тема автоматизации вызывает горячие споры. Одни представляют ее как волшебную палочку, которая сделает всю работу за тестировщика. Другие, особенно те, кто уже прошел этот путь, знают: «если где‑то прибыло, значит, где‑то убыло». Давайте оставим эти споры на потом (жду вас в комментариях!), а пока сосредоточимся на конкретике.
На мой взгляд, процент автоматизированных тестов не так важен для оптимизации, ведь в любом случае придется пересмотреть регресс и разделить кейсы на:
уже автоматизированные — их требуется поддерживать в актуальном состоянии;
кандидаты на автоматизацию — сценарии, которые можно проходить вручную, но было бы здорово автоматизировать;
не требующие автоматизации — сложные UX‑кейсы, редкие сценарии, нестабильные области продукта.
Да, это может быть неудобно для команды автотестеров, но актуализация регресса — вынужденная мера, и без нее процесс тестирования будет только усложняться, а потому все неудобства, идущие с ней в комплекте, принимаем как должное.
Автотесты в CI/CD — must‑have. Один из лучших способов оптимизировать регресс — интеграция автоматизированного smoke в CI/CD. Это значит, что ключевые ручки проверяются автоматически после каждого коммита.
Что это дает?
Моментальная обратная связь для разработчиков и тестировщиков.
Быстрое обнаружение критических проблем.
Снижение нагрузки на регрессионное тестирование перед релизом.
Шаг 5. Продолжайте продолжать
Выполнить оптимизацию регресса (особенно, если вы сделали это впервые ) — здорово. Но важно не только разово сформировать подходы по ведению нового регресс‑набора, но и придерживаться их, адаптируя по необходимости. Иначе результат будет напоминать ночной прилив мотивации, после которого весь следующий день хочется спать. Требуется выстроить процесс работы между ручниками и автотестерами, чтобы все понимали, что и в какую очередь будет автоматизировано (или уже автоматизировано), а новые кейсы не остались незамеченными.
Здесь лишь обозначу некоторые моменты, которые мы с командой стараемся держать на контроле, остальное — на ваше усмотрение:
при наличии времени или большого количества критов/падений желательно провести их анализ и учесть в следующем регрессе,
доработать кейсы, которые были отмечены статусом «требует доработки»,
учитывать теги, которые автотестеры оставляют в кейсах,
перед началом регресса или по его завершении нужно подсветить автотестерам кейсы по новым фичам, добавленным в этой версии.
Чем больше растет продукт, тем сложнее его покрытие тестами. В идеальном мире хочется тестировать все. В реальности — ставка делается на стабильную функциональность.
Как видите, дать вторую жизнь своему регрессионному набору на самом деле довольно легко. Пять простых шагов, и корабль, еще недавно лежавший на боку, снова рассекает волны под светом тающих звезд и, поймав попутный ветер, красиво уходит в сторону рассвета, торопясь к горизонту релиза…
За внимание спасибо, остаемся на связи!
