Отличие бага от ошибки

Чем же они отличаются? Почитайте веселую историю и вспомнить отличие будет легко без подсматривания в гугл!

В летней школе тестировщиков Алексей Баранцев вел тренинг для продвинутых, как искать баги и исследовать приложение. Он задал простой вопрос → «Чем отличаются ошибка, дефект и сбой?». Предположения были самыми разнообразными, но уловить тонкую грань отличий никто не смог. Алексей мог зачитать умные слова из справочника 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. Возможно, именно вас не хватает в нашей команде!

А чтобы узнать больше о типах тестирования и их классификации, предлагаем вам просмотреть статью Типы тестирования.

После того, как разработчик получил баг-репорт, он приступает к исправлению бага. Но, прежде чем ошибку исправить, нужно ее воспроизвести, понять, как она происходит и где ее найти в коде. Дебаг, буквально “de”+”bug” — это и есть процесс поиска и устранения ошибок в коде. Специальная debug-версия билда приложения может иметь расширенный вывод для более информативных логов или любые другие модификации для упрощения понимания проблемы. Тактика отладки может включать интерактивную отладку, анализ потока управления, модульное тестирование, интеграционное тестирование, анализ логов, мониторинг на уровне приложения или системы, дампы памяти и профилирование. Многие языки программирования и инструменты разработки программного обеспечения также предлагают программы для помощи в отладке, известные как отладчики/дебаггеры.

Several terminologies are used in the field of software development to characterise problems that can arise in software systems and applications. These phrases include «bug,» «defect,» «error,» «fault,» and «failure,» yet they are frequently used synonymously, which causes misunderstanding among stakeholders and developers. In order to effectively communicate and solve problems in the software development industry, it is crucial to comprehend the differences between these phrases.

What are Bugs?

An mistake, flaw, or fault in a computer programme or system that makes it act unexpectedly or produce inaccurate or undesired consequences is known as a bug in the software development industry. Incomplete or confusing specifications, unanticipated inputs or situations, hardware or other software issues, programming errors, and other factors can all result in bugs.

From simple annoyances to major failures that might result in data loss, system crashes, or security vulnerabilities, bugs can have a wide range of effects. Software engineers utilise a range of methods, including testing, code reviews, and automated analysis tools, to find and correct flaws before they are incorporated into live systems in order to prevent defects.

What are Defects?

A software application or system defect is a different name for a bug, fault, or flaw that prevents it from operating as intended. Several things, like programming errors, design faults, or insufficient testing, might lead to defects.

Defects, like bugs, can be avoided by implementing various quality assurance procedures like testing, code reviews, and automated analysis. Software engineers must address and correct faults once they have been found in order for the system or application to function as intended.

What are Errors?

An error in software development is a mistake that a software developer makes when writing code. Mistakes can be brought about by a number of things, including a lack of expertise or experience, a misunderstanding of the requirements or the design, or just an accident.

Software engineers apply a number of approaches to avoid problems, including creating clear and succinct code, checking their work, and employing automated analysis tools to find flaws. When mistakes do happen, programmers must find them through debugging and testing to guarantee that the software operates properly.

What are Faults?

A fault in software development is a flaw that can make a software application or system malfunction or give inaccurate results. A flaw is typically brought about by a coding or design problem in the software that leads to an unexpected behaviour when the programme is run.

Software developers utilise a variety of methods to ensure that their work is strong and trustworthy, including testing, design reviews, and cautious coding procedures. When errors do arise, programmers employ debugging techniques to locate and address the root cause in order to return the software to normal operation.

What are Failures?

A failure in software development is when a system or software programme falls short of user expectations or intended requirements. Failure can happen when a flaw or defect in the software causes unanticipated behaviour, which prevents it from carrying out the intended function.

Software developers employ a range of strategies, such as thorough testing and quality assurance procedures, to guarantee that their software satisfies the intended criteria and performs dependably in order to prevent failures. When a failure happens, developers must look into the underlying reason and take the necessary steps to rectify it, such as addressing the flaw or defect that gave rise to the failure.

Bugs vs Defect vs Error vs Fault vs Failure

Let us now compare and contrast the different features of Bugs, Defects, Errors, Faults, and Failures:

Definition

• Bug − It is a colloquial term used to describe a defect.

• Defect − The discrepancy between actual results and anticipated outputs is known as the defect.

• Error − Since an error is a mistake in the code, we are unable to execute or compile the code.

• Fault − A Fault is a condition that prevents the software from doing its fundamental task.

• Failure − If the software has several flaws, it will fail or will be the cause of failure.

Raised By

• Bug − Bugs are reported by the test engineers.

