Использовали ли Jira для управления задачами

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

Не сам факт работы с Jira, а то, как вы встроены в процесс команды: как заводите баги, как двигаете задачи по статусам, как находите нужное. Следом часто просят описать хороший баг-репорт или объяснить разницу между severity и priority.

Как отвечать

Короткого «да, использовал» не хватит. Расскажите, что именно делали сами на реальном проекте:

• баг-репорт: заголовок по схеме «где, что, при каком условии», шаги воспроизведения, ожидаемый и фактический результат, окружение (сборка, браузер, устройство), вложения: скриншот, видео, HAR, фрагмент лога;
• severity и priority: severity это влияние дефекта на систему, её оценивает QA; priority это очерёдность исправления, её решает продакт или лид. Опечатка в названии компании на главной бывает низкой severity и высоким priority;
• workflow: через какие статусы шла задача, например «В работе», «Готово к тестированию», «Переоткрыта», «Закрыта», и кто её двигал на каждом шаге;
• JQL и фильтры: запросы вроде project = SHOP AND type = Bug AND status = "Ready for Test" AND assignee = currentUser(), сохранённые фильтры и дашборды для регресса;
• связи: баг привязан к истории, задачи собраны в fixVersion релиза, тест-кейсы ведутся в Zephyr Scale, Xray или внешней TMS.

Учтите, что Atlassian прекратила продажи в России в 2022 году, и многие команды перешли на Яндекс Трекер, YouTrack или Kaiten. Если ваш опыт в другом трекере, так и скажите: принципы те же, интерфейс осваивается за несколько дней. Если трекером пользовались только на курсах, признайтесь честно и покажите, что знаете, как устроен хороший баг-репорт.

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

Отвечают одним словом и не приводят ни одного примера своей работы в трекере.

Путают severity и priority или считают, что оба поля выставляет тестировщик.

Приносят шаблонную историю «после внедрения Jira время исправления сократилось на 30%». Без вашего реального вклада и проверяемых цифр это звучит как заготовка, и первый же уточняющий вопрос её разрушит.