В чём разница между Major и Critical?

Разница между Severity (Severity) и Priority (Priority) в тестировании ПО

Важный вопрос! Однако сразу хочу заметить, что в контексте классификации дефектов (багов) в тестировании, правильными терминами являются Severity (Серьезность/Критичность) и Priority (Приоритет). «Major» и «Critical» — это, как правило, значения или уровни внутри атрибута Severity. Их часто путают, потому что на практике они связаны, но отвечают на разные вопросы.

Severity (Серьезность/Критичность): Влияние дефекта на систему

Severity оценивает, насколько серьезно баг влияет на функциональность, работоспособность или безопасность продукта/системы. Это техническая оценка, которую обычно дает QA Engineer или тестировщик. Она показывает масштаб проблемы для системы.

Типичные уровни Severity:

• Critical (Критический): Дефект полностью блокирует ключевые функции системы, приводя к ее краху, невозможности продолжать работу, потере данных или серьезной угрозе безопасности. Пример: Серверная часть приложения падает при попытке совершить платеж, не позволяя завершить транзакцию.
• Major (Высокий/Значительный): Дефект существенно влияет на важную функциональность, но система продолжает работать в целом или есть обходной путь. Пример: В отчете не отображается критически важный график, но данные можно получить в другом разделе.
• Medium (Средний): Дефект влияет на неключевую функциональность или вызывает неудобство для пользователя. Пример: Неправильное форматирование текста на странице "О компании".
• Low/Trivial (Низкий/Незначительный): Дефект минимального влияния, часто косметический. Пример: Незначительное отклонение цвета кнопки от стандарта.

// Пример влияния дефекта с разной Severity на код:
public class PaymentService {
    // Critical: Метод падает с исключением, блокируя всю оплату.
    public void processPayment(Card card) throws SystemFatalException {
        if (card == null) {
            throw new SystemFatalException("Payment system unavailable!");
        }
        // ... логика оплаты
    }

    // Major: Метод работает, но возвращает некорректные данные для важного отчета.
    public Report generateFinancialReport() {
        Report report = new Report();
        // Ошибка: пропускает добавление ключевой секции "Итоги".
        // report.addSection(new SummarySection()); // Эта строка отсутствует!
        return report;
    }
}

Priority (Приоритет): Порядок исправления дефекта

Priority определяет порядок и срочность исправления дефекта с точки зрения бизнеса, проекта или релиза. Это бизнес-оценка, которую обычно устанавливает Project Manager, Product Owner или команда менеджмента. Она отвечает на вопрос: "Как быстро нам нужно это исправить?"

Типичные уровни Priority:

• High (Высокий): Дефект должен быть исправлен как можно скорее, в следующем спринте или даже в виде горячего патча.
• Medium (Средний): Дефект планируется исправить в рамках текущего релиза или следующего спринта.
• Low (Низкий): Дефект может быть исправлен позже, когда будут ресурсы (например, в будущем релизе).

Ключевые различия и взаимосвязь

Практическое применение в рабочем процессе

В процессе управления дефектами эти два атрибута используются совместно:

1. Тестировщик обнаруживает баг и назначает ему Severity (например, Critical).
2. На triage-совещании (совещании по оценке дефектов) команда (QA, разработчики, менеджеры) рассматривает баг.
3. На основе Severity, бизнес-контекста, сроков релиза и ресурсов менеджер или команда устанавливает Priority.
4. Дефект с High/Critical Severity AND High Priority попадает в работу немедленно.
5. Дефект с Critical Severity, но Low Priority может быть отложен, но его серьезность означает, что при приближении срока его использования Priority будет повышена.

Итог: «Critical» и «Major» — это градации Severity, показывающие техническую серьезность проблемы для системы. Priority — это отдельный, но связанный атрибут, который определяет порядок исправления с точки зрения бизнес-процесса. Их раздельное использование позволяет балансировать между технической целостностью продукта и практическими требованиями проекта.