Какие знаешь резолюции баг репорта?

Резолюции баг-репортов: классификация и стратегии применения

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

Стандартный набор резолюций (классика JIRA/баг-трекеров)

• Fixed (Исправлен)

    *   **Значение:** Дефект был воспроизведен, код (или конфигурация) изменен, и исправление верифицировано (как минимум, разработчиком). Баг готов к проверке тестировщиком.
    *   **Контекст:** Основная целевая резолюция для большинства реальных багов. Требует обязательного перехода в статус "Reopened", если при повторной проверке (Re-Test) проблема не устранена.

• Duplicate (Дубликат)

    *   **Значение:** Обнаруженная проблема уже была заведена в системе ранее в другом баг-репорте. Все детали и шаги должны быть аналогичны или являться частным случаем уже существующего отчета.
    *   **Контекст:** Крайне важно в поле комментариев **ссылкой указать основной (оригинальный) баг-репорт**. Это предотвращает потерю информации и объединяет историю обсуждения. Частый выбор при массовом тестировании одной функциональности несколькими QA.

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

    *   **Значение:** Дефект технически подтвержден, но принято сознательное решение не исправлять его в данной версии или вообще. Причины могут быть бизнес-ориентированными (низкий приоритет, disproportionate cost — стоимость исправления превышает пользу) или техническими (архитектурные ограничения).
    *   **Контекст:** **Требует обязательного обоснования в комментарии.** Пример: неконсистентное, но не критичное поведение в устаревшем модуле, который скоро будет полностью переписан. Решение должно быть согласовано с менеджером продукта (PO/PM).

• Cannot Reproduce (Не воспроизводится)

    *   **Значение:** Разработчик не смог воспроизвести проблему в своей среде с предоставленными шагами.
    *   **Контекст:** Одна из самых "неприятных" резолюций. Частая причина — недостаточно детализированные шаги, уникальность данных или состояния окружения (особенно актуально для тестирования на mobile devices). **Стратегия для QA:** немедленно провести повторное исследование, уточнить шаги, приложить дополнительные логи, скриншоты или видео. Если воспроизводится — переоткрыть баг с новой информацией.

• Not a Bug (Не баг)

    *   **Значение:** Описанное поведение системы является корректным с точки зрения требований (явных или неявных), технических спецификаций или общепринятых UX-практик.
    *   **Контекст:** Часто возникает из-за разного толкования требований между тестировщиком и разработчиком. **Обязательно требует аргументации со ссылкой на спецификацию.** Если QA не согласен, он должен инициировать обсуждение с аналитиком или тимлидом.

• Deferred (Отложен)

    *   **Значение:** Дефект признан валидным, но его исправление переносится на одну из следующих итераций или релизов (например, на бэклог следующего спринта).
    *   **Контекст:** Промежуточное решение между "Won't Fix" и "Fixed". Часто используется при нехватке времени в конце спринта для багов с низким/средним приоритетом. Важно указать в комментарии целевую версию (если известна) или причину переноса.

Расширенные и ситуативные резолюции

• Works as Designed (Работает как задумано)

    *   Похоже на "Not a Bug", но с акцентом на то, что поведение соответствует дизайну, даже если он может быть неочевидным для пользователя. Может быть поводом для обсуждения улучшения дизайна (UX-баг).

• Need More Info (Требуется дополнительная информация)

    *   Используется, когда разработчик или другой участник не может двигаться дальше без уточнений от автора бага. После получения информации резолюция меняется.

• Obsolete/No longer applicable (Устарело/Более не применимо)

    *   Дефект потерял актуальность из-за кардинального изменения функциональности, удаления фичи или смены платформы.

Практические рекомендации по использованию

1. Единый глоссарий: Команда обязательно должна договориться о четком значении каждой резолюции. Это фундамент для чистых аналитических отчетов.
2. Комментарии — это всё: Резолюции "Won't Fix", "Not a Bug", "Duplicate" без содержательного комментария — это источник будущих конфликтов и потери информации.
3. Связь с приоритетом: Резолюция "Deferred" для критичного бага — это красный флаг, требующий обсуждения на Scrum of Scrums или с владельцем продукта.
4. Автоматизация и метрики: На основе резолюций строятся ключевые метрики:

    *   **Reopened Rate (%):** (Количество переоткрытых багов / Общее количество закрытых) * 100. Высокий показатель говорит о проблемах в процессе верификации или качестве фиксов.
    *   **Distribution of Resolutions:** Распределение по резолюциям показывает "здоровье" процесса. Высокий процент "Cannot Reproduce" сигнализирует о плохом качестве баг-репортов, а высокий процент "Won't Fix" — о возможных проблемах с планированием или проработкой требований.

-- Пример SQL-запроса для анализа резолюций в спринте
SELECT
    resolution,
    COUNT(*) as bug_count,
    ROUND((COUNT(*) * 100.0 / (SELECT COUNT(*) FROM bugs WHERE sprint_id = 123)), 2) as percentage
FROM bugs
WHERE sprint_id = 123 AND status = 'CLOSED'
GROUP BY resolution
ORDER BY bug_count DESC;

Итог: Резолюция — это не просто "выбор из выпадающего списка". Это формальное, структурированное завершение жизненного цикла дефекта, которое несет в себе ценную информацию для всех участников процесса: от разработчика и тестировщика до менеджера проекта и аналитика качества. Грамотное ее применение — признак зрелого и дисциплинированного процесса разработки.