Баг (он же дефект) — это несоответствие между тем, как программа работает, и тем, как она должна работать. Ключевое слово — «должна»: чтобы назвать что-то багом, нужно знать, как правильно. Если поведение странное, но именно так и задумано в требованиях, — это не баг.
Найти баг — половина дела. Вторая половина — правильно оценить, насколько он важен, потому что чинить всё сразу невозможно, и команде нужно понимать, за что хвататься. Для оценки есть две отдельные шкалы: severity и priority.
Сверху одно и то же наблюдение: счётчик разошёлся с числом товаров. Вердикт зависит не от наблюдения, а от эталона — одно требование делает его багом, другое объявляет «так и задумано», а молчание требований превращает в вопрос аналитику. Снизу — две независимые оценки уже заведённого бага: по диагонали стоят те самые случаи, где severity и priority расходятся.
Что считать багом
Баг — это отклонение от ожидаемого поведения. Оно берётся из требований, макетов, здравого смысла и общих правил (например, «приложение не должно падать» — это всегда баг, даже если явно нигде не написано).
Частые сомнения новичка:
- «Странно, но так в требованиях». Не баг. Если считаете, что требование плохое, — это вопрос к аналитику, а не дефект.
- «В требованиях об этом ничего нет». Возможно, баг: есть негласные ожидания (не падать, не терять данные, показывать понятные ошибки). Такие случаи обсуждают с командой.
- «Мне не нравится, как выглядит». Само по себе не баг, если соответствует макету. Но если реально неудобно или нечитаемо — стоит завести как замечание к удобству.
Когда сомневаетесь, баг это или нет, — не молчите, спрашивайте. «Так и задумано или это баг?» — нормальный рабочий вопрос.
Ошибка, дефект, сбой: откуда берутся баги
В строгой терминологии за словом «баг» стоит цепочка из трёх звеньев:
- Ошибка (error) — действие человека: разработчик опечатался, аналитик написал двусмысленное требование.
- Дефект (defect, bug) — результат этой ошибки в продукте: неверная строка кода, неправильное условие. Дефект может тихо жить в коде и никак не проявляться.
- Сбой или отказ (failure) — проявление дефекта при работе: программа упала, посчитала неверно, показала не то.
Тестировщик замечает именно сбои — а в репорте описывает дефект, докапываясь до его причины. Важное следствие: дефекты бывают не только в коде — в требованиях, документации, настройках. Двусмысленное требование — такой же дефект, и находить его дешевле всего ещё до написания кода.
В повседневной речи всё это зовут «багом», и это нормально. Но понимание цепочки помогает писать репорты по сути: описывать не «где-то что-то упало» (сбой), а что именно работает не так (дефект).
Severity — насколько серьёзно ломает
Severity (серьёзность) отвечает на вопрос: насколько сильно баг вредит продукту технически, если с ним столкнуться. Это объективная характеристика самого дефекта. Обычные градации:
- Blocker (блокер). Дальше работать невозможно: приложение не открывается, оплата вообще не проходит.
- Critical (критический). Ломается важная функция или теряются данные: заказы не создаются, списываются лишние деньги.
- Major (значительный). Заметная функция работает неверно, но есть обходной путь.
- Minor (незначительный). Мелочь: криво выровнена кнопка, опечатка, некрасивая, но понятная ошибка.
Severity обычно ставит тестировщик — он видит, что и как сломалось.
Priority — насколько срочно чинить
Priority (приоритет) отвечает на другой вопрос: насколько срочно это нужно исправить с точки зрения бизнеса. Обычно: High / Medium / Low (высокий / средний / низкий). Приоритет чаще определяют менеджер или команда, а не только тестировщик, потому что он про бизнес, а не про технику.
Ключевая мысль: severity и priority — это разные вещи, и они не всегда совпадают. Классические примеры:
- Высокая severity, низкий priority. Приложение падает, но только при экзотической настройке, которой почти никто не пользуется. Серьёзно по сути, но чинить не срочно.
- Низкая severity, высокий priority. Опечатка в названии компании на главной странице или неверный логотип. Технически ерунда (minor), но позорно и видно всем — исправить надо немедленно.
Где это применяется
Оценку важности вы даёте каждому багу, который заводите, — это часть баг-репорта. От неё зависит, возьмут баг в работу сейчас или отложат. Ошибётесь с оценкой — либо команда бросит силы на ерунду, либо пропустит что-то важное. Поэтому severity и priority — не формальность, а способ донести до команды, насколько всё плохо и насколько срочно.
Где спотыкаются начинающие:
- Путают severity и priority или считают их одним и тем же. Это разные шкалы: «насколько ломает» и «насколько срочно чинить».
- Всему ставят «критично». Если критично всё — значит, ничего. Оценивайте честно, иначе к вашим оценкам перестанут прислушиваться.
- Заводят как баг то, что задумано, не сверившись с требованиями. Сначала уточните, «так и надо?».
Коротко
- Баг — расхождение с тем, как должно быть; без эталона (требование, макет, здравый смысл) вердикта нет.
- Цепочка одна: ошибка человека → дефект в продукте → сбой при работе. Видим сбой, описываем дефект.
- Дефект бывает не только в коде: двусмысленное требование — такой же дефект, и чинить его дешевле всего.
- Severity ставит тестировщик, и она про технику; priority ставит команда, и он про бизнес.
- Шкалы расходятся: падение при редкой настройке — высокая severity и низкий priority, опечатка в названии компании — наоборот.
Что почитать дальше
- Как писать баг-репорт — как из находки получается отчёт, который разработчик повторит шаг в шаг.
- Качество баг-репорта — почему заниженная важность стоит багу месяцев ожидания.
- Жизненный цикл бага и трекеры — что происходит с оценкой дальше и кто её меняет.
- Уровни и свойства хороших требований — откуда берётся «как должно быть», без которого нет вердикта.