• Defect − Defects are found by the testers. Also, the developer addressed it at the early stages of development.

• Error − Errors are brought up by the developers and automated test engineers.

• Fault − Faults are caused by human errors.

• Failure − During the development cycle, the manual test engineers discover the failure.

Different Types

• Bug − Logic bugs, Algorithmic bugs, Resource bugs

• Defect − Based on priority: High, Medium, Low. Based on severity: Critical, Major, Minor, Trivial early stages of development.

• Error − Syntactic mistake, an interface flaw, mistake in flow control, mistake in error handling, Calculation blunder, Testing mistake with hardware

• Fault − Errors in Business Logic, Logic and Functional Errors, Poor GUI Performance Issues, Security Errors, Hardware/software error

• Failure − No categories

Causes

• Bug − Lack of coding, incorrect coding, added coding

• Defect − Giving inaccurate and incorrect inputs. Problems and mistakes in the internal structure and design as well as external behaviour. The software is affected by a coding or logic problem, which results in its failure or breakdown.

• Error − Errors in the code. The Mistake of some values. If a developer is unable to compile or run a program successfully. Confusions and issues in programming. Misperception in understanding the requirements of the application.

• Fault − An incorrect step in the initial stage, procedure, or data definition might result in a fault. Issue or inconsistency with the program. A flaw or irregularity in the program that causes it to function incorrectly.

• Failure − Environmental condition, System usage, Human error

Way to Prevent the Causes

• Bug − Development that is test-driven. Support for programming languages. Adjusting cutting-edge and practical development techniques. Systematising the code evaluation.

• Defect − Using a variety of cutting-edge programming techniques. Use of fundamental and accurate software development methodologies. Performing regular code reviews to assess the quality and accuracy of the code.

• Error − Reviewing the system and code will improve the software’s quality. Find the problems and create a good mitigation strategy. Verify the fixes’ accuracy and quality by validating them.

• Fault − Peer evaluation. Evaluate the software’s functional requirements. Carry out the thorough code analysis. Check the programming and design of the software.

• Failure − Verify the retesting. Study the specifications and go over the requirements. Put existing safety measures into practise. Sort and rank errors and problems.

Conclusion

Understanding the terms that are used for describing software problems is crucial for software development. Although they all contain somewhat similar notions, bugs, defects, mistakes, faults, and failures have slightly distinct definitions. In contrast, an error refers to a mistake made by a developer when developing code, a bug or defect refers to a flaw or error in the software.

В таком случае, как менеджер тестов, что вы будете делать?

А) Согласиться с командой тестирования, что это дефект
Б) Менеджер теста берет на себя роль судьи, чтобы решить, является ли проблема дефектом или нет
В) договориться с командой разработчиков, что не является дефектом

Для разрешения конфликта, вы (менеджер проекта) берете на себя роль судьи, который решает, является ли проблема продукта дефектом или нет.

Категории ошибок

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

Критический – дефект должен быть устранены немедленно, иначе это может привести к большим потерям для продукта
Например: функция входа на сайт не работает должным образом.
Вход в систему является одной из основных функций банковского сайта, если эта функция не работает, это серьезные ошибки.

Высокий – дефект негативно влияет на основные функции продукта
Например: производительность сайта слишком низкая.

Средний – дефект вносит минимальные отклонения от требований к к продукту
Например: не корректно отображается интерфейс на мобильных устройствах.

Низкий – минимальное не функциональное влияние на продукт
Например: некоторые ссылки не работают.

Решение

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

• Назначение: проблемы отправлены разработчику или другому техническому специалисту для исправления и изменило статус на отвечающий.
• График устранения: сторона разработчика берет на себя ответственность на этом этапе, они создадут график для устранения этих дефектов в зависимости от их приоритета.
• Исправление: пока группа разработчиков устраняет дефекты, диспетчер тестов отслеживает процесс устранения проблем, исходя из графика.
• Сообщить о решении: получите отчет об устранении бага от разработчиков, когда дефекты устранены.

Верификация

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

Закрытие

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

Составление отчетов

Далее вы должны сообщить правлению текущую ситуацию с дефектами, чтобы получить от них обратную связь. Они должно видеть и понимать процесс управления дефектами, чтобы поддержать вас в случае необходимости.

Как измерить и оценить качество выполнения теста?

Это вопрос, который хочет знать каждый менеджер в тестировании. Есть 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%. Это означает, что качество выполнения теста низкое.

Чтобы уменьшить эти коэффициенты:

• Улучшите навыки тестирования участников проекта.
• Тратьте больше времени на выполнение тестов и на просмотр результатов.