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