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