Так мне кажется это вопрос процесса тестирования. Если ты написал чёткий тест-план, в котором указал виды тестирования, и правильно расписал приоритеты и важность в кейсах/баг-репортах, то с первого же взгляда должны быть видны баги, которые нельзя не фиксить -- блокеры и критикал. К тому же, для последующего тестирования есть энтри кондишнс (условия начала тестирования). Если блокеры и критикал не пофикшены, то это препятствует тестированию

Угу, некоторые блокноты кочуют уже 2 спринта)

Нет.
Стоит доносить информацию о рисках, проблемах и костылях.
Их критичности и количестве.

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

Если решат что нет, значит с точки зрения бизнеса запуститься как есть - важнее (а причин для этого может быть много).

Это может быть, но если ПМ говорит "норм, катим дальше", то это не имеет никакого значения.

Все баги можно не фиксить.

Так я не про все, я про блокеры и критикал. Если какой-то кор функционал работает не так, как должен, то нужно всеми силами доносить это до бизнеса, на мой взгляд. Поэтому я говорю, может человек не правильно приоритеты ставит. ПМ видит, что это не критично для бизнеса, и оставляет на потом)

На берегу необходимо было договориться о тестовой стратегии. В ней описать критерии выхода в прод, учитывающие количество допустимых багов каждого приоритета. И также в стратегии чётко описать правила приоритезации багов.

Идея такова, вы выполняете тестирование, находите какой то блокер, который не влияет на текущий спринт. ПМ говорит, что это пофикситься после того, как распишут дизаин и определенная задача эту проблему. Но через 2 спринта, дизайнер не успел доделать эту маску и в следствии у нас вагон техтдолга. А говорят тебе - это не твои заботы, когда оно будет фикситься. Ты проверил, дал знать о проблеме - остальное тебя волновать не должно.

Так не бывает. Блокер не может не влиять на спринт. Он влияет на всё, иначе это не блокер

Я пытался намекнуть, что история с багами это всегда про "cost vs value".
Если стоимость того, что бы отложить релиз выше, чем стоимость этого самого бага в продакшене - то вообще без разницы, что оно там блокирует или не блокирует.
Значит никому не нужно откладывать релиз.

А что вы вкладываете в определение термина "блокер"?

Блокер может блокировать часть функционала, но не весь функционал нам нужен для проверки другого функционала

У нас на проекте это дефект, блокирующий более 50% тест кейсов, и не имеющий WA

Вы можете договориться о другом определении. Главное, чтобы договорились

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

У вас есть релиз, в котором сделана новая фича, для оставшихся 49%, а эти 51% заблокированы и сломаны к хренам.
Так же у вас есть эстимейт в N времени, которое нужно для исправления дефекта.

Всё, что нужно дальше, это:
1) Посчитать потери компании за N времени от того, что 51% функциональности заблокирован и не работает.
2) Посчитать прибыль компании, которую сгенерируют новые фичи для тех самых 49% функциональности за эти N времени.

Если первое больше второго - вы откладываете релиз и фиксите баг.
Если второе больше первого - вы катите как есть, потому что это целесообразнее.

Смотря какой проект. Заказчик может и на@%й послать, если у него половина системы не работает. Могут быть и штрафные санкции.

Лично я не могу себе представить, чтобы внедрялись с блокером добровольно. Его же точно придётся хотфиксом править.

Продукт пока в разработке и прода нет

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

Я пытаюсь донести простую мысль:
Принимать решение о том, нужно ли катить "как есть" или править баги - это бизнесовое решение.