Asked
Viewed
7k times
I was reading the differences between defect, error, bug and failure. I found a website that says about them. Are these correct?
“A mistake in coding is called error, error found by tester is
called defect, defect accepted by development team then it is called
bug , build does not meet the requirements then it Is failure.”Error: A discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct
value or condition. This can be a misunderstanding of the internal
state of the software, an oversight in terms of memory management,
confusion about the proper way to calculate a value, etc.Failure: The inability of a system or component to perform its required functions within specified performance requirements. See:
bug, crash, exception, and fault.Bug: A fault in a program which causes the program to perform in an unintended or unanticipated manner. See: anomaly, defect, error,
exception, and fault. The bug is terminology of Tester.Fault: An incorrect step, process, or data definition in a computer program which causes the program to perform in an unintended
or unanticipated manner. See: bug, defect, error, exception.Defect: Commonly refers to several troubles with the software products, with its external behavior or with its internal features.
Source: Click here
Bharat Mane
6,78510 gold badges39 silver badges67 bronze badges
asked Apr 19, 2017 at 14:42
1
ISQTB foundation level material states the following:
A human being can make an error (mistake), which produces a defect
(fault, bug) in the program code, or in a document.If a defect in code is executed, the system may fail to do what it
should do (or do something it shouldn’t), causing a failure.Defects in software, systems or documents may result in failures, but
not all defects do so.
If you read this definition carefully, I think it is pretty self-explanatory.
answered Apr 20, 2017 at 7:44
1
As with most testing terminology it depends on the company, person and or industry. It is a means to communicate. When in doubt ask what people mean with it within its context.
For me bugs and defects are the same. Bugs are something from the 40ties according to Wikipedia.
featuring a dead moth that was removed from the device
I would push for calling all bugs defects instead, because dead animals do not anymore block computer systems.
Coding mistakes are just coding mistakes, they could cause errors.
An ‘error’ is a deviation from accuracy or correctness. A ‘mistake’ is
an error caused by a fault: the fault being misjudgment, carelessness,
or forgetfulness. Now, say that I run a stop sign because I was in a
hurry, and wasn’t concentrating, and the police stop me, that is a
mistake. If, however, I try to park in an area with conflicting signs,
and I get a ticket because I was incorrect on my interpretation of
what the signs meant, that would be an error. The first time it would
be an error. The second time it would be a mistake since I should have
known better.https://en.wikipedia.org/wiki/Error
For build failures. Hmm. I think if the build cannot build it is a build failure. When it does not meet its requirements it just a defect, or an improvements depending on its classification. Calling it a failure does not add a lot of value. Still it might fail as a product, because its requirements were not met, but is the build a failure? Only time will tell, maybe the requirements were wrong to start with.
So from my perspective that quote you found on a website is not correct, but I think I could also create an argument for it being valid. 
answered Apr 19, 2017 at 15:18
Honestly, it depends on the organization, the developement methodology, and the QA guidelines. You could say a defect is simply a bug report, a bug is a confirmed bug, an error is a user-facing error (or is user error — an error caused by the user), a fault is a type of bug, and a failure is when, for any number of reasons, the system does not meet the agreed upon standards or metrics that it was designed to meet.
All of these change depending on your organization and personal opinion. A website that expects 50 purchases per day and is very well designed and bug free, but only nets 49 purchases per day could be called a failure by management, despite being bug, defect, and error free.
answered Jun 12, 2017 at 22:13
In today’s world of software functional testing services these are some terms that requires clarification and below
are the details:
Error:
Error is a human action that produces an incorrect result. It is deviation from actual and expected value. The mistakes made by programmer is known as an ‘Error’.
Failure:
Failure is a deviation of the software from its intended purpose. It is the inability of a system or a component to perform its required functions within specified requirements.
Bug:
A Bug is the result of a coding Error or Fault in the program which causes the program to behave in an unintended or unanticipated manner. Bugs arise from mistakes and errors, made by people, in either a program’s source code or its design.
Fault or Defect:
A Defect is a deviation from the Requirements. A Defect is a condition in a software product which does not meet a software requirement. In other words, a defect is an error in coding or logic that causes a program to malfunction or to produce incorrect/unexpected result. This could be hardware, software, network, performance, format, or functionality.
Conclusion:
A Bug is the result of a coding Error and A Defect is a deviation from the Requirements. A defect does not necessarily mean there is a bug in the code, it could be a function that was not implemented but defined in the requirements of the software.
answered Jun 15, 2017 at 12:13
AnandAnand
7634 silver badges8 bronze badges
- Подробнее
- Таблица
Промах, допущенный человеком при создании кода, называется Error. Ошибка, найденная на этапе тестирования, называется дефектом (Defect). Дефект, который должен быть устранен разработчиком, называется багом (Bug). Если функция не работает, это называется сбоем (Fault). Failure — полный отказ системы.
Понятия Error, Defect, Fault, Bug и Failure
Bug (баг)
Баг — это ситуация, возникающая, когда продукт (приложение) не соответствует утвержденным ранее требованиям. Если где-то в коде допущена ошибка, она провоцирует «поломку» кода, и приложение работает некорректно. Такую ситуацию тестировщики называют багом. Найденный баг может быть воспроизведен, то есть воссозданы условия, при которых он возникает.
Defect (дефект)
Дефект — это ситуация, при которой приложение не работает соответственно требованиям, то есть отличается ожидаемое и действительное поведение продукта.
Error (ошибка)
Error — это ситуация, которая происходит когда разработчики неправильно понимают требования к продукту, и это приводит к багам.
Fault (сбой)
Ситуация, когда приложение не может правильно функционировать. Например, из-за недостатка свободной памяти или места на диске, или невыполнения каких-то нужных действий.
Failure (отказ)
Сочетание дефектов, которые приводят к полному отказу приложения, обычно с потерей данных, в том числе критически важных; система не реагирует на действия пользователя. Обычно такие ситуации происходят редко — перед релизом продукта тестируются возможные сценарии.
Таблица: Bug — Defect — Error — Fault — Failure
| Bug (баг) | Defect (дефект) | Fault (сбой) | Error (ошибка) | Failure (отказ) | |
|---|---|---|---|---|---|
| Описание проблемы | Продукт не работает как должен работать соответственно требованиям | Несоответствие полученного и ожидаемого результата | Состояние приложения, при котором оно не выполняет свою функцию | Ошибка, допущенная в коде, при компиляции или выполнении, из-за которой происходит Fault | Серьезный дефект или их сочетание, приводящее к полному отказу приложения, потере данных и потере управления приложением |
| Кто сталкивается | Тестировщики | Находят тестировщики и устраняют разработчики | Пользователи | Тестировщики и разработчики | Тестировщики и пользователи |
| Какие типы бывают | Много типов, чаще всего: — Логические баги — Алгоритмические баги — Баги распределения системных ресурсов |
— Высокий, средний и низкий приоритет — Критическая, большая, малая и очень низкая серьезность |
— Бизнес-логики — Функциональные — Интерфейса — Производительности — Аппаратные |
— Синтаксические ошибки — Ошибки в интерфейсе — Ошибки рантайма — Ошибки вычислений — Аппаратные ошибки |
Неработоспособность приложения, по разным причинам |
| Причины возникновения | — Ошибки в логике приложения — Дефектный код |
— Получение и передача некорректных данных, из-за некорректной логики/архитектуры/другие причины | — Неправильная архитектура приложения — Неправильная логика приложения |
— Ошибки в коде — Ошибки в логике — Неспособность приложения к компиляции и выполнению — Неправильно понятые требования — Неправильная архитектура приложения |
— Некорректные переменные окружения — Системные ошибки — Человеческие ошибки |
| Как предотвратить | — Разработка через тестирование (TDD) — И другие современные практики разработки и тестирования, стимулирующие «чистоту кода» |
— Внедрение современных практик разработки — Правильное применение существующих практик |
— Проверка кода и требований другими участниками команды — Тщательная верификация архитектуры и кода |
— Проверка кода другими участниками команды — Валидация багфиксов |
— Повторное тестирование — Тщательное сквозное тестирование — Проверка требований/спецификаций — Категоризация ошибок и проблем |
Источник
В таком случае, как менеджер тестов, что вы будете делать?
А) Согласиться с командой тестирования, что это дефект
Б) Менеджер теста берет на себя роль судьи, чтобы решить, является ли проблема дефектом или нет
В) договориться с командой разработчиков, что не является дефектом
Для разрешения конфликта, вы (менеджер проекта) берете на себя роль судьи, который решает, является ли проблема продукта дефектом или нет.
Категории ошибок
Классификация дефектов помогает разработчикам программного обеспечения определять приоритеты своих задач и в первую очередь устранить те дефекты, которые больше прочих угрожают работоспособности продукта.
Критический – дефект должен быть устранены немедленно, иначе это может привести к большим потерям для продукта
Например: функция входа на сайт не работает должным образом.
Вход в систему является одной из основных функций банковского сайта, если эта функция не работает, это серьезные ошибки.
Высокий – дефект негативно влияет на основные функции продукта
Например: производительность сайта слишком низкая.
Средний – дефект вносит минимальные отклонения от требований к к продукту
Например: не корректно отображается интерфейс на мобильных устройствах.
Низкий – минимальное не функциональное влияние на продукт
Например: некоторые ссылки не работают.
Решение
После того, как дефекты приняты и классифицированы, вы можете выполнить следующие шаги, чтобы исправить их.
- Назначение: проблемы отправлены разработчику или другому техническому специалисту для исправления и изменило статус на отвечающий.
- График устранения: сторона разработчика берет на себя ответственность на этом этапе, они создадут график для устранения этих дефектов в зависимости от их приоритета.
- Исправление: пока группа разработчиков устраняет дефекты, диспетчер тестов отслеживает процесс устранения проблем, исходя из графика.
- Сообщить о решении: получите отчет об устранении бага от разработчиков, когда дефекты устранены.
Верификация
После того, как команда разработчиков исправила дефект и сообщила об этом, команда тестирования проверяет, действительно ли устранены все заявленные дефекты.
Закрытие
После устранения и проверки дефекта его статус меняется на закрытый. Если он не устранен, вы отправляете уведомление в отдел разработки, чтобы они проверили дефект еще раз.
Составление отчетов
Далее вы должны сообщить правлению текущую ситуацию с дефектами, чтобы получить от них обратную связь. Они должно видеть и понимать процесс управления дефектами, чтобы поддержать вас в случае необходимости.
Как измерить и оценить качество выполнения теста?
Это вопрос, который хочет знать каждый менеджер в тестировании. Есть 2 параметра, которые вы можете рассмотреть следующим образом…
В приведенном выше сценарии можно рассчитать коэффициент отклонения брака (DRR), равный 20/84 = 0,238 (23,8%).
Другой пример: предположительно, в продукте всего 64 дефекта, но ваша группа по тестированию обнаружила только 44 дефекта, т.е. они пропустили 20 дефектов. Следовательно, можно рассчитать коэффициент утечки дефектов (DLR), равный 20/64 = 0,312 (31,2%).
Вывод, качество выполнения теста оценивается по следующим двум параметрам.
Defect reject ratio (DRR) – 23,8%
Defect leakage ratio (DLR) – 31,2%
Чем меньше значение DRR и DLR, тем, соответственно, лучше качество тестирования. Какой диапазон коэффициентов является приемлемым? Этот диапазон может быть определен и принят за основу в проекте исходя из целей, или вы можете ссылаться на показатели аналогичных проектов.
В рассматриваемом нами проекте рекомендуемое значение показателей качества тестирования должно составлять 5 ~ 10%. Это означает, что качество выполнения теста низкое.
Чтобы уменьшить эти коэффициенты:
- Улучшите навыки тестирования участников проекта.
- Тратьте больше времени на выполнение тестов и на просмотр результатов.
Чем же они отличаются? Почитайте веселую историю и вспомнить отличие будет легко без подсматривания в гугл!
В летней школе тестировщиков Алексей Баранцев вел тренинг для продвинутых, как искать баги и исследовать приложение. Он задал простой вопрос → «Чем отличаются ошибка, дефект и сбой?». Предположения были самыми разнообразными, но уловить тонкую грань отличий никто не смог. Алексей мог зачитать умные слова из справочника ISTQB, но предпочел рассказать историю. Три года прошло! Я помню историю до сих пор и могу назвать отличия без подглядывания в гугл 
Вступление от Алексея — придумал историю не сам. На одном из тренингов я задал этот вопрос. Девочки посовещались между собой и сказали: «Мы не можем объяснить это с точки зрения ПО, но можем на примере шитья». Я удивился и сказал: «Давайте!».
Жил-был мастер. Он шил платья на заказ. Однажды он допустил ошибку — забыл прошить нижний край у кармана платья.
Результатом ошибки стал дефект. Платье висело на вешалке и выглядело абсолютно нормально, но оно было с дефектом.
Маленькая девочка увидела платье и сразу влюбилась. Она купила платье и носила его повсюду. И все было хорошо, платье сидело замечательно, дефект никак не проявлялся. Пока новая хозяйка не решила положить в карман ключ.
Девочка опустила руку в карман, отпустила ключ… У-у-у-упс, ключ выпал на пол! Произошелсбой в системе — проявился ранее скрытый дефект.
Точно также бывает и в ПО → разработчики допускают ошибки при написании кода и в программе затаивается дефект. И даже если дефект не нашли и о нем никто не знает, он все равно есть! Сидит и ждет своего часа. И когда пользователь натыкается на ошибочный код, происходит сбой.
Официальное определение
А под конец немножко официоза — версия из ISTQB:
A human being can make an error (mistake), which produces a defect (fault, bug) in the code, in software or a system, or in a document. If a defect in code is executed, the system will fail to do what it should do (or do something it souldn’t), causing a failure. Defects in software, systems or documents may result in failures, but not all defects do so.
Человек может допустить ошибку, которая приводит к дефекту (к неисправности, багу) в коде, в софте или системе, или документе. Если дефект в коде исполняется, система не сможет сделать то, что должна (или то, что не должна), что вызовет сбой. Дефекты в программном обеспечении, системах или документах, могут вызвать неисправности, но не все дефекты вызывают их.
© Оригинальный блог-пост
Знали ли вы, что термина «баг» официально не существует? Этим словом ошибочно называют все проблемы, возникающие в коде – но будущим QA инженерам этой информации должно быть недостаточно. Вооружаемся словарем ISTQB, помощью экспертов EPAM и рассказываем о четырех базовых терминах, которые должен знать каждый тестировщик.
Начнем с простого!
Что такое «баг»?
Баг (официально – «defect«, синонимы «bug», «fault») – это, обобщенно говоря, любой недостаток в продукте, из-за которого этот самый продукт не соответствует требованиям. То есть, если вместо числа от 1 до 9 функция почему-то выдает полный текст Конституции, где-то произошел баг и продукт надо фиксить.
Требования закладываются еще до начала работы над проектом; на них основывается ожидаемый функционал продукта, который уже позже будет проверять тестировщик. Как только в системе появляется отклонение – QA специалист «заводит» баг, который должен исправить разработчик.
История термина «баг» очень интересная: 9 сентября 1945 ученые Гарвардского университета обнаружили в вычислительной машине настоящую бабочку, застрявшую в электромеханическом реле. Это насекомое они добавили в технический журнал с подписью: «Первый задокументированный случай нахождения бага».
Что такое «ошибка»?
Ошибка (официально — «error», синоним «mistake»): это, согласно ISTQB, любое действие человека, которое вызвало неверный результат. Это может быть как неправильно введенный пароль, который вызвал error 403, так и ошибка в коде, которую допустил разработчик, и из-за которой «случайно» упали серверы.
Баг может быть вызван ошибкой, но ошибка ≠ баг, ведь, как в случае неверного пароля, это – ожидаемое поведение системы. Говоря проще, ошибка может быть результатом дефекта, а может быть одним из «правильных» ответов на неправильные действия пользователей.
Что такое «отказ»?
Отказ (официально – «failure», также встречается вариант «interruption»). Полное определение с ISTQB – «событие, при котором система не выполняет ожидаемую функцию». Но зачем использовать отдельный термин, который означает почти то же, что и баг?
Но эти понятия разные! Если объяснять ну ооочень упрощенно, баг находят на этапе тестирования системы, а отказ – когда продукт уже выпущен в публичное пользование. Чтобы лучше понять разницу между багом (дефектом), ошибкой и отказом, визуализируйте следующую аналогию.
Представьте обычного швейного мастера, который создает пальто. В одном из изделий мастер случайного не пристрочил карман – таким образом, мастером была допущена ошибка (error). Пальто спокойно висело на вешалке – на первый взгляд, совершенно обычное, но теперь мы знаем, что в нем «завелся» баг (defect). Дефект является незаметной на первый взгляд ошибкой, которая может не влиять на работу системы в обычном состоянии; однако, при чрезмерной нагрузке (как один из возможных вариантов) дефект дает о себе знать и становится причиной отказа. Итак, пальто с дефектом (или багом) приобрел человек и попытался положить в карман телефон, который сразу же оттуда выпал. Пальто (или его карман) не выполнило ожидаемую функцию – телефон должен был остаться в кармане в безопасности.
Представьте себе масштабы ситуации, если целая фабрика станет производить пальто с дефектами! Именно поэтому профессия тестировщика является настолько ответственной: задачей такого специалиста является найти, а затем воспроизвести, или даже разобраться в причинах ошибки.
Что такое «аномалия»?
Аномалия (официально «anomaly», или «deviation») – это собирательный термин, под которым может иметься ввиду и баг, и отказ, и ошибка. Аномалия является широким термином, который можно использовать в любой ситуации, где что-то идет не по плану (например: «Я сегодня аномально устал, поэтому все таски выполню завтра» или «В коде произошла аномалия, и вместо калькулятора у меня случайно написался искусственный интеллект»).
Поздравляем, теперь вы немного ближе знакомы с профессией тестировщика! И если вы точно знаете, что поиск дефектов и совершенствование систем является вашим призванием – присоединяйтесь к наборам по направлению Software Testing в EPAM. Возможно, именно вас не хватает в нашей команде!
А чтобы узнать больше о типах тестирования и их классификации, предлагаем вам просмотреть статью Типы тестирования.