- Подробнее
- Таблица
Промах, допущенный человеком при создании кода, называется 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) — И другие современные практики разработки и тестирования, стимулирующие «чистоту кода» |
— Внедрение современных практик разработки — Правильное применение существующих практик |
— Проверка кода и требований другими участниками команды — Тщательная верификация архитектуры и кода |
— Проверка кода другими участниками команды — Валидация багфиксов |
— Повторное тестирование — Тщательное сквозное тестирование — Проверка требований/спецификаций — Категоризация ошибок и проблем |
Источник
После того, как разработчик получил баг-репорт, он приступает к исправлению бага. Но, прежде чем ошибку исправить, нужно ее воспроизвести, понять, как она происходит и где ее найти в коде. Дебаг, буквально “de”+”bug” — это и есть процесс поиска и устранения ошибок в коде. Специальная debug-версия билда приложения может иметь расширенный вывод для более информативных логов или любые другие модификации для упрощения понимания проблемы. Тактика отладки может включать интерактивную отладку, анализ потока управления, модульное тестирование, интеграционное тестирование, анализ логов, мониторинг на уровне приложения или системы, дампы памяти и профилирование. Многие языки программирования и инструменты разработки программного обеспечения также предлагают программы для помощи в отладке, известные как отладчики/дебаггеры.
В таком случае, как менеджер тестов, что вы будете делать?
А) Согласиться с командой тестирования, что это дефект
Б) Менеджер теста берет на себя роль судьи, чтобы решить, является ли проблема дефектом или нет
В) договориться с командой разработчиков, что не является дефектом
Для разрешения конфликта, вы (менеджер проекта) берете на себя роль судьи, который решает, является ли проблема продукта дефектом или нет.
Категории ошибок
Классификация дефектов помогает разработчикам программного обеспечения определять приоритеты своих задач и в первую очередь устранить те дефекты, которые больше прочих угрожают работоспособности продукта.
Критический – дефект должен быть устранены немедленно, иначе это может привести к большим потерям для продукта
Например: функция входа на сайт не работает должным образом.
Вход в систему является одной из основных функций банковского сайта, если эта функция не работает, это серьезные ошибки.
Высокий – дефект негативно влияет на основные функции продукта
Например: производительность сайта слишком низкая.
Средний – дефект вносит минимальные отклонения от требований к к продукту
Например: не корректно отображается интерфейс на мобильных устройствах.
Низкий – минимальное не функциональное влияние на продукт
Например: некоторые ссылки не работают.
Решение
После того, как дефекты приняты и классифицированы, вы можете выполнить следующие шаги, чтобы исправить их.
- Назначение: проблемы отправлены разработчику или другому техническому специалисту для исправления и изменило статус на отвечающий.
- График устранения: сторона разработчика берет на себя ответственность на этом этапе, они создадут график для устранения этих дефектов в зависимости от их приоритета.
- Исправление: пока группа разработчиков устраняет дефекты, диспетчер тестов отслеживает процесс устранения проблем, исходя из графика.
- Сообщить о решении: получите отчет об устранении бага от разработчиков, когда дефекты устранены.
Верификация
После того, как команда разработчиков исправила дефект и сообщила об этом, команда тестирования проверяет, действительно ли устранены все заявленные дефекты.
Закрытие
После устранения и проверки дефекта его статус меняется на закрытый. Если он не устранен, вы отправляете уведомление в отдел разработки, чтобы они проверили дефект еще раз.
Составление отчетов
Далее вы должны сообщить правлению текущую ситуацию с дефектами, чтобы получить от них обратную связь. Они должно видеть и понимать процесс управления дефектами, чтобы поддержать вас в случае необходимости.
Как измерить и оценить качество выполнения теста?
Это вопрос, который хочет знать каждый менеджер в тестировании. Есть 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.
Человек может допустить ошибку, которая приводит к дефекту (к неисправности, багу) в коде, в софте или системе, или документе. Если дефект в коде исполняется, система не сможет сделать то, что должна (или то, что не должна), что вызовет сбой. Дефекты в программном обеспечении, системах или документах, могут вызвать неисправности, но не все дефекты вызывают их.
© Оригинальный блог-пост
Давайте посмотрим, в чем разница между дефектом, багом, ошибкой и сбоем. Как правило, мы используем эти термины всякий раз, когда система/приложение работает ненормально. Иногда мы называем это ошибкой, иногда ошибкой и так далее. Многие новички в индустрии тестирования программного обеспечения не могут использовать это.
В чем разница между дефектом, багом, ошибкой и сбоем — это один из вопросов на собеседовании при приеме на работу новичка.
Как правило, существует противоречие в использовании этих терминов. Обычно в жизненном цикле разработки программного обеспечения мы используем эти термины в зависимости от фазы.
Примечание. И дефект, и ошибка являются проблемами в приложении, но общая разница заключается в том, на каком этапе SDLC они были обнаружены.
Посмотрите видео ниже, чтобы увидеть «Разница между дефектом, ошибкой и ошибкой»
Что такое дефект?
Разница между фактическими и ожидаемыми результатами называется дефектом.
Если разработчик находит проблему и исправляет ее самостоятельно на этапе разработки, это называется дефектом.
Что такое ошибка?< /strong>
Если тестировщики обнаруживают какие-либо несоответствия в приложении/системе на этапе тестирования, они называют это ошибкой.
Как я упоминал ранее, существует противоречие в использовании Ошибка и дефект. Многие говорят, что баг — это неофициальное название дефекта.
Что такое ошибка?
Мы не можем скомпилировать или запустить программу из-за ошибки кода в программе. Если разработчик не может успешно скомпилировать или запустить программу, он называет это ошибкой.
Что такое ошибка?
После того, как продукт развертывается, и клиенты обнаруживают какие-либо проблемы, после чего они называют продукт неудачным продуктом. После выпуска, если конечный пользователь обнаруживает проблему, эта конкретная проблема называется сбоем
Важно знать:
Если аналитик качества (QA) обнаруживает ошибку, он должен воспроизвести и записать его, используя шаблон отчета об ошибке.
Ранее я разместил подробный пост в разделе «Шаблон отчета об ошибке». Если вы еще не ознакомились с ним, вы можете просмотреть его, нажав здесь.
Кроме того, вы можете скачать Образец шаблона отчета об ошибках/Шаблон отчета о дефектах отсюда.
Не забудьте поделиться этим сообщением со всеми, кому оно может быть полезно эту информацию, включая ваших друзей в Facebook, подписчиков в Twitter, подписчиков в LinkedIn и участников вашей группы Google+!
TAG: qa