Как поступить, если решение не исправлять баг было принято на встрече без вашего участия?

Решение, принятое без участия тестировщика, требует анализа и документирования.

План действий:

1. Запросить контекст. Узнать у участников встречи (разработчики, PM) причины решения: низкий приоритет, запланированное исправление в другой задаче, высокая стоимость исправления.
2. Оценить риски. Самостоятельно проанализировать влияние бага на пользователей, безопасность и бизнес-логику.
3. Документировать решение. Обновить статус баг-репорта (например, на Won't Fix или Postponed) и обязательно указать причину в комментарии.
4. Предложить альтернативу (при необходимости). Если оценка рисков показывает высокую критичность, подготовить аргументы и инициировать повторное обсуждение.

Пример оформления в Jira:

Статус: Won't Fix
Причина: Решение принято на планировании спринта 2023-10-26. 
        Баг возникает только в устаревшей версии браузера (IE11), доля которой <0.5%. 
        Исправление потребует значительных изменений в кодовой базе.
Рекомендация: Добавить предупреждение для пользователей IE11 в релизных заметках.
Ссылка на решение: CONFLU-123 (Протокол встречи)

Главная цель — обеспечить прозрачность и отслеживаемость всех решений по качеству.