Сколько кейсов обычно на регрессионное тестирование на одну платформу?
Что проверяют
Понимаете ли вы, что числа без контекста не существует, и есть ли у вас собственный опыт управления набором. Сама цифра интервьюеру не нужна, ему нужно услышать, как набор собран, сколько идёт прогон и по какому принципу вы решаете, что в него не попадёт.
Как отвечать
Назовите свою цифру вместе с рамкой: что за продукт, что считается платформой, какая доля автоматизирована, сколько занимает полный прогон. Дальше объясните принцип отбора:
- критичные пользовательские сценарии и денежный путь целиком;
- места с историей дефектов, туда регрессии возвращаются чаще всего;
- то, что задето текущими изменениями и их ближайшим окружением;
- уровни: быстрый дымовой набор на каждую сборку, сокращённый регресс на релизную ветку, полный по расписанию.
Про несколько платформ скажите отдельно, иначе набор растёт кратно их числу. Логика, одинаковая везде, проверяется один раз на быстром уровне, а на каждой платформе остаётся своё: разрешения, уведомления, оплата, переходы по ссылкам, поведение при потере сети и особенности интерфейса.
Хорошая опора в ответе это ограничение по времени. Набор ровно такой, чтобы полный прогон укладывался в окно выпуска, и если он перестал укладываться, его чистят, а не пропускают куски выборочно.
Где спотыкаются
Называют круглое число и замолкают. Следом спрашивают, сколько длится прогон и сколько человек его выполняют, и оказывается, что цифра из чужой статьи.
Второе: считают регрессом все существующие кейсы. Набор разрастается, прогон перестаёт помещаться в релизный цикл, и его начинают выполнять частями по настроению, после чего он теряет смысл вообще.
Третье: путают регресс с проверкой исправления и с дымовым набором. Первое подтверждает конкретный фикс, второе отвечает на вопрос, годится ли сборка для дальнейших проверок, и подменять одно другим в ответе не стоит.