Как подходить к приоритетам задач
Что проверяют
Умеете ли вы решать, что тестировать первым, когда времени на всё не хватает, а так бывает почти перед каждым релизом. Интервьюер хочет услышать критерии, а не «делаю самое важное». Следом часто спрашивают, чем severity отличается от priority и кто в итоге решает, что баг блокирует релиз.
Как отвечать
Постройте ответ вокруг риска: приоритет задачи определяется вероятностью проблемы и её ценой для пользователя и бизнеса.
- severity и priority: первое описывает, насколько серьёзен дефект технически, второе, как срочно его чинить. Опечатка на главной странице может иметь низкую severity и высокий priority, падение в редком админском разделе наоборот;
- risk-based testing: сначала критичный путь пользователя (регистрация, оплата, оформление заказа), затем зоны, которые затронуты изменениями в релизе, затем то, что исторически часто ломается;
- порядок внутри релиза: smoke на новой сборке, проверка новых фич и исправленных багов, затем регрессия, где тоже есть приоритеты кейсов. В TestRail или Qase у кейсов есть поле приоритета, и по нему собирается сокращённый прогон, когда времени мало;
- MoSCoW или матрица Эйзенхауэра: полезны как язык для обсуждения с продактом, но не заменяют оценку риска;
- коммуникация: приоритеты согласуются с тимлидом и продактом. Если всё не успеть, вы открыто говорите, что осталось непроверенным и чем это грозит, а решение о выпуске принимает команда.
Расскажите реальный случай: сколько было задач, по какому признаку вы их упорядочили, что сознательно отложили и чем кончилось. Если опыта в команде нет, опишите, как расставили бы приоритеты в конкретной ситуации, например когда за день до релиза нашли пять багов разной тяжести.
Где спотыкаются
Путают severity и priority или считают их одним и тем же. Для QA это базовый вопрос.
Говорят, что сами решают, что пойдёт в релиз. Тестировщик даёт информацию о рисках, а решение принимается вместе с продуктом и разработкой.
Рассказывают STAR-историю с результатом «все остались довольны», без цифр и без того, что пришлось отложить. Честное «регрессию платёжного модуля мы урезали и отметили это в отчёте» звучит убедительнее.