Зачем нужно тестирование: дефект, ошибка, отказ и их различия · 12 мин
🎯 Цель урока

Понять, почему тестирование является неотъемлемой частью разработки ПО и как соотносятся понятия ошибки, дефекта и отказа по ISTQB. Научиться использовать правильную терминологию при общении с командой и в экзаменационных заданиях.

Контекст

Программное обеспечение присутствует повсюду — от банковских систем до медицинских приборов. Ошибки в нём стоят денег, репутации и даже человеческих жизней. ISTQB выделяет три ключевых понятия, которые позволяют точно описать природу проблем в ПО.

  • Error (ошибка): действие человека, которое приводит к некорректному результату — например, опечатка разработчика в условии if.
  • Defect (дефект / баг): изъян в рабочем продукте, возникший вследствие ошибки человека и зафиксированный в коде, документе или конфигурации.
  • Failure (отказ): отклонение компонента или системы от ожидаемого результата при выполнении — то, что видит пользователь.
  • Не каждый дефект приводит к отказу: код с дефектом может никогда не выполниться при реальных сценариях использования.
  • Root cause (коренная причина): первопричина возникновения дефекта — неправильное требование, усталость разработчика, давление сроков.

Рабочий алгоритм

Как правильно классифицировать проблему и выбрать верный термин при написании баг-репорта или ответе на экзаменационный вопрос.

  • Шаг 1. Определите, кто допустил ошибку и на каком этапе — это error (человеческое действие).
  • Шаг 2. Найдите артефакт, который содержит изъян в результате ошибки — это defect (конкретная строка кода, требование, схема).
  • Шаг 3. Воспроизведите нежелательное поведение системы при запуске — это failure (наблюдаемое отклонение).
  • Шаг 4. Проследите цепочку: error → defect → failure, чтобы понять, где вмешаться эффективнее всего.
  • Шаг 5. Укажите root cause в баг-репорте: что именно спровоцировало ошибку человека.
  • Шаг 6. Используйте правильный термин в коммуникации: не называйте отказ «багом», если имеете в виду дефект в коде.

Пример из практики

Команда разрабатывает интернет-банк. Разработчик допустил ошибку при написании логики расчёта процентов — использовал целочисленное деление вместо деления с плавающей точкой.

  • Error: разработчик написал int вместо float при объявлении переменной в расчёте процентной ставки.
  • Defect: строка кода `rate = totalAmount / 100` вместо `rate = totalAmount / 100.0` зафиксирована в репозитории.
  • Failure: клиент получает начисление 0% вместо 5.7% — система видимо работает, но результат неверный.
  • Root cause: отсутствие code review и автоматических тестов для граничных значений расчётного модуля.

Частые ошибки

Неправильное применение терминологии — частая причина потери баллов на экзамене ISTQB.

  • Называть любую проблему «багом» без различения error, defect и failure.
  • Считать, что каждый дефект обязательно вызывает отказ — дефект может присутствовать, но никогда не срабатывать.
  • Путать root cause с defect: root cause — это причина ошибки человека, а не сам изъян в коде.
  • Игнорировать, что failure — это наблюдаемое поведение, а не внутреннее состояние системы.
  • Не учитывать, что ошибка может быть допущена и в требованиях, и в дизайне, и в коде — не только разработчиком.

Самопроверка

1Чем отличается defect от failure по ISTQB?
Defect — это изъян в артефакте (коде, документе), зафиксированный статически. Failure — это наблюдаемое отклонение системы от ожидаемого поведения при выполнении. Defect существует даже без запуска программы; failure возникает в момент исполнения.
2Может ли дефект никогда не привести к отказу? Объясните.
Да. Дефектный код может никогда не выполниться, если соответствующие условия не встречаются в реальных сценариях использования. Например, дефект в коде обработки ошибки сетевого тайм-аута не проявится, если сеть всегда стабильна.
3Что такое root cause и зачем его фиксировать в баг-репорте?
Root cause — коренная причина, из-за которой человек допустил ошибку (error): неполное требование, отсутствие code review, усталость. Фиксация root cause позволяет устранить системную проблему и предотвратить класс похожих дефектов в будущем.