Был ли опыт составления регрессионного скоупа

Что проверяют

Умеете ли вы выбрать, что гонять перед релизом, когда на полный регресс нет времени, и обосновать выбор. Следом обычно спрашивают, как вы узнаёте, что задели изменения, и что делаете, если в срок не укладываетесь.

Как отвечать

Рассказ строится на вашем релизе, а каркас примерно такой:

• источник изменений: задачи в версии релиза в Jira или YouTrack, описания пулл-реквестов, разговор с разработчиками о том, какие модули задеты. Без этого скоуп собирается вслепую;
• анализ влияния: от изменённого модуля идёте к зависимым. Поменяли расчёт скидки, значит проверяете корзину, оформление заказа, промокоды и чеки;
• риск и приоритет: критичные пользовательские пути (регистрация, оплата, основной сценарий) идут всегда, остальное по вероятности поломки и цене ошибки. Помогает история дефектов: где ломалось раньше, там сломается снова;
• уровни регресса: смоук на каждой сборке, частичный регресс по затронутым областям, полный перед крупным релизом;
• инструменты: кейсы с приоритетами и метками в TestRail, Qase, Allure TestOps или Zephyr, из них собирается тестовый прогон под релиз. Автотесты в CI закрывают стабильную часть, руками остаётся новое и то, что дорого автоматизировать.

Цифры должны быть вашими: сколько кейсов в полном наборе, сколько попало в скоуп, сколько времени заняло, что нашли. Если сами скоуп не составляли, скажите честно: прогоняли готовый набор и видели, как его собирает лид. Затем объясните, как собрали бы его сами по шагам выше.

Где спотыкаются

Отвечают «прогоняем всё». Это не скоуп, а отказ от выбора, и следующим вопросом будет, что вы уберёте, если на регресс дадут один день.

Собирают скоуп только по требованиям, не спрашивая разработчиков. Рефакторинг общего кода в требованиях не виден, а ломает он больше всего.

Не чистят набор. Устаревшие кейсы, которые давно никто не проходит по-настоящему, раздувают регресс и дают ложное ощущение покрытия.