Приоритеты и важность дефектов устанавливались на совместных совещаниях команды разработки и QA, с участием продукт-менеджера или бизнес-аналитика.

Роли и ответственность:

QA-инженер: Обнаруживал дефект, предоставлял подробное описание, шаги воспроизведения, ожидаемый и фактический результаты, а также предлагал начальную оценку важности с точки зрения пользователя.
Разработчик: Анализировал техническую сложность исправления и потенциальное влияние на другие части системы.
Продукт-менеджер / Бизнес-аналитик: Оценивал бизнес-влияние дефекта, его влияние на пользователей и соответствие приоритетам продукта.

Окончательное решение о приоритете принималось совместно, учитывая все эти факторы. В случае разногласий, решающее слово было за продукт-менеджером или тимлидом.

Приоритизация основана на матрице, учитывающей:

Приоритет	Важность (Severity)	Влияние на бизнес и пользователей
Blocker	Critical	Блокирует ключевой функционал, делает приложение неработоспособным. Требует немедленного исправления.
High	Major	Серьезно нарушает работу важного функционала, но есть обходные пути. Влияет на большое количество пользователей.
Medium	Minor	Незначительно ухудшает работу функционала, есть простые обходные пути. Заметен пользователям.
Low	Trivial	Косметические ошибки, несущественное влияние на функционал. Не влияет на большинство пользователей.

Важность (Severity) — это техническая оценка влияния дефекта на систему, устанавливаемая QA и иногда разработчиками. Приоритет — это бизнес-решение о том, как быстро нужно исправить дефект, устанавливаемое совместно с продакт-менеджером. Эти два параметра могут не совпадать.

Инструменты для отслеживания дефектов (например, Jira) использовались для фиксации и обсуждения приоритетов.

Кто в команде был ответственен за установление приоритетов и важности дефектов?