Помню, как несколько лет назад на собеседовании, когда я ещё была, считай, новичком в тестировании, меня спросили: «Что делать, если до релиза остался день, а полная регрессия занимает три?»
Точно помню, что тогда я прекрасно поняла, что собеседующий хочет проверить не знание определения, а ход моих размышлений. Но с ходом размышлений случилась проблема.
Проекты, на которых я работала раньше, были маленькие. Регрессии в классическом смысле у нас вообще не проходились, поэтому что отвечать было непонятно. Конечно, я сказала, что нужно начать с самых критичных сценариев и привлечь разработку к тестированию, но в целом ответ я завалила. И с тех пор часто возвращалась к мысли: каким же должен был быть эталонный ответ?
В этой статье попробую, наконец, нормально ответить на тот самый вопрос :)
Почему ответ был неполный
Сам по себе ответ «начать с критичных сценариев» звучит вполне разумно, но дает мало чего полезного для проверки хода рассуждений. Что такое критичные проверки? Те, где чаще всего ходят пользователи? Те, где затрагиваются деньги? Те, где менялся функционал, или те, которые раньше чаще ломались?
Проблема не в том, что ответ неверный, а в том, что он слишком общий. В реальной работе мы руководствуемся порядком выбора. То есть приоритизацией.
Критерии изменения порядка регрессионных тестов, которые дают ранние сигналы о дефектах
Проверки, которые находят баги быстрее
Главная цель приоритизации — это повышение скорости обнаружения дефектов. То есть нам в первую очередь важно не просто найти ошибки когда‑нибудь в процессе, а сделать это как можно быстрее, потому что в таком случае у нас останется больше времени на исправления.
Откидываем второстепенные сценарии, проходимся по основным пользовательским путям, авторизации, оплатам, подаче заявок и так далее.
Проверки, которые связаны с изменениями
Даже если речь идет о регрессии, мы не должны привычно идти сверху вниз от старого списка. Первыми должны идти проверки, которые связаны с функционалом, вошедшим в новую версию релиза.
Лучше двигаться от проверок на прямую область изменений к проверкам сценариев, которые она затрагивает (то есть найти пользовательские пути вокруг изменений), уточнить, были ли изменения в данных, правах, интеграциях и в других зонах с высокой ценой ошибки, обязательно уточнить у разработчиков, что именно они сами считают рискованным.
Проверки с бОльшим покрытием
Если говорить про автотесты, существуют техники, где тесты упорядочиваются по покрытию компонентов кода. То есть первыми мы запускаем те тесты, которые проходят через большее количество участков.
Для ручной регрессии это адаптируется как покрытие пользовательского пути. Если один сценарий проходит через несколько важных частей системы, он выше в очереди, чем узкая проверка одного второстепенного элемента.
Проверки, которые дают новое покрытие
Отдельной идеей стоит рассмотреть так называемое дополнительное покрытие. После какого‑то количества выполненных тестов стоит выбрать следующий не просто с бОльшим общим покрытием, а тот, который добавит проверку на участки, которые еще ни разу не проверялись.
Также при сокращённой регрессии важно не застрять в одной зоне только потому, что она знакомая и быстро проверяется. Например, если вы уже проверили вход, профиль, сохранение телефона и создание заявки из профиля, похожие варианты сохранения профиля проверять менее полезно, чем условную оплату/заказ/отправку письма и так далее
Проверки, учитывающие историю прошлых дефектов
Если исторически какая‑то область функционала у вас имеет бОльшую склонность к отказам и регулярно ломается после внесения изменений, в регрессии нужно поднять ее выше. Это хороший критерий, который является нормальным источником приоритета, потому что он основан не на ощущениях, а на истории продукта.
Проверки, учитывающие частоту использования функционала
Если пользователи чаще пользуются какой‑то фичей, проверки ее функционала должны стоять выше, чем той фичи, которая используется реже.
Но здесь важна поправка: частота использования — не единственный критерий. Редкий сценарий с высоким риском может быть важнее частого, но безобидного.
Что еще?
Можно подумать, что мы противопоставляем приоритизацию выбору и минимизации тест‑набора. Во втором варианте часть тестов фактически убирается, это может снизить способность набора находить дефекты. Приоритизация мягче, мы не удаляем тесты, а переставляем их местами.
Сокращенная регрессия не означает, что остальные проверки стали ненужными.
Мы понимаем, что все проверки важны, но в условиях ограниченного времени сначала проверяем зоны с более высоким риском.
Особенно полезна приоритизация, если регресс может быть неожиданно остановлен. В таком случае первые часы должны быть самыми полезными, и тогда выше шанс, что уже потраченное время использовали лучше, чем при случайном порядке проверок.
Первые часы должны закрывать самые рискованные зоны.
Небольшая оговорка: стоимость самой приоритизации тоже важна. Если полный набор тестов короткий, сложная приоритизация может быть невыгодной, проще выполнить все.
Если же набор длинный, приоритизация становится полезной, потому что раннее достижение целей тестирования даёт реальную пользу.
Как это применить на практике
Итак, сначала необходимо понять, что именно вошло в релиз. Какие задачи вошли в версию, какие сценарии они затрагивают, были ли изменения в данных, правах, оплате, интеграциях, отчётах, какие баги исправляли и что сами разработчики считают рискованным.
Дальше из этого собирается короткий порядок проверок.
Например, у нас есть личный кабинет. В релиз вошли:
Что вошло в релиз | Что проверяем в первую очередь | Почему |
|---|---|---|
Изменили возврат после оплаты | Успешная оплата, возврат на сайт, создание заказа | Затронуты деньги и заказ, цена ошибки высокая |
Исправили создание заявки | Заявка создаётся, видна пользователю и менеджеру | Нельзя потерять обращение пользователя |
Обновили форму профиля | Сохранение данных, обязательные поля, старые данные не затираются | Риск потери или искажения пользовательских данных |
Профиль используется в заявке | Заявка создаётся с актуальными данными профиля | Проверяем не только экран, но и путь данных дальше |
Обновили отчёт по заказам | Итоговые суммы совпадают со строками, старые данные не искажены | Риск неверных расчётов и ручных разборов |
Поправили тексты и подсказки | Проверяем позже, если останется время | Ниже риск, если это не мешает основному сценарию |
Обратите внимание, здесь важен не только список, а порядок. Сначала берем сценарии, связанные с изменениями и высокой ценой ошибки. Потом основные пользовательские пути и места, которые раньше ломались, а только после этого всё остальное.
При этом сокращённая регрессия не должна заканчиваться фразой «всё проверили». Если времени было меньше, чем нужно, итог должен звучать как «проверены основные сценарии, связанные с изменениями» и «критичных проблем в данных областях не найдено, остаточный риск в локальных визуальных ошибках или проблемы в редко используемых сценариях».
То есть мы должны зафиксировать:
Что нужно зафиксировать | Пример |
|---|---|
Что проверили | Оплата, заказ, заявка, профиль, отчёт |
Что не проверили | Редкие экраны, второстепенные уведомления, старые сценарии вне изменений |
Почему не проверили | Не связано с релизом, ниже риск, не хватило времени |
Какой риск остаётся | Возможны проблемы вне основных пользовательских путей |
Что делать после релиза | Дойти до отложенных проверок и следить за обращениями пользователей |
И ещё важная оговорка. Такой подход не спасает, если команда не понимает, что именно вошло в релиз, если изменения затрагивают миграции данных, безопасность, права доступа или платёжную логику, а быстро вернуть старую версию невозможно. В таких случаях сокращать регрессию особенно опасно. Лучше уменьшать сам релиз, отключать часть функциональности или переносить выпуск, чем делать вид, что один день проверки равен полноценным трём.
Если тема регрессии, быстрых проверок и разумной приоритизации вам близка, присмотритесь к открытым урокам OTUS по тестированию. Это бесплатные занятия в рамках онлайн‑курсов: их проводят преподаватели‑практики, можно познакомиться с форматом обучения, задать вопросы и понять, какие инструменты помогают быстрее находить критичные дефекты.
Ближайшие уроки по теме:
4 июня, 20:00 — «API под контролем: тестирование сервисов с помощью Postman»
На уроке покажем, как тестировать API и сервисные сценарии, которые часто входят в критичный регресс: авторизация, заявки, данные, интеграции и другие участки, где ошибка может стоить дорого.16 июня, 20:00 — «ИИ в автотестах: помощник или угроза?»
Поговорим о том, где ИИ действительно может помочь в автоматизации тестирования, а где есть риск получить ложное чувство надежности вместо качественного покрытия.
Приходите на открытые уроки, если хотите не просто «успевать регресс к релизу», а выстраивать проверки так, чтобы команда быстрее находила важные проблемы и лучше понимала остаточные риски.
А чтобы не пропускать новые материалы, открытые уроки и разборы от практиков, подписывайтесь на канал OTUS в МАХ. Там публикуем анонсы, полезные материалы и подборки по IT-направлениям.