В таком случае, как менеджер тестов, что вы будете делать?
А) Согласиться с командой тестирования, что это дефект
Б) Менеджер теста берет на себя роль судьи, чтобы решить, является ли проблема дефектом или нет
В) договориться с командой разработчиков, что не является дефектом
Для разрешения конфликта, вы (менеджер проекта) берете на себя роль судьи, который решает, является ли проблема продукта дефектом или нет.
Категории ошибок
Классификация дефектов помогает разработчикам программного обеспечения определять приоритеты своих задач и в первую очередь устранить те дефекты, которые больше прочих угрожают работоспособности продукта.
Критический – дефект должен быть устранены немедленно, иначе это может привести к большим потерям для продукта
Например: функция входа на сайт не работает должным образом.
Вход в систему является одной из основных функций банковского сайта, если эта функция не работает, это серьезные ошибки.
Высокий – дефект негативно влияет на основные функции продукта
Например: производительность сайта слишком низкая.
Средний – дефект вносит минимальные отклонения от требований к к продукту
Например: не корректно отображается интерфейс на мобильных устройствах.
Низкий – минимальное не функциональное влияние на продукт
Например: некоторые ссылки не работают.
Решение
После того, как дефекты приняты и классифицированы, вы можете выполнить следующие шаги, чтобы исправить их.
- Назначение: проблемы отправлены разработчику или другому техническому специалисту для исправления и изменило статус на отвечающий.
- График устранения: сторона разработчика берет на себя ответственность на этом этапе, они создадут график для устранения этих дефектов в зависимости от их приоритета.
- Исправление: пока группа разработчиков устраняет дефекты, диспетчер тестов отслеживает процесс устранения проблем, исходя из графика.
- Сообщить о решении: получите отчет об устранении бага от разработчиков, когда дефекты устранены.
Верификация
После того, как команда разработчиков исправила дефект и сообщила об этом, команда тестирования проверяет, действительно ли устранены все заявленные дефекты.
Закрытие
После устранения и проверки дефекта его статус меняется на закрытый. Если он не устранен, вы отправляете уведомление в отдел разработки, чтобы они проверили дефект еще раз.
Составление отчетов
Далее вы должны сообщить правлению текущую ситуацию с дефектами, чтобы получить от них обратную связь. Они должно видеть и понимать процесс управления дефектами, чтобы поддержать вас в случае необходимости.
Как измерить и оценить качество выполнения теста?
Это вопрос, который хочет знать каждый менеджер в тестировании. Есть 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%. Это означает, что качество выполнения теста низкое.
Чтобы уменьшить эти коэффициенты:
- Улучшите навыки тестирования участников проекта.
- Тратьте больше времени на выполнение тестов и на просмотр результатов.
Improve Article
Save Article
Improve Article
Save Article
Generally, when the system/application does not act as per expectation or abnormally, we call it’s an error or it’s an fault and so on. Many of the newbies in Software Testing industry have confusion in using this, so let’s know what is the difference b/w defect, bug, error and failure. We will see these terms in detail one by one.
- Defect:
The bugs introduced by programmer inside the code is called as Defect.
Defect is defined as the deviation from the actual and expected result of application or software or in other words, defects are defined as any deviation or irregularity from the specifications mentioned in the product functional specification document. Defect is also solved by the developer in development phase or stage.
Reasons for Defects:
- Any deviation from the customer requirements is called as defect.
- By giving wrong input may lead to defect.
- Any error in logic code may lead to defect.
- Bug:
Sometimes most people are confused between defect and bug, they say that bug is the informal name of defect. Actually bugs are faults in system or application which impact on software functionality and performance. Usually bugs are found in unit testing by testers.There are different types of bugs, some of them are given below.
- Functional Errors
- Compilation Errors
- Missing commands
- Run time Errors
- Logical errors
- Inappropriate error handling
Above given these errors lead to bug.
- Failure:
When a defect reaches the end customer, it is called as Failure.
Once the product is completed and it is delivered to the customers and if the customer find any issues in product or software then it is the condition of failure of product.
In other words, if an end user finds an issue in product then that particular issue is called as failure.Causes of Failure:
- Human errors or mistakes may lead to failure.
- Environmental conditions
- The way in which system is used.
Flow of Bug to Defect:
Example:
Let’s see a defect by an example.
a=7
b=5
ans=a*b
print("Addition of {} and {} = {}.".format(a, b, ans))
When you compile and run this program you see the printed statement as below:
Addition of 7 and 5=35
This is program of adding two numbers but the output is deviated from it’s actual result which is 12. Now we have detected a failure. As the failure has been detected a defect can be raised.
Improve Article
Save Article
Improve Article
Save Article
Generally, when the system/application does not act as per expectation or abnormally, we call it’s an error or it’s an fault and so on. Many of the newbies in Software Testing industry have confusion in using this, so let’s know what is the difference b/w defect, bug, error and failure. We will see these terms in detail one by one.
- Defect:
The bugs introduced by programmer inside the code is called as Defect.
Defect is defined as the deviation from the actual and expected result of application or software or in other words, defects are defined as any deviation or irregularity from the specifications mentioned in the product functional specification document. Defect is also solved by the developer in development phase or stage.
Reasons for Defects:
- Any deviation from the customer requirements is called as defect.
- By giving wrong input may lead to defect.
- Any error in logic code may lead to defect.
- Bug:
Sometimes most people are confused between defect and bug, they say that bug is the informal name of defect. Actually bugs are faults in system or application which impact on software functionality and performance. Usually bugs are found in unit testing by testers.There are different types of bugs, some of them are given below.
- Functional Errors
- Compilation Errors
- Missing commands
- Run time Errors
- Logical errors
- Inappropriate error handling
Above given these errors lead to bug.
- Failure:
When a defect reaches the end customer, it is called as Failure.
Once the product is completed and it is delivered to the customers and if the customer find any issues in product or software then it is the condition of failure of product.
In other words, if an end user finds an issue in product then that particular issue is called as failure.Causes of Failure:
- Human errors or mistakes may lead to failure.
- Environmental conditions
- The way in which system is used.
Flow of Bug to Defect:
Example:
Let’s see a defect by an example.
a=7
b=5
ans=a*b
print("Addition of {} and {} = {}.".format(a, b, ans))
When you compile and run this program you see the printed statement as below:
Addition of 7 and 5=35
This is program of adding two numbers but the output is deviated from it’s actual result which is 12. Now we have detected a failure. As the failure has been detected a defect can be raised.
Очередной сайт «Software Quality Assurance Interview Questions and Answers» подкинул то, над чем я когда-то искренне смеялся:
20. What is Bug?
A fault in a program which causes the program to perform in an unintended or unanticipated manner.
20. What is Defect?
If software misses some feature or function from what is there in requirement it is called as defect.
Причина смеха: это же взаимозаменяемые понятия.
Но, с точки зрения грамматики, разница есть.
Толковый словарь говорит, что разница в терминах есть:
- Дефект
- недостаток,
- изъян,
- повреждение.
- Ошибка
- неправильность в действиях, поступках, суждениях, мыслях.
- отклонение от правильного употребления.
- погрешность.
- то, что невозможно рассчитать и предсказать заранее, опираясь на накопленные знания.
По этим выкладкам, наиболее близкий перевод для ‘bug’ > ‘ошибка’.
Дефект = ошибка?
Нет. Сам по себе дефект не ошибка. Дефект возникает как следствие ошибки. Но они сопутствуют друг другу, поэтому могут быть восприняты совместно.
В чем же их синонимность?
Ошибка:
грех, погрешность, заблуждение, неловкость, оплошность, опечатка, описка, отступление, промах, уклонение, упущение, неправильность, шероховатость, ложный шаг, провес, промер, просмотр, просчет, аномалия, уродливость. Сопутствующий термин: Недостаток.
Недостаток:
изъян, недосмотр, недочет, неисправность, неправильность, несовершенство, грех, порок, порча, повреждение, пробел, прореха, пятно, аномалия, дефект, слабость, слабое (больное) место, ахиллесова пята.
Следовательно,
> Ошибка
> > Недостаток
> > > Дефект.
Рассматривать эти термины совместно — можно. Подменять — нет.
Баг = ошибка = дефект — в зависимости от контекста.
Добавим перцу
и поговорим как английские лорды с милордами о той же пошаговой стратегии определения терминов:
Mistake
Ошибка. Человеческое деяние, которое в конечном итоге привело к получению неверного результата.
Сказал бы «неожиданного», но это уводит нас в другой контекст.
В широком смысле — непреднамеренное отклонение от истины или правил.
Оригинал: A human action that produces an incorrect result.
Fault
Дефект, изъян. Неверный шаг (или процесс, или определение данных) в компутерной программе. Первая причина для появления ошибки, потенциальная причина неисправности.
Оригинал: An incorrect step, process, or data definition in a computer program. The outgrowth of the mistake, potentially leads to failure.
Failure
Неисправность. Неправильный результат. Собственно, результат дефекта.
Оригинал: An incorrect result. The result of the fault (e.g. a crash).
Error
Невозможность выполнить задачу (или получить верный результат) вследствие того, что где-то случилась ошибка, которая привела к дефекту, который вызвал неисправность, которая привела к невозможности сделать то, чего мы тут намеревались (евангелие от Антивируса, стих 256, строка 00).
Оригинал: A failure to complete a task, usually involving a premature termination.
Есть еще один распространенный вариант» The amount by which the result is incorrect, но внятно перевести это на русский я не могу. Что-то вроде «насколько неправилен результат»…
Чем же они отличаются? Почитайте веселую историю и вспомнить отличие будет легко без подсматривания в гугл!
В летней школе тестировщиков Алексей Баранцев вел тренинг для продвинутых, как искать баги и исследовать приложение. Он задал простой вопрос → «Чем отличаются ошибка, дефект и сбой?». Предположения были самыми разнообразными, но уловить тонкую грань отличий никто не смог. Алексей мог зачитать умные слова из справочника 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
Какой же путь проходит баг и какую роль в его жизненном цикле играет тестировщик? Давайте разбираться.
Ошибка, дефект, но чаще всего баг. Именно так называется то, что находят тестировщики в процессе работы.
Определение бага
Bug в переводе означает “жук, насекомое”. Первая ошибка, которая была задокументирована, возникла как раз из-за жука. В середине 40-х годов 20 века ученых Гарвардского университета вызвали для того, чтобы определить причину сбоя в работе вычислительной машины Mark II. Покопавшись в этой громадной куче приборов, соединенных проводами, они обнаружили бабочку, застрявшую между контактами электромеханического реле. Стало ясно, что именно она и явилась причиной сбоя. Одна из сотрудниц университета, Грейс Хоппер, так и сформулировала результат исследований: «неполадку вызвал баг». Извлеченное насекомое было вклеено скотчем в технический дневник, с соответствующей сопроводительной надписью. Ее, как говорят, до сих пор можно увидеть в этом журнале, хранящемся в университетском научном музее.
В наше время большинство багов вызвано не насекомыми, как раньше, а преимущественно людьми.
Если обратиться к терминологии, то получается, что баг — это расхождение ожидаемого результата с фактическим. В нашем случае, ожидаемый результат — это поведение программы или системы, описанное в требованиях, а фактический результат — это поведение системы, наблюдаемое в процессе тестирования.
Баг в программе не появляется просто так, у него всегда есть источник. Например, ошибка программиста при написании кода. Дефекты встречаются, потому что люди склонны ошибаться, существует нехватка времени, сложность кода, сложность инфраструктуры, изменения технологий и/или много системных взаимодействий.
Что еще интересно, что программ, не содержащих ошибок, не бывает. По статистике на каждую тысячу строк программного кода, который пишут программисты, приходится несколько ошибок, а количество строк в сложном программном обеспечении достигает нескольких миллионов. Поэтому поиск и исправление этих ошибок – очень трудоемкое дело, составляющее до 45% всех затрат на разработку программного обеспечения.
Жизненный цикл бага
Давайте вкратце разберем каждый этап жизненного цикла
- Новый (New) — Тестировщик находит баг, локализует и вносит его в специальную систему, где хранятся баг-репорты. С этого момента баг начинает официально существовать.
Далее его статус меняется на Отказ (Rejected) или на Назначен (Assigned). - Отказ (Rejected) — пишется комментарий программиста или менеджера о причине reject-a(отклонения). Это может быть некачественное описание дефекта, такой дефект уже существует (дубликат), невозможность воспроизвести дефект. Также это может произойти потому что для заказчика какие-то ошибки перестали быть актуальными. После этого, тестировщик или закрывает дефект (Closed), или дополняет комментарии данного дефекта и переводит дефект заново в состояние Назначен(Assigned).
- Назначен (Assigned)— дефект просмотрен и открыт (то есть признан для исправления).
- Решен (Fixed) — дефект исправили и он в этом состоянии требует перепроверки тестировщиком.
- После проверки ошибки тестировщиком, дефект переводится в состояние Переоткрыт (Re-opened) (если дефект не исправлен или исправлен не полностью) либо в Закрыт (Closed), если ошибка исправлена.
Данную схему можно изобразить в текстовом виде. Вот несколько вариантов прохождения багов (можно просто нарисовать на листочке на собеседовании):
1. Новый (new) —> Отклонен (rejected) —> Закрыт (closed)
2. Новый (new) —> Назначен (аssigned) —> Решен (fixed) —> Закрыт (closed)
3. Новый (new) —> Назначен (аssigned) —> Решен (fixed) —> Закрыт (closed) —> Переоткрыт (re-opend)
Жизненный цикл бага с точки зрения команды
Давайте для большей наглядности рассмотрим жизненный цикл бага с точки зрения участников команды и их функций.
Сначала тестировщик находит баг. Далее заносит его в систему учета ошибок. После этого программист начинает изучать отчет о дефекте. Именно на этом этапе он решает баг это или нет.
Давайте посмотрим сначала сценарий, в котором разработчик принял баг. Перед ним сразу встает задача пофиксить его, то есть исправить и залить (отдать заново на проверку). Как только разработчик все сделал, баг снова отправляется к тестировщику, который производит тестирование исправлений, а также проверяет смежные участки (регрессионное тестирование).
Если баг больше не воспроизводится, то тестировщик закрывает баг.
Если баг снова воспроизводится, то мы возвращаем его программисту. И снова проходим все шаги, начиная с 3-го шага (рассмотрения проблемы программистом).
Теперь другой сценарий — разработчик не принял баг. Если баг не принят, то разработчик возвращает его нам. Наша задача — рассмотреть проблему. Если баг вернули из-за некорректного описания, то значит переписываем его. Если невозможно воспроизвести дефект, то заново проверяем все шаги, может мы что то упустили при описании. Если разработчик прав и бага нет, то мы закрываем баг. А если баг все же есть, то вносим необходимые коррективы и опять возвращаемся на шаг 3.
***
Именно так выглядят основные этапы жизненного цикла бага. Иногда могут добавляться дополнительные этапы, это вызвано особенностями процессов тестирования внутри фирмы. Неизменным всегда останется то, что баг создается и закрывается (прекращает существование) по различным причинам.