В чем разница дубликатов won't do и not repruduse?

Разница между "Won't Do" и "Not Reproduce" в трекинге багов

В управлении дефектами (bug tracking) термины "Won't Do" и "Not Reproduce" обозначают совершенно разные статусы, каждый из которых имеет свои причины, последствия и процессы обработки. Их путаница может привести к серьезным проблемам в коммуникации между командами и в качестве продукта.

Статус "Won't Do" (Не будем исправлять)

"Won't Do" – это решение не исправлять найденный дефект. Это бизнес- или техническое решение, принятое, как правило, менеджером продукта или руководством после анализа.

Типичные причины для статуса "Won't Do":

• Низкий приоритет/незначительность: Баг является косметическим, не влияет на ключевую функциональность, и его исправление не стоит усилий (например, неидеальное выравнивание текста в rarely used диалоге).
• Слишком дорого/рискованно: Исправление требует огромных архитектурных изменений, сопряжено с высоким риском внесения новых ошибок в стабильные модули или несоразмерно затратно по времени.
• "Так и задумано": Поведение, описанное в баг-репорте, на самом деле соответствует дизайну или техническим ограничениям, о которых тестировщик мог не знать.
• Устаревание: Баг был найден в функциональности, которую решено удалить в следующей версии, или в платформе, которую более не поддерживают.
• Работа по контракту: Дефект находится вне рамок договора (Scope of Work).

Процесс: Баг проходит обсуждение, анализ влияния (impact analysis) и затрат (cost of fix). Решение "Won't Do" должно быть задокументировано с четким обоснованием.

Статус "Not Reproduce" (Не воспроизводится)

"Not Reproduce" (или "Cannot Reproduce", "CNR") – это техническая невозможность воспроизвести дефект в условиях, описанных в отчете. Это вызов для тестировщика и разработчика, а не финальное решение.

Типичные причины для статуса "Not Reproduce":

• Неполная или неточная информация в баг-репорте: Отсутствуют шаги воспроизведения, указана не та версия сборки, не описаны специфические данные или настройки окружения.
• Проблемы с окружением: Дефект проявлялся только на конкретной машине тестировщика из-за уникальных настроек, кеша, установленных сторонних программ.
• Синхронизация/состояние гонки (Race Condition): Ошибка возникала в результате специфического временного соотношения событий, которое сложно поймать повторно.
• Исправление "мимоходом": Дефект был случайно исправлен в другой ветке кода или при обновлении сторонней библиотеки.
• Проблемы с данными: Ошибка зависела от конкретного состояния базы данных или файла, который был изменен.

Процесс: Получив такой статус, QA-инженер обязан провести расследование:

1. Перепроверить и детализировать шаги воспроизведения.
2. Попытаться воспроизвести на другом оборудовании или в другом окружении.
3. Запросить у разработчика логи, дампы памяти или снимки состояния системы на момент падения.
4. Если воспроизвести все же не удается, но проблема критична, можно добавить мониторинг или логирование для поимки дефекта в будущем.

Сводная таблица ключевых отличий

Пример в жизненном цикле бага

Представьте баг: "При нажатии кнопки 'Сохранить' в форме профиля на устройстве iPhone X возникает креш".

• Если разработчик пишет: "Not Reproduce. На эмуляторе iPhone X с последней iOS и build #145 все работает. Пришлите логи креша и точную версию ОС." – это запрос на уточнение.
• Если продукт-менеджер пишет: "Won't Do. Устройство iPhone X составляет менее 0.1% нашей пользовательской базы, а для исправления требуется 2 недели работы. Решено сосредоточиться на новой функциональности." – это бизнес-решение.

Вывод: "Won't Do" – это стратегический вердикт, закрывающий задачу. "Not Reproduce" – это технический тупик, который является сигналом для более глубокого исследования и улучшения процесса тестирования и коммуникации. Путать их недопустимо, так как они требуют принципиально разных действий от команды.