Ошибка, дефект и отказ: в чём разница

Разбираем цепочку «человек ошибся → в коде дефект → система отказала» и учимся не называть багом всё подряд.

В команде нужно говорить на одном языке — иначе обсуждение превращается в «у меня всё работает» против «а у меня нет». Международный словарь тестирования (ISTQB) даёт три разных слова там, где новичок обычно использует одно — «баг».

Цепочка: ошибка → дефект → отказ

Термин	Что это	Пример
Ошибка (error, mistake)	Действие человека, приведшее к неверному результату	Разработчик неверно понял требование «скидка от 5 000 ₽»
Дефект (defect, bug, fault)	След ошибки в артефакте: коде, требовании, макете, тест-кейсе	В коде написано total > 5000 вместо total >= 5000
Отказ (failure)	Внешне наблюдаемое неправильное поведение системы	Заказ ровно на 5 000 ₽ оформляется без скидки

Важное следствие: дефект может существовать и не приводить к отказу. Пока никто не оформит заказ ровно на 5 000 ₽, никто ничего не заметит. Именно поэтому тестировщик целится в граничные значения, а не в «обычные» данные — там дефекты и живут.

Дефект бывает не только в коде

Самые дорогие дефекты живут в требованиях. Примеры из реальной жизни:

• «Пользователь вводит номер телефона» — а в каком формате? С +7 или с 8? Со скобками? Разрешён ли зарубежный номер? Каждый неотвеченный вопрос — будущий баг и будущий спор.
• «После оплаты пользователь видит подтверждение» — а если оплата прошла, но письмо не ушло? А если пользователь закрыл вкладку? Это состояние системы никем не описано.
• Макет нарисован только для десктопа. Как эта таблица на 8 столбцов должна выглядеть на телефоне — не знает никто, и каждый разработчик решит по-своему.

Дефект, улучшение и вопрос

Три разных типа задач, которые новички валят в одну кучу:

• Дефект (bug) — поведение расходится с требованием, макетом, стандартом или предыдущей работавшей версией. Всегда можно назвать, с чем именно расходится.
• Улучшение (improvement / feature request) — «работает по требованию, но было бы лучше…». Оформляется отдельно, приоритет ставит продакт, а не вы.
• Вопрос (clarification) — «требование не покрывает случай X, что делаем?». Это самый ценный тип задачи от новичка: он экономит переделку.

Отдельно: severity и priority — не одно и то же

Забегая вперёд (подробно — во втором модуле): серьёзность отвечает на вопрос «насколько сломано», приоритет — «когда чинить». Опечатка на главной странице — Trivial по серьёзности, но чинится сегодня, потому что её видят все. Падение при экспорте отчёта в редком формате — Critical по серьёзности, но подождёт до следующего спринта, если этим пользуются два клиента.

Мини-практика

Прочитайте три ситуации и мысленно разложите их по полочкам «ошибка / дефект / отказ»:

1. Аналитик забыл описать поведение при отмене уже оплаченного заказа → в коде нет ветки на этот случай → пользователь нажимает «Отменить» и получает белый экран.
2. Дизайнер нарисовал кнопку 44 px, разработчик сделал 32 px → на телефоне в кнопку тяжело попасть пальцем.
3. Тестировщик неверно понял требование и завёл баг на корректное поведение → разработчик потратил день на разбирательство.

Третий пункт — тоже дефект. Только в тест-кейсе. Такое случается у всех; важно признать быстро и поправить кейс, а не защищать репорт из принципа.