Определение дефекта

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

“Быстрое тестирование” Роберт Калбертсон, Крис Браун, Гэри Кобб:

Программная ошибка - ни что иное, как изьян в разработке программного продукта, который вызывает несоответствие ожидаемых результатов выполнения программного продукта и фактически полученных результатов.

“Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах” Роман Савин

Итак, баг (bug) — это отклонение фактического результата (actual result) от ожидаемого результата (expected result).

В соответствии с законом исключенного третьего у нас есть баг при наличии любого фактического результата, отличного от ожидаемого.

Википедия

В целом, разработчики различают дефекты программного обеспечения и сбои. В случае сбоя программа ведёт себя не так, как ожидает пользователь. Дефект — это ошибка/неточность, которая может быть (а может и не быть) следствием сбоя.

Мое определение.

Дефект - поведение программы, затрудняющее или делающее невозможным достижение целей пользователя или удовлетворение интересов участников. Подразумевает возможность исправления. При невозможности исправления переходит в разряд ограничения технологии.
“Интересы участников” - следует понимать в значении А. Коберна.

Комментариев: 8

  1. karkadil написал:

    Дефект - поведение программы, затрудняющая или делающая невозможным достижение целей пользователя или удовлетворение интересов участников

    Трудно согласиться: грамматическая ошибка - тоже баг, интерфейсный, однако он ничего не затрудняет.

    У вас в определении дефекта, кстати, тоже есть баг. Надо бы вот так:
    Дефект - поведение программы, затрудняющЕЕ или делающЕЕ :)

  2. SALar написал:

    - Нул посчемтудже. Обдилие отрагравитестикх огшибхог зруднуят ралту с по.
    Ну почему же. Обилие орфографических ошибок затрудняет работу с ПО.

    За найденный баг спасибо. Все таки идея отдавать статьи на вычитку корректору и рецензенту не лишена привлекательности.

    PS. Да. На этом блоге премодерация.

  3. SALar написал:

    И самое важное. Отдельная орфографическая ошибка может быть и не затрудняет достижение цели пользователем, но наносит удар по репутации производителя и издателя. Т.е. затрудняет или делает невозможным удовлетворение интересов участников. Замечу, что участники - понятие более широкое, чем пользователь. Участник может даже не знать о существовании программы, но при этом его интересы могут страдать из-за некорректного поведения программы.
    В этом отличие моего определения от остальных.

  4. Alexei Barantsev написал:

    Сергей, посмотри вот здесь интересную коллекцию терминов: http://www.softwaredevelopment.ca/bugs.shtml

    Ещё любопытно вот это исследование Канера, в котором он пытается подвести юридическую базу под понятие дефекта ПО: http://www.kaner.com/pdfs/defects4.pdf

    А моё любимое определение вот такое (источник — http://www.sei.cmu.edu/sema/pdf/defect-prediction-techniques.pdf):
    “Software Defect: any flaw or imperfection in a software work product or software process
    - software work product is any artifact created as part of software process
    - software process is a set of activities, methods, practices, and transformations that people use to develop and maintain software work products”

  5. Alex Lebedev написал:

    Считаю, что к вашему определению следует добавить важное граничное условие.

    Помимо принципиальной реализуемости правильного варианта, нужно чтобы реализация этого варианта входила в установленные рамки (scope) проекта.

  6. SALar написал:

    > Помимо принципиальной реализуемости правильного варианта, нужно чтобы
    > реализация этого варианта входила в установленные рамки (scope) проекта.
    Скорее да, чем нет.
    Но здесь мы плавно переходим к “запросам на изменения”. Что начинает уводить разговор в сторону анализа бизнес требований.

  7. Alex Lebedev написал:

    Если мы привязываем понятие качества к соответствию требованиям, то управление требованиями никак не является посторонней темой.

    В свое время довелось лично наблюдать, как контроль качества на основании общих представлений о том, что “любой продукт должен обладать свойствами A, B и C) давал в разы меньше ценных результатов, чем то же самое, но с учетом целей текущего этапа проекта.

    Вывод, который я сделал для себя тогда — контроль качества без привязки к задачам проекта так же бесполезен, как создание “общей платформы для решения любых задач” в разработке.

  8. Ghost83 написал:

    И все таки дефект - это несоответствие реализованного продукта предъявляемым к нему требованиям. Требования, в свою очередь, могут быть функциональными, требованиями к интерфейсу и т.п. В конце концов сам специалист по тестированию может предъявлять дополнительные требования к тестируемому продукту.

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.