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