Определение дефекта
В этой заметке я постарался собрать различные определения дефекта или программного бага. Вроде бы вещь элементарная, но она является основополагающей, а потому к ней стоит иногда возвращаться.
“Быстрое тестирование” Роберт Калбертсон, Крис Браун, Гэри Кобб:
Программная ошибка - ни что иное, как изьян в разработке программного продукта, который вызывает несоответствие ожидаемых результатов выполнения программного продукта и фактически полученных результатов.
“Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах” Роман Савин
Итак, баг (bug) — это отклонение фактического результата (actual result) от ожидаемого результата (expected result).
В соответствии с законом исключенного третьего у нас есть баг при наличии любого фактического результата, отличного от ожидаемого.
В целом, разработчики различают дефекты программного обеспечения и сбои. В случае сбоя программа ведёт себя не так, как ожидает пользователь. Дефект — это ошибка/неточность, которая может быть (а может и не быть) следствием сбоя.
Мое определение.
Дефект - поведение программы, затрудняющее или делающее невозможным достижение целей пользователя или удовлетворение интересов участников. Подразумевает возможность исправления. При невозможности исправления переходит в разряд ограничения технологии.
“Интересы участников” - следует понимать в значении А. Коберна.
7 Апрель 2008 в 18:41
Трудно согласиться: грамматическая ошибка - тоже баг, интерфейсный, однако он ничего не затрудняет.
У вас в определении дефекта, кстати, тоже есть баг. Надо бы вот так:
Дефект - поведение программы, затрудняющЕЕ или делающЕЕ
7 Апрель 2008 в 20:34
- Нул посчемтудже. Обдилие отрагравитестикх огшибхог зруднуят ралту с по.
Ну почему же. Обилие орфографических ошибок затрудняет работу с ПО.
За найденный баг спасибо. Все таки идея отдавать статьи на вычитку корректору и рецензенту не лишена привлекательности.
PS. Да. На этом блоге премодерация.
7 Апрель 2008 в 21:13
И самое важное. Отдельная орфографическая ошибка может быть и не затрудняет достижение цели пользователем, но наносит удар по репутации производителя и издателя. Т.е. затрудняет или делает невозможным удовлетворение интересов участников. Замечу, что участники - понятие более широкое, чем пользователь. Участник может даже не знать о существовании программы, но при этом его интересы могут страдать из-за некорректного поведения программы.
В этом отличие моего определения от остальных.
8 Апрель 2008 в 09:12
Сергей, посмотри вот здесь интересную коллекцию терминов: 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”
19 Апрель 2008 в 12:32
Считаю, что к вашему определению следует добавить важное граничное условие.
Помимо принципиальной реализуемости правильного варианта, нужно чтобы реализация этого варианта входила в установленные рамки (scope) проекта.
20 Апрель 2008 в 16:54
> Помимо принципиальной реализуемости правильного варианта, нужно чтобы
> реализация этого варианта входила в установленные рамки (scope) проекта.
Скорее да, чем нет.
Но здесь мы плавно переходим к “запросам на изменения”. Что начинает уводить разговор в сторону анализа бизнес требований.
21 Апрель 2008 в 10:03
Если мы привязываем понятие качества к соответствию требованиям, то управление требованиями никак не является посторонней темой.
В свое время довелось лично наблюдать, как контроль качества на основании общих представлений о том, что “любой продукт должен обладать свойствами A, B и C) давал в разы меньше ценных результатов, чем то же самое, но с учетом целей текущего этапа проекта.
Вывод, который я сделал для себя тогда — контроль качества без привязки к задачам проекта так же бесполезен, как создание “общей платформы для решения любых задач” в разработке.
13 Май 2008 в 11:44
И все таки дефект - это несоответствие реализованного продукта предъявляемым к нему требованиям. Требования, в свою очередь, могут быть функциональными, требованиями к интерфейсу и т.п. В конце концов сам специалист по тестированию может предъявлять дополнительные требования к тестируемому продукту.