Чем руководствуешься при выставлении критичности на дефекте?

При выставлении критичности (severity или priority) дефекта я руководствуюсь комплексным набором критериев, который позволяет оценить влияние бага на продукт, пользователей и бизнес-процессы. Это не просто субъективная оценка, а скорее система взвешенных факторов.

Основные критерии для оценки Severity (Критичность/Серьезность)

Severity отражает степень технического влияния дефекта на функциональность системы. Её определяют прежде всего по следующим факторам:

1. Влияние на основные функции продукта:

    *   Дефекты, которые полностью блокируют ключевые пользовательские сценарии или бизнес-процессы (например, невозможность совершить платеж в финансовом приложении).
    *   Проблемы, приводящие к падению (crash) приложения или сервиса.

1. Объем и масштаб воздействия:

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

1. Влияние на данные:

    *   Дефекты, вызывающие **потерю**, **некорректную обработку** или **несанкционированное изменение данных** (например, corruption данных). Это часто высшая степень серьезности.
    *   Проблемы, нарушающие целостность данных (integrity).

1. Влияние на безопасность (Security):

    *   Любая уязвимость, потенциально ведущая к нарушению конфиденциальности, целостности или доступности данных (например, инъекции, неавторизованный доступ). Такие дефекты почти всегда получают максимальную серьезность (`Critical` или `Blocker`).

1. Частота возникновения (Reproducibility):

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

Основные критерии для оценки Priority (Приоритет исправления)

Priority определяет порядок и скорость устранения дефекта с точки зрения бизнес-задач, сроков и ресурсов. Его устанавливают, учитывая:

1. Бизнес-риски и финансовые последствия:

    *   Баг, который может привести к прямым финансовым потерям (недоступность продаж, штрафы) или ущербу для репутации.
    *   Дефекты, затрагивающие функции, критичные для запуска релиза (release-blocking issues).

1. Влияние на пользователей и клиентов:

    *   Проблемы, затрагивающие большой процент пользователей или ключевых (VIP) клиентов.
    *   Баги, сильно снижающие удобство использования (usability) ключевых функций.

1. Зависимости и сроки проекта:

    *   Дефекты, блокирующие работу других команд или дальнейшее тестирование (например, баг в API, который нужен для интеграции).
    *   Проблемы, обнаруженные близко к дате релиза, часто получают повышенный приоритет для быстрого исправления.

1. Сложность и стоимость исправления (Effort):

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

Моя практическая методология

В реальной работе я объединяю эти критерии, часто используя матрицу или простые правила. Например:

# Пример логики оценки (очень упрощенный)
def evaluate_defect(blocks_core_function, data_loss, security_issue, affects_many_users):
    severity = "Low"
    priority = "Low"

    if security_issue or data_loss:
        severity = "Critical"
        priority = "Highest"
    elif blocks_core_function:
        severity = "High"
        priority = "High" if affects_many_users else "Medium"
    # ... Другие условия

    return severity, priority

Процесс выглядит так:

1. Сначала определяю Severity на основе технических критериев (блокировка, данные, безопасность).
2. Затем, учитывая контекст проекта, устанавливаю Priority. Severity Critical почти всегда означает Priority Highest, но Severity Medium может в некоторых случаях получить Priority High (например, если баг мешает демонстрации продукта инвестору на следующей неделе).
3. Я всегда указываю в комментарии к дефекту краткое обоснование выбранной оценки. Это важно для прозрачности и возможных дискуссий с разработчиками или менеджером.
4. При необходимости провожу согласование. Если разработчик считает, что серьезность ниже из-за сложности исправления, или менеджер требует повысить приоритет по бизнес-причинам, мы обсуждаем и можем корректировать Priority, но Severity обычно остается объективной технической характеристикой.

Примеры оценок

• Critical Severity / Highest Priority: Уязвимость, позволяющая получить доступ к административным функциям без авторизации; Потеря транзакций пользователей в банковском приложении.
• High Severity / High Priority: Основная функция "Добавить в корзину" не работает на главной странице сайта; Приложение регулярно падает при открытии определенного раздела.
• Medium Severity / Medium Priority: Неправильное отображение даты в определенном формате в отчете; Отсутствие валидации на поле ввода, не ведущее к серьезным ошибкам.
• Low Severity / Low Priority: Несоответствие цвета кнопки гайдлайнам в редком состоянии UI; Описательная ошибка в тексте сообщения, не влияющая на понимание.

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