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

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

В команде нужно говорить на одном языке — иначе обсуждение превращается в «у меня всё работает» против «а у меня нет». Международный словарь тестирования (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 по серьёзности, но подождёт до следующего спринта, если этим пользуются два клиента.

Ещё семь слов, без которых дальше не обойтись

Эти термины встречаются в вакансиях, на собеседовании и в каждом следующем уроке. Здесь — короткие определения, чтобы дальше не спотыкаться; подробный разбор придёт в своё время.

Термин	Что это	Пример на нашем магазине
Верификация	Проверка «правильно ли мы делаем продукт»: сверяем реализацию с требованием, макетом, стандартом	В требовании «скидка от 5 000 ₽ включительно» — проверяем, что заказ ровно на 5 000 ₽ её получает
Валидация	Проверка «то ли мы вообще делаем»: решает ли продукт задачу пользователя и бизнеса	Скидка работает по требованию, но покупатель узнаёт о ней только на последнем шаге оплаты — цель «поднять средний чек» не достигнута
Тест-кейс	Одна проверка с предусловием, шагами и ожидаемым результатом; выполнима любым человеком без вас	«Корзина на 5 000 ₽ → перейти к оформлению → в итоге видна скидка 10%»
Чек-лист	Список того, что надо проверить, без подробных шагов. Быстрее кейсов, но требует опыта	«Скидка: 4 999 / 5 000 / 5 001 / 0 / вместе с промокодом / после удаления товара»
Тестовые данные	Конкретные значения, на которых выполняется проверка	Пользователь test+5@shop.ru, товар «Кружка» за 2 500 ₽, промокод SPRING
Окружение (стенд)	Среда, где развёрнута сборка: код, база, настройки, версии сервисов	dev — для разработчиков, test — наш, prod — тот, которым пользуются покупатели
Регресс	Проверка, что новые изменения не сломали то, что работало раньше	Починили скидку — перепроверяем оформление заказа целиком, а не только скидку

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

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

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

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

Слова из этого урока спрашивают на собеседовании прямо, а прочитать определение и вспомнить его через неделю — разные вещи. Прогоните карточки: сформулируйте определение про себя, потом сверьтесь.