Как происходит взаимодействие с системой управления задачами в работе

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

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

Как отвечать

Назовите систему, с которой работали (Jira, YouTrack, Redmine), и опишите свою часть работы:

• жизненный цикл бага: New, In Progress, Resolved или Ready for Test, затем Closed либо Reopened. Уточните, кто в вашей команде двигает задачу на каждом шаге;
• баг-репорт: заголовок по схеме «где, что, при каких условиях», шаги, ожидаемый и фактический результат, окружение и версия сборки, вложения: скриншот, видео, лог, HAR;
• severity и priority: первое про влияние дефекта на систему, его ставит QA. Второе про очерёдность исправления, его решает продакт или лид. Опечатка в названии продукта на главной незначительна по severity, но срочна по priority;
• связи: баг привязан к истории, где найден, и к тест-кейсу. Кейсы и прогоны часто живут прямо в Jira через Zephyr Scale или Xray;
• фильтры и дашборды: JQL вроде project = APP AND issuetype = Bug AND status = Reopened, выборка по fixVersion перед релизом, дашборд открытых критичных дефектов;
• колонка тестирования на доске: задача не считается сделанной, пока не прошла проверку.

Приводите свои цифры, если они есть: сколько багов за спринт, как изменилась доля переоткрытых после введения шаблона баг-репорта. Если процесс был хаотичным, честно скажите и опишите, что бы изменили.

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

Путают severity и priority или считают их одним полем.

Не ищут дубликаты перед заведением. Три бага на одну проблему засоряют бэклог и раздражают разработчиков.

Меняют статус без комментария. Баг переоткрыли, не написав, на какой сборке и с какими данными он воспроизводится, и разработчик начинает разбор с нуля.