Какие возможности дает система управления задачами для тестировщика

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

Работали ли вы в трекере по-настоящему: оформляли баги, строили фильтры, связывали дефекты с требованиями и релизами. Следом обычно просят рассказать, как вы заводите баг, или спрашивают, чем severity отличается от priority.

Как отвечать

Говорите не про «можно ставить задачи», а про конкретные возможности, лучше на примере трекера, где работали сами: Jira, YouTrack, Redmine или отечественные аналоги.

• жизненный цикл дефекта: workflow со статусами и переходами, от «Новый» до «Закрыт», с возвратом в «Переоткрыт». Тестировщик закрывает баг только после перепроверки на нужной сборке;
• поля для воспроизведения: шаги, фактический и ожидаемый результат, окружение, версия, где нашли (Affects Version), и версия, где исправят (Fix Version), логи и запись экрана;
• severity и priority: серьёзность отражает влияние на систему, приоритет отражает очерёдность исправления, и они не обязаны совпадать;
• связи: blocks, duplicates, relates to, связь бага с историей и тест-кейсом. Так появляется трассируемость от требования до дефекта;
• фильтры и дашборды: в Jira это запросы на JQL, например все открытые баги релиза с высокой серьёзностью. Из них собирается отчёт о готовности к релизу;
• интеграции: тест-менеджмент (Zephyr, Xray, TestRail, Test IT), связь с коммитами и merge request, автоматическое создание задачи по упавшему автотесту в CI.

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

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

Говорят общими словами про «организацию работы и коммуникацию». Интервьюер ждёт терминов трекера и того, как им пользуется именно тестировщик.

Путают severity и priority или считают их одним полем. Опечатка в названии компании на главной странице имеет низкую серьёзность и высокий приоритет, это классический пример.

Заводят дубли, не поискав существующий баг, и не обновляют статус после перепроверки. Трекер перестаёт отражать реальность, и ему перестают доверять.