Asked
5 years, 9 months ago
Viewed
6k 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,76910 gold badges38 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
7454 silver badges8 bronze badges
Asked
5 years, 9 months ago
Viewed
6k 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,76910 gold badges38 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
7454 silver badges8 bronze badges
Уважаемый пользователь, сайт развивается и существует только на доходы от рекламы — пожалуйста, отключите блокировщик рекламы.
Ответов: 1 шт.
Описание:
Все пожелания и предложения можно отправлять на почту: support@poncy.ru.
Дефекты. Ошибки, сбои, отказы
Дефект — расхождение ожидаемого и фактического результата. Или дефект — отклонение фактического результата от ожиданий наблюдателя, сформированных на основе требований, спецификаций, иной документации или опыта и здравого смысла.
Ожидаемый результат — поведение системы, описанное в требованиях.
Фактический результат — поведение системы, наблюдаемое в процессе тестирования.
Ошибки совершает человек , которые приводят к возникновению дефектов в коде, которые, в свою очередь, приводят к сбоям и отказам приложения (однако сбои и отказы могут возникать и из-за внешних условий, таких как электромагнитное воздействие на оборудование и т.д.). Таким образом, упрощённо можно изобразить следующую схему
Ошибка (error , mistake) — действие человека, приводящее к некорректным результатам.
Дефект (defect, bug, problem, fault) — недостаток в компоненте или системе, способный привести к ситуации сбоя или отказа.
Дефекты могут быть в документации, настройках, входных данных и т.д.
Сбой или отказ — отклонение поведения системы от ожидаемого.
В ГОСТ 27.002-89 даны краткие определения сбоя и отказа :
Сбой — самоустраняющийся отказ или однократный отказ, устраняемый незначительным вмешательством оператора.
Отказ — событие, заключающееся в нарушении работоспособного состояния объекта.
Сбои и отказы являются тем, что тестировщик замечает в процессе тестирования и отталкиваясь от чего, проводит исследование с целью выявить дефект и его причины.
Отчёт о дефекте и его жизненный цикл
При обнаружении дефекта тестировщик создаёт отчёт о дефекте .
Отчёт о дефекте — документ, описывающий обнаруженный дефект, а также содействующий его устранению
Отчёт о дефекте пишется со следующими основными целями:
- предоставить информацию о проблеме — уведомить проектную команду и иных заинтересованных лиц о наличии проблемы, описать суть проблемы; приоритизировать проблему — определить степень опасности проблемы для проекта и желаемые сроки её устранения;
- содействовать устранению проблемы — качественный отчёт о дефекте не только предоставляет все необходимые подробности для понимания сути случившегося, но также может содержать анализ причин возникновения проблемы и рекомендации по исправлению ситуации.
Хорошо написанный отчёт о дефекте — половина решения проблемы для программиста. От полноты, корректности, аккуратности, подробности и логичности отчёта о дефекте зависит очень многое — одна и та же проблема может быть описана так, что программисту останется исправить пару строк кода, а может быть описана и так, что сам автор отчёта на следующий день не сможет понять, что же он имел в виду.
Отчёт о дефекте (и сам дефект вместе с ним) проходит определённые стадии жизненного цикла, которые схематично можно показать так (рисунок 2на следующем слайде):
- Обнаружен (submitted) — начальное состояние отчёта (иногда называется «Новый» (new)), в котором он находится сразу после создания. Некоторые средства также позволяют сначала создавать черновик (draft) и лишь потом публиковать отчёт.
- Назначен (assigned) — в это состояние отчёт переходит с момента, когда кто — то из проектной команды назначается ответственным за исправление дефекта. Назначение ответственного производится или решением лидера команды разработки, или коллегиально, или по добровольному принципу, или иным принятым в команде способом или выполняется автоматически на основе определённых правил.
- Исправлен (fixed) — в это состояние отчёт переводит ответственный за исправление дефекта член команды после выполнения соответствующих действий по исправлению.
- Проверен (verified) — в это состояние отчёт переводит тестировщик, удостоверившийся, что дефект на самом деле был устранён. Как правило, такую проверку выполняет тестировщик, изначально написавший отчёт о дефекте.
Свежий взгляд человека, ранее не знакомого с данным дефектом, позволяет ему в процессе верификации с большой вероятностью обнаружить новые дефекты.
Жизненный цикл отчёта о дефекте с наиболее типичными переходами между состояниями
Набор стадий жизненного цикла, их наименование и принцип перехода от стадии к стадии может различаться в разных инструментальных средствах управления жизненным циклом отчётов о дефектах. Более того — многие такие средства позволяют гибко настраивать эти параметры.
- Закрыт (closed) — состояние отчёта, означающее, что по данному дефекту не планируется никаких дальнейших действий.
Здесь есть некоторые расхождения в жизненном цикле, принятом в разных инструментальных средствах управления отчётами о дефектах:
В некоторых средствах существуют оба состояния — « Проверен » и « Закрыт », чтобы подчеркнуть, что в состоянии « Проверен » ещё могут потребоваться какие-то дополнительные действия (обсуждения, дополнительные проверки) в то время как состояние « Закрыт » означает «с дефектом покончено, больше к этому вопросу не возвращаемся».
- В некоторых средствах одного из состояний нет (оно поглощается другим)
В некоторых средствах в состояние «Закрыт» или «Отклонён» отчёт о дефекте может быть переведён из множества предшествующих состояний с резолюциями наподобие:
- «Не является дефектом» — приложение так и должно работать, описанное поведение не является аномальным.
- «Дубликат» — данный дефект уже описан в другом отчёте.
- «Не удалось воспроизвести» — разработчикам не удалось воспроизвести проблему на своём оборудовании.
- «Не будет исправлено» — дефект есть, но по каким-то серьёзным причинам его решено не исправлять.
- «Невозможно исправить» — непреодолимая причина дефекта находится вне области полномочий команды разработчиков, например существует проблема в операционной системе или аппаратном обеспечении, влияние которой устранить разумными способами невозможно. В подобных случаях будет переведён в состояние «Закрыт», в некоторых — в состояние «Отклонён», в некоторых — часть случаев закреплена за состоянием «Закрыт», часть — за «Отклонён».
- Открыт заново (reopened) — в это состояние (как правило, из состояния «Исправлен») отчёт переводит тестировщик, удостоверившийся, что дефект попрежнему воспроизводится на билде, в котором он уже должен быть исправлен.
- Рекомендован к отклонению (to be declined) — в это состояние отчёт о дефекте может быть переведён из множества других состояний с целью вынести на рассмотрение вопрос об отклонении отчёта по той или иной причине. Если рекомендация является обоснованной, отчёт переводится в состояние «Отклонён» (см. следующий пункт).
- Отклонён (declined) — в это состояние отчёт переводится в случаях, подробно описанных в пункте «Закрыт», если средство управления отчётами о дефектах предполагает использование этого состояния вместо состояния «Закрыт» для тех или иных резолюций по отчёту.
- Отложен (deferred) — в это состояние отчёт переводится в случае, если исправление дефекта в ближайшее время является нерациональным или не представляется возможным, однако есть основания полагать, что скоро ситуация исправится (выйдет новая версия библиотеки, вернётся из отпуска специалист по данной технологии, изменятся требования заказчика и т.д.).
Атрибуты (поля) отчёта о дефекте
Общий вид всей структуры отчёта о дефекте представлен на рисунке
- Идентификатор представляет собой уникальное значение, позволяющее однозначно отличить один отчёт о дефекте от другого и используемое во всевозможных ссылках. В общем случае идентификатор отчёта о дефекте может представлять собой просто уникальный номер, но может быть : включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить суть дефекта и часть приложения (или требований), к которой он относится.
- Краткое описание должно в предельно лаконичной форме давать исчерпывающий ответ на вопросы «Что произошло?» «Где это произошло»? «При каких условиях это произошло?».
Например: «Отсутствует логотип на странице приветствия, если пользователь
является администратором»:
— Что произошло? Отсутствует логотип.
— Где это произошло? На странице приветствия.
— При каких условиях это произошло? Если пользователь является
администратором.
Заполнение поля « краткое описание », которое одновременно должно:
— содержать предельно краткую, но в то же время достаточную для
понимания сути проблемы информацию о дефекте;
— быть достаточно коротким, чтобы полностью помещаться на экране;
— при необходимости содержать информацию об окружении, под
которым был обнаружен дефект;
— по возможности не дублировать краткие описания других
дефектов (и даже не быть похожими на них), чтобы дефекты
было сложно перепутать или посчитать дубликатами друг друга;
— быть законченным предложением русского или английского (или
иного) языка, построенным по соответствующим правилам
грамматики.
Для создания хороших кратких описаний дефектов рекомендуется пользоваться следующим алгоритмом:
- Полноценно понять суть проблемы. До тех пор, пока у тестировщика нет чёткого понимания того, «что не работает», писать отчёт о дефекте не стоит.
- Сформулировать подробное описание
- 3. Убрать из получившегося подробного описания всё лишнее, уточнить важные детали.
4. Выделить в подробном описании слова (словосочетания, фрагменты фраз), отвечающие на вопросы, «что, где и при каких условиях случилось».
5. Оформить получившееся в пункте 4 в виде законченного грамматически правильного предложения.
6. Если предложение получилось слишком длинным, переформулировать
его, сократив длину (за счёт подбора синонимов, использования
общепринятых аббревиатур и сокращений). К слову, в английском языке
предложение почти всегда будет короче русского аналога.
Пример применения этого алгоритма.
Тестированию подвергается некое веб-приложение, поле описания товара должно допускать ввод максимум 250 символов; в процессе тестирования оказалось, что этого ограничения нет.
- Суть проблемы: исследование показало, что ни на клиентской, ни на серверной части нет никаких механизмов, проверяющих и/или ограничивающих длину введённых в поле «О товаре» данных.
- Исходный вариант подробного описания: в клиентской и серверной части приложения отсутствуют проверка и ограничение длины данных, вводимых в поле «О товаре» на странице http://testapplication/admin/goods/edit.
- Конечный вариант подробного описания:
— Фактический результат: в описании товара (поле «О товаре»,
http://testapplication/admin/goods/edit/) отсутствуют проверка и
ограничение длины вводимого текста (MAX=250 символов).
— Ожидаемый результат: в случае попытки ввода 251+ символов
выводится сообщение об ошибке.
- Определение «что, где и при каких условиях случилось»:
— Что: отсутствуют проверка и ограничение длины вводимого текста.
— Где: описание товара, поле «О товаре»,
http://testapplication/admin/goods/edit/.
— При каких условиях: – (в данном случае дефект присутствует всегда, вне
зависимости от каких бы то ни было особых условий).
- Первичная формулировка: отсутствуют проверка и ограничение максимальной длины текста, вводимого в поле «О товаре» описания товара.
- Сокращение (итоговое краткое описание): нет ограничения максимальной длины поля «О товаре». Английский вариант: no check for «О товаре» max length.
- Подробное описание представляет в развёрнутом виде необходимую информацию о дефекте, а также (обязательно!) описание фактического результата, ожидаемого результата и ссылку на требование (если это возможно).
Пример подробного описания :
Если в систему входит администратор, на странице приветствия отсутствует логотип. Фактический результат: логотип отсутствует в левом верхнем углу страницы. Ожидаемый результат: логотип отображается в левом верхнем углу страницы. Требование: R245.3.23b.
В отличие от краткого описания, которое является одним предложением, здесь нужно давать подробную информацию. Если одна и та же проблема (вызванная одним источником) проявляется в нескольких местах приложения, можно в подробном описании перечислить эти места.
- Шаги по воспроизведению описывают действия, которые необходимо выполнить для воспроизведения дефекта.
Это поле похоже на шаги тест-кейса, за исключением одного отличия: здесь действия прописываются максимально подробно, с указанием конкретных вводимых значений и самых мелких деталей, т.к. отсутствие этой информации в сложных случаях может привести к невозможности воспроизведения дефекта.
Пример шагов воспроизведения :
- Открыть http://testapplication/admin/login/.
- Авторизоваться с именем «defaultadmin» и паролем «dapassword». Дефект : в левом верхнем углу страницы отсутствует логотип (вместо него отображается пустое пространство с надписью «logo»).
Воспроизводимость показывает, при каждом ли прохождении по шагам воспроизведения дефекта удаётся вызвать его проявление. Это поле принимает всего два значения: всегда или иногда. Можно сказать, что воспроизводимость «иногда» означает, что тестировщик не нашёл настоящую причину возникновения дефекта. Это приводит к серьёзным дополнительным сложностям в работе с дефектом:
- Тестировщику нужно потратить много времени на то, чтобы удостовериться в наличии дефекта (т.к. однократный сбой в работе приложения мог быть вызван большим количеством посторонних причин).
- Разработчику тоже нужно потратить время, чтобы добиться проявления дефекта и убедиться в его наличии. После внесения исправлений в приложение разработчик фактически должен полагаться только на свой профессионализм, т.к. даже многократное прохождение по шагам воспроизведения в таком случае не гарантирует, что дефект был исправлен (возможно, через ещё 10–20 повторений он бы проявился).
- Важность показывает степень ущерба, который наносится проекту существованием дефекта. В общем случае выделяют следующие виды важности:
— Критическая — существование дефекта приводит к масштабным последствиям катастрофического характера, например: потеря данных, раскрытие конфиденциальной информации, нарушение ключевой функциональности приложения и т.д.
— Высокая — существование дефекта приносит ощутимые неудобства многим пользователям в рамках их типичной деятельности, например: недоступность вставки из буфера обмена, неработоспособность общепринятых клавиатурных комбинаций, необходимость перезапуска приложения при выполнении типичных сценариев работы.
— Средняя — существование дефекта слабо влияет на типичные
сценарии работы пользователей, и/или существует обходной путь
достижения цели, например: диалоговое окно не закрывается
автоматически после нажатия кнопок «OK»/«Cancel», при распечатке
нескольких документов подряд не сохраняется значение поля
«Двусторонняя печать», перепутаны направления сортировок по
некоему полю таблицы.
— Низкая — существование дефекта редко обнаруживается
незначительным процентом пользователей и (почти) не влияет на их
работу, например: опечатка в глубоко вложенном пункте меню
настроек, некоторое окно при отображении расположено неудобно
(нужно перетянуть его в удобное место), неточно отображается время
до завершения операции копирования файлов.
- Срочность показывает, как быстро дефект должен быть устранён. В общем случае выделяют следующие виды срочности:
- Наивысшая срочность указывает на необходимость устранить дефект настолько быстро, насколько это возможно.
- Высокая срочность означает, что дефект следует исправить вне очереди, т.к. его существование или уже объективно мешает работе, или начнёт создавать такие помехи в самом ближайшем будущем.
- Обычная срочность означает, что дефект следует исправить в порядке общей очерёдности. Такое значение срочности получает большинство дефектов.
- Низкая срочность означает, что в обозримом будущем исправление данного дефекта не окажет существенного влияния на повышение качества продукта.
- С имптом — позволяет классифицировать дефекты по их типичному проявлению. Не существует никакого общепринятого списка симптомов.
В качестве примера рассмотрим следующие значения симптомов дефекта.
- Косметический дефект — визуально заметный недостаток интерфейса, не влияющий на функциональность приложения (например, надпись на кнопке выполнена шрифтом не той гарнитуры).
- Повреждение/потеря данных — в результате возникновения дефекта искажаются, уничтожаются (или не сохраняются) некоторые данные (например, при копировании файлов копии оказываются повреждёнными).
- Проблема в документации (— дефект относится не к приложению, а к документации (например, отсутствует раздел руководства по эксплуатации).
- Некорректная операция — некоторая операция выполняется некорректно
- Проблема инсталляции — дефект проявляется на стадии установки и/или конфигурирования приложения.
- Ошибка локализации — что-то в приложении не переведено или переведено неверно на выбранный язык интерфейса.
- Нереализованная функциональность — некая функция приложения не выполняется или не может быть вызвана (например, в списке форматов для экспорта документа отсутствует несколько пунктов, которые там должны быть
- Проблема масштабируемости — при увеличении количества доступных приложению ресурсов не происходит ожидаемого прироста производительности приложения
- Низкая производительность — выполнение неких операций занимает недопустимо большое время
- Крах системы — приложение прекращает работу или теряет способность выполнять свои ключевые функции
- Неожиданное поведение — в процессе выполнения некоторой типичной операции приложение ведёт себя необычным (отличным от общепринятого) образом (например, после добавления в список новой записи активной становится не новая запись, а первая в списке).
- Недружественное поведение — поведение приложения создаёт пользователю неудобства в работе (например, на разных диалоговых окнах в разном порядке расположены кнопки «OK» и «Cancel»).
- Расхождение с требованиями — этот симптом указывают, если дефект сложно соотнести с другими симптомами, но тем не менее приложение ведёт себя не так, как описано в требованиях.
- Предложение по улучшению — во многих инструментальных средствах управления отчётами о дефектах для этого случая есть отдельный вид отчёта
Часто у одного дефекта может быть сразу несколько симптомов.
- Возможность обойти — показывает, существует ли альтернативная последовательность действий, выполнение которой позволило бы пользователю достичь поставленной цели (например, клавиатурная комбинация Ctrl+P не работает, но распечатать документ можно, выбрав соответствующие пункты в меню). В некоторых инструментальных средствах управления отчётами о дефектах это поле может просто принимать значения «Да» и «Нет», в некоторых при выборе «Да» появляется возможность описать обходной путь. Традиционно считается, что дефектам без возможности обхода стоит повысить срочность исправления.
- Комментарий— может содержать любые полезные для понимания и исправления дефекта данные.
- Вложения — представляет собой не столько поле, сколько список прикреплённых к отчёту о дефекте приложений (копий экрана, вызывающих сбой файлов и т.д.).
Чем же они отличаются? Почитайте веселую историю и вспомнить отличие будет легко без подсматривания в гугл!
В летней школе тестировщиков Алексей Баранцев вел тренинг для продвинутых, как искать баги и исследовать приложение. Он задал простой вопрос → «Чем отличаются ошибка, дефект и сбой?». Предположения были самыми разнообразными, но уловить тонкую грань отличий никто не смог. Алексей мог зачитать умные слова из справочника 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.
Человек может допустить ошибку, которая приводит к дефекту (к неисправности, багу) в коде, в софте или системе, или документе. Если дефект в коде исполняется, система не сможет сделать то, что должна (или то, что не должна), что вызовет сбой. Дефекты в программном обеспечении, системах или документах, могут вызвать неисправности, но не все дефекты вызывают их.
© Оригинальный блог-пост
Стандартное отклонение и стандартная ошибка: в чем разница?
17 авг. 2022 г.
читать 2 мин
В статистике студенты часто путают два термина: стандартное отклонение и стандартная ошибка .
Стандартное отклонение измеряет, насколько разбросаны значения в наборе данных.
Стандартная ошибка — это стандартное отклонение среднего значения в повторных выборках из совокупности.
Давайте рассмотрим пример, чтобы ясно проиллюстрировать эту идею.
Пример: стандартное отклонение против стандартной ошибки
Предположим, мы измеряем вес 10 разных черепах.
Для этой выборки из 10 черепах мы можем вычислить среднее значение выборки и стандартное отклонение выборки:
Предположим, что стандартное отклонение оказалось равным 8,68. Это дает нам представление о том, насколько распределен вес этих черепах.
Но предположим, что мы собираем еще одну простую случайную выборку из 10 черепах и также проводим их измерения. Более чем вероятно, что эта выборка из 10 черепах будет иметь немного другое среднее значение и стандартное отклонение, даже если они взяты из одной и той же популяции:
Теперь, если мы представим, что мы берем повторные выборки из одной и той же совокупности и записываем выборочное среднее и выборочное стандартное отклонение для каждой выборки:
Теперь представьте, что мы наносим каждое среднее значение выборки на одну и ту же строку:
Стандартное отклонение этих средних значений известно как стандартная ошибка.
Формула для фактического расчета стандартной ошибки:
Стандартная ошибка = s/ √n
куда:
- s: стандартное отклонение выборки
- n: размер выборки
Какой смысл использовать стандартную ошибку?
Когда мы вычисляем среднее значение данной выборки, нас на самом деле интересует не среднее значение этой конкретной выборки, а скорее среднее значение большей совокупности, из которой взята выборка.
Однако мы используем выборки, потому что для них гораздо проще собирать данные, чем для всего населения. И, конечно же, среднее значение выборки будет варьироваться от выборки к выборке, поэтому мы используем стандартную ошибку среднего значения как способ измерить, насколько точна наша оценка среднего значения.
Вы заметите из формулы для расчета стандартной ошибки, что по мере увеличения размера выборки (n) стандартная ошибка уменьшается:
Стандартная ошибка = s/ √n
Это должно иметь смысл, поскольку большие размеры выборки уменьшают изменчивость и увеличивают вероятность того, что среднее значение нашей выборки ближе к фактическому среднему значению генеральной совокупности.
Когда использовать стандартное отклонение против стандартной ошибки
Если мы просто заинтересованы в измерении того, насколько разбросаны значения в наборе данных, мы можем использовать стандартное отклонение .
Однако, если мы заинтересованы в количественной оценке неопределенности оценки среднего значения, мы можем использовать стандартную ошибку среднего значения .
В зависимости от вашего конкретного сценария и того, чего вы пытаетесь достичь, вы можете использовать либо стандартное отклонение, либо стандартную ошибку.
Погре́шность измере́ния — оценка отклонения величины измеренного значения величины от её истинного значения. Погрешность измерения является характеристикой (мерой) точности измерения.
Поскольку выяснить с абсолютной точностью истинное значение любой величины невозможно, то невозможно и указать величину отклонения измеренного значения от истинного. (Это отклонение принято называть ошибкой измерения. В ряде источников, например, в БСЭ, термины ошибка измерения и погрешность измерения используются как синонимы.) Возможно лишь оценить величину этого отклонения, например, при помощи статистических методов. При этом за истинное значение принимается среднестатистическое значение, полученное при статистической обработке результатов серии измерений. Это полученное значение не является точным, а лишь наиболее вероятным. Поэтому в измерениях необходимо указывать, какова их точность. Для этого вместе с полученным результатом указывается погрешность измерений. Например, запись T=2.8±0.1 c. означает, что истинное значение величины T лежит в интервале от 2.7 с. до 2.9 с. некоторой оговоренной вероятностью (см. доверительный интервал, доверительная вероятность, стандартная ошибка).
В 2006 году на международном уровне был принят новый документ, диктующий условия проведения измерений и установивший новые правила сличения государственных эталонов. Понятие «погрешность» стало устаревать, вместо него было введено понятие «неопределенность измерений».
Содержание
- 1 Определение погрешности
- 2 Классификация погрешностей
- 2.1 По форме представления
- 2.2 По причине возникновения
- 2.3 По характеру проявления
- 2.4 По способу измерения
- 3 См. также
- 4 Литература
Определение погрешности
В зависимости от характеристик измеряемой величины для определения погрешности измерений используют различные методы.
- Метод Корнфельда, заключается в выборе доверительного интервала в пределах от минимального до максимального результата измерений, и погрешность как половина разности между максимальным и минимальным результатом измерения:
- Средняя квадратическая погрешность:
- Средняя квадратическая погрешность среднего арифметического:
Классификация погрешностей
По форме представления
- Абсолютная погрешность — ΔX является оценкой абсолютной ошибки измерения. Величина этой погрешности зависит от способа её вычисления, который, в свою очередь, определяется распределением случайной величины Xmeas. При этом равенство:
ΔX = | Xtrue − Xmeas | ,
где Xtrue — истинное значение, а Xmeas — измеренное значение, должно выполняться с некоторой вероятностью близкой к 1. Если случайная величина Xmeas распределена по нормальному закону, то, обычно, за абсолютную погрешность принимают её среднеквадратичное отклонение. Абсолютная погрешность измеряется в тех же единицах измерения, что и сама величина.
- Относительная погрешность — отношение абсолютной погрешности к тому значению, которое принимается за истинное:
.
Относительная погрешность является безразмерной величиной, либо измеряется в процентах.
- Приведенная погрешность — относительная погрешность, выраженная отношением абсолютной погрешности средства измерений к условно принятому значению величины, постоянному во всем диапазоне измерений или в части диапазона. Вычисляется по формуле
,
где Xn — нормирующее значение, которое зависит от типа шкалы измерительного прибора и определяется по его градуировке:
— если шкала прибора односторонняя, т.е. нижний предел измерений равен нулю, то Xn определяется равным верхнему пределу измерений;
— если шкала прибора двухсторонняя, то нормирующее значение равно ширине диапазона измерений прибора.
Приведенная погрешность — безразмерная величина (может измеряться в процентах).
По причине возникновения
- Инструментальные / приборные погрешности — погрешности, которые определяются погрешностями применяемых средств измерений и вызываются несовершенством принципа действия, неточностью градуировки шкалы, ненаглядностью прибора.
- Методические погрешности — погрешности, обусловленные несовершенством метода, а также упрощениями, положенными в основу методики.
- Субъективные / операторные / личные погрешности — погрешности, обусловленные степенью внимательности, сосредоточенности, подготовленности и другими качествами оператора.
В технике применяют приборы для измерения лишь с определенной заранее заданной точностью – основной погрешностью, допускаемой нормали в нормальных условиях эксплуатации для данного прибора.
Если прибор работает в условиях, отличных от нормальных, то возникает дополнительная погрешность, увеличивающая общую погрешность прибора. К дополнительным погрешностям относятся: температурная, вызванная отклонением температуры окружающей среды от нормальной, установочная, обусловленная отклонением положения прибора от нормального рабочего положения, и т.п. За нормальную температуру окружающего воздуха принимают 20°С, за нормальное атмосферное давление 01,325 кПа.
Обобщенной характеристикой средств измерения является класс точности, определяемый предельными значениями допускаемых основной и дополнительной погрешностей, а также другими параметрами, влияющими на точность средств измерения; значение параметров установлено стандартами на отдельные виды средств измерений. Класс точности средств измерений характеризует их точностные свойства, но не является непосредственным показателем точности измерений, выполняемых с помощью этих средств, так как точность зависит также от метода измерений и условий их выполнения. Измерительным приборам, пределы допускаемой основной погрешности которых заданы в виде приведенных основных (относительных) погрешностей, присваивают классы точности, выбираемые из ряда следующих чисел: (1; 1,5; 2,0; 2,5; 3,0; 4,0; 5,0; 6,0)*10n, где n = 1; 0; -1; -2 и т.д.
По характеру проявления
- Случайная погрешность — погрешность, меняющаяся (по величине и по знаку) от измерения к измерению. Случайные погрешности могут быть связаны с несовершенством приборов (трение в механических приборах и т.п.), тряской в городских условиях, с несовершенством объекта измерений (например, при измерении диаметра тонкой проволоки, которая может иметь не совсем круглое сечение в результате несовершенства процесса изготовления), с особенностями самой измеряемой величины (например при измерении количества элементарных частиц, проходящих в минуту через счётчик Гейгера).
- Систематическая погрешность — погрешность, изменяющаяся во времени по определенному закону (частным случаем является постоянная погрешность, не изменяющаяся с течением времени). Систематические погрешности могут быть связаны с ошибками приборов (неправильная шкала, калибровка и т.п.), неучтёнными экспериментатором.
- Прогрессирующая (дрейфовая) погрешность — непредсказуемая погрешность, медленно меняющаяся во времени. Она представляет собой нестационарный случайный процесс.
- Грубая погрешность (промах) — погрешность, возникшая вследствие недосмотра экспериментатора или неисправности аппаратуры (например, если экспериментатор неправильно прочёл номер деления на шкале прибора, если произошло замыкание в электрической цепи).
По способу измерения
- Погрешность прямых измерений
- Погрешность косвенных измерений — погрешность вычисляемой (не измеряемой непосредственно) величины:
Если F = F(x1,x2…xn), где xi — непосредственно измеряемые независимые величины, имеющие погрешность Δxi, тогда:
См. также
- Измерение физических величин
- Класс точности
- Метрология
- Система автоматизированного сбора данных со счетчиков по радиоканалу
- Методы электроаналитической химии
Литература
- Назаров Н. Г. Метрология. Основные понятия и математические модели. М.: Высшая школа, 2002. 348 с.
- Лабораторные занятия по физике. Учебное пособие/Гольдин Л. Л., Игошин Ф. Ф., Козел С. М. и др.; под ред. Гольдина Л. Л. — М.: Наука. Главная редакция физико-математичекой литературы, 1983. — 704 с.
Wikimedia Foundation.
2010.
1.
Лекция 3.
Дефекты.
Ошибки, сбои, отказы
2.
Дефект — расхождение ожидаемого и фактического результата. Или дефект —
отклонение фактического результата от ожиданий наблюдателя, сформированных на
основе требований, спецификаций, иной документации или опыта и здравого смысла.
Ожидаемый результат — поведение системы, описанное в требованиях.
Фактический результат — поведение системы, наблюдаемое в процессе тестирования.
Ошибки совершает человек , которые приводят к возникновению дефектов в коде,
которые, в свою очередь, приводят к сбоям и отказам приложения (однако сбои и отказы
могут возникать и из-за внешних условий, таких как электромагнитное воздействие на
оборудование и т.д.). Таким образом, упрощённо можно изобразить следующую схему
3.
Ошибка (error , mistake) — действие человека, приводящее к некорректным
результатам.
Дефект (defect, bug, problem, fault) — недостаток в компоненте или системе, способный
привести к ситуации сбоя или отказа.
Дефекты могут быть в документации, настройках, входных данных и т.д.
Сбой или отказ — отклонение поведения системы от ожидаемого.
В ГОСТ 27.002-89 даны краткие определения сбоя и отказа:
Сбой — самоустраняющийся отказ или однократный отказ, устраняемый
незначительным вмешательством оператора.
Отказ — событие, заключающееся в нарушении работоспособного состояния объекта.
Сбои и отказы являются тем, что тестировщик замечает в процессе тестирования и
отталкиваясь от чего, проводит исследование с целью выявить дефект и его причины.
Отчёт о дефекте и его жизненный цикл
При обнаружении дефекта тестировщик создаёт отчёт о дефекте.
Отчёт о дефекте — документ, описывающий обнаруженный дефект, а также
содействующий его устранению
4.
Отчёт о дефекте пишется со следующими основными целями:
• предоставить информацию о проблеме — уведомить проектную команду
и иных заинтересованных лиц о наличии проблемы, описать суть
проблемы; приоритизировать проблему — определить степень опасности
проблемы для проекта и желаемые сроки её устранения;
• содействовать устранению проблемы — качественный отчёт о дефекте не
только предоставляет все необходимые подробности для понимания сути
случившегося, но также может содержать анализ причин возникновения
проблемы и рекомендации по исправлению ситуации.
Хорошо написанный отчёт о дефекте — половина решения проблемы для
программиста. От полноты, корректности, аккуратности, подробности и
логичности отчёта о дефекте зависит очень многое — одна и та же
проблема может быть описана так, что программисту останется исправить
пару строк кода, а может быть описана и так, что сам автор отчёта на
следующий день не сможет понять, что же он имел в виду.
5.
Отчёт о дефекте (и сам дефект вместе с ним) проходит определённые стадии
жизненного цикла, которые схематично можно показать так (рисунок 2на
следующем слайде):
• Обнаружен (submitted) — начальное состояние отчёта (иногда называется
«Новый» (new)), в котором он находится сразу после создания. Некоторые
средства также позволяют сначала создавать черновик (draft) и лишь потом
публиковать отчёт.
• Назначен (assigned) — в это состояние отчёт переходит с момента, когда кто — то
из проектной команды назначается ответственным за исправление дефекта.
Назначение ответственного производится или решением лидера команды
разработки, или коллегиально, или по добровольному принципу, или иным
принятым в команде способом или выполняется автоматически на основе
определённых правил.
• Исправлен (fixed) — в это состояние отчёт переводит ответственный за
исправление дефекта член команды после выполнения соответствующих
действий по исправлению.
• Проверен (verified) — в это состояние отчёт переводит тестировщик,
удостоверившийся, что дефект на самом деле был устранён. Как правило,
такую проверку выполняет тестировщик, изначально написавший отчёт о
дефекте.
6.
Свежий взгляд человека, ранее не знакомого с данным дефектом, позволяет ему в
процессе верификации с большой вероятностью обнаружить новые дефекты.
Жизненный цикл отчёта о дефекте с наиболее типичными переходами между состояниями
7.
Набор стадий жизненного цикла, их наименование и принцип перехода от
стадии к стадии может различаться в разных инструментальных средствах
управления жизненным циклом отчётов о дефектах. Более того — многие
такие средства позволяют гибко настраивать эти параметры.
• Закрыт (closed) — состояние отчёта, означающее, что по данному дефекту
не планируется никаких дальнейших действий.
Здесь есть некоторые расхождения в жизненном цикле, принятом в разных
инструментальных средствах управления отчётами о дефектах:
В некоторых средствах существуют оба состояния — «Проверен» и
«Закрыт», чтобы подчеркнуть, что в состоянии «Проверен» ещё могут
потребоваться
какие-то
дополнительные
действия
(обсуждения,
дополнительные проверки) в то время как состояние «Закрыт» означает «с
дефектом покончено, больше к этому вопросу не возвращаемся».
• В некоторых средствах одного из состояний нет (оно поглощается другим)
8.
В некоторых средствах в состояние «Закрыт» или «Отклонён» отчёт о дефекте
может быть переведён из множества предшествующих состояний с резолюциями
наподобие:
• «Не является дефектом» — приложение так и должно работать, описанное
поведение не является аномальным.
• «Дубликат» — данный дефект уже описан в другом отчёте.
• «Не удалось воспроизвести» — разработчикам не удалось воспроизвести
проблему на своём оборудовании.
• «Не будет исправлено» — дефект есть, но по каким-то серьёзным причинам его
решено не исправлять.
• «Невозможно исправить» — непреодолимая причина дефекта находится вне
области полномочий команды разработчиков, например существует проблема в
операционной системе или аппаратном обеспечении, влияние которой
устранить разумными способами невозможно. В подобных случаях будет
переведён в состояние «Закрыт», в некоторых — в состояние «Отклонён», в
некоторых — часть случаев закреплена за состоянием «Закрыт», часть — за
«Отклонён».
9.
• Открыт заново (reopened) — в это состояние (как правило, из состояния
«Исправлен») отчёт переводит тестировщик, удостоверившийся, что дефект
попрежнему воспроизводится на билде, в котором он уже должен быть
исправлен.
• Рекомендован к отклонению (to be declined) — в это состояние отчёт о дефекте
может быть переведён из множества других состояний с целью вынести на
рассмотрение вопрос об отклонении отчёта по той или иной причине. Если
рекомендация является обоснованной, отчёт переводится в состояние
«Отклонён» (см. следующий пункт).
• Отклонён (declined) — в это состояние отчёт переводится в случаях, подробно
описанных в пункте «Закрыт», если средство управления отчётами о дефектах
предполагает использование этого состояния вместо состояния «Закрыт» для
тех или иных резолюций по отчёту.
• Отложен (deferred) — в это состояние отчёт переводится в случае, если
исправление дефекта в ближайшее время является нерациональным или не
представляется возможным, однако есть основания полагать, что скоро
ситуация исправится (выйдет новая версия библиотеки, вернётся из отпуска
специалист по данной технологии, изменятся требования заказчика и т.д.).
10.
Атрибуты (поля) отчёта о дефекте
Общий вид всей структуры отчёта о дефекте представлен на рисунке
11.
12.
• Идентификатор представляет собой уникальное значение, позволяющее однозначно
отличить один отчёт о дефекте от другого и используемое во всевозможных ссылках. В
общем случае идентификатор отчёта о дефекте может представлять собой просто
уникальный номер, но может быть : включать префиксы, суффиксы и иные
осмысленные компоненты, позволяющие быстро определить суть дефекта и часть
приложения (или требований), к которой он относится.
• Краткое описание должно в предельно лаконичной форме давать исчерпывающий
ответ на вопросы «Что произошло?» «Где это произошло»? «При каких условиях это
произошло?».
Например: «Отсутствует логотип на странице приветствия, если пользователь
является администратором»:
— Что произошло? Отсутствует логотип.
— Где это произошло? На странице приветствия.
— При каких условиях это произошло? Если пользователь является
администратором.
Заполнение поля «краткое описание», которое одновременно должно:
— содержать предельно краткую, но в то же время достаточную для
понимания сути проблемы информацию о дефекте;
— быть достаточно коротким, чтобы полностью помещаться на экране;
13.
— при необходимости содержать информацию об окружении, под
которым был обнаружен дефект;
— по возможности не дублировать краткие описания других
дефектов (и даже не быть похожими на них), чтобы дефекты
было сложно перепутать или посчитать дубликатами друг друга;
— быть законченным предложением русского или английского (или
иного) языка, построенным по соответствующим правилам
грамматики.
Для создания хороших кратких описаний дефектов рекомендуется пользоваться
следующим алгоритмом:
1. Полноценно понять суть проблемы. До тех пор, пока у тестировщика нет
чёткого понимания того, «что не работает», писать отчёт о дефекте не стоит.
2. Сформулировать подробное описание
3. 3. Убрать из получившегося подробного описания всё лишнее, уточнить
важные детали.
14.
4. Выделить в подробном описании слова (словосочетания, фрагменты фраз),
отвечающие на вопросы, «что, где и при каких условиях случилось».
5. Оформить получившееся в пункте 4 в виде законченного грамматически
правильного предложения.
6. Если предложение получилось слишком длинным, переформулировать
его, сократив длину (за счёт подбора синонимов, использования
общепринятых аббревиатур и сокращений). К слову, в английском языке
предложение почти всегда будет короче русского аналога.
Пример применения этого алгоритма.
Тестированию подвергается некое веб-приложение, поле описания товара должно
допускать ввод максимум 250 символов; в процессе тестирования оказалось, что
этого ограничения нет.
1. Суть проблемы: исследование показало, что ни на клиентской, ни на
серверной части нет никаких механизмов, проверяющих и/или
ограничивающих длину введённых в поле «О товаре» данных.
2. Исходный вариант подробного описания: в клиентской и серверной части
приложения отсутствуют проверка и ограничение длины данных, вводимых в
поле «О товаре» на странице http://testapplication/admin/goods/edit.
15.
3. Конечный вариант подробного описания:
— Фактический результат: в описании товара (поле «О товаре»,
http://testapplication/admin/goods/edit/) отсутствуют проверка и
ограничение длины вводимого текста (MAX=250 символов).
— Ожидаемый результат: в случае попытки ввода 251+ символов
выводится сообщение об ошибке.
4. Определение «что, где и при каких условиях случилось»:
— Что: отсутствуют проверка и ограничение длины вводимого текста.
— Где: описание товара, поле «О товаре»,
http://testapplication/admin/goods/edit/.
— При каких условиях: – (в данном случае дефект присутствует всегда, вне
зависимости от каких бы то ни было особых условий).
5. Первичная формулировка: отсутствуют проверка и ограничение
максимальной длины текста, вводимого в поле «О товаре» описания товара.
6. Сокращение (итоговое краткое описание): нет ограничения максимальной
длины поля «О товаре». Английский вариант: no check for «О товаре» max
length.
16.
• Подробное описание представляет в развёрнутом виде необходимую
информацию о дефекте, а также (обязательно!) описание фактического
результата, ожидаемого результата и ссылку на требование (если это
возможно).
Пример подробного описания:
Если в систему входит администратор, на странице приветствия отсутствует
логотип. Фактический результат: логотип отсутствует в левом верхнем углу
страницы. Ожидаемый результат: логотип отображается в левом верхнем
углу страницы. Требование: R245.3.23b.
В отличие от краткого описания, которое является одним предложением,
здесь нужно давать подробную информацию. Если одна и та же проблема
(вызванная одним источником) проявляется в нескольких местах
приложения, можно в подробном описании перечислить эти места.
• Шаги по воспроизведению описывают действия, которые необходимо
выполнить для воспроизведения дефекта.
17.
Это поле похоже на шаги тест-кейса, за исключением одного отличия: здесь
действия прописываются максимально подробно, с указанием конкретных
вводимых значений и самых мелких деталей, т.к. отсутствие этой информации в
сложных случаях может привести к невозможности воспроизведения дефекта.
Пример шагов воспроизведения:
1. Открыть http://testapplication/admin/login/.
2. Авторизоваться с именем «defaultadmin» и паролем «dapassword». Дефект: в
левом верхнем углу страницы отсутствует логотип (вместо него отображается
пустое пространство с надписью «logo»).
Воспроизводимость показывает, при каждом ли прохождении по шагам
воспроизведения дефекта удаётся вызвать его проявление. Это поле принимает
всего два значения: всегда или иногда. Можно сказать, что воспроизводимость
«иногда» означает, что тестировщик не нашёл настоящую причину возникновения
дефекта. Это приводит к серьёзным дополнительным сложностям в работе с
дефектом:
• Тестировщику нужно потратить много времени на то, чтобы удостовериться в
наличии дефекта (т.к. однократный сбой в работе приложения мог быть вызван
большим количеством посторонних причин).
18.
• Разработчику тоже нужно потратить время, чтобы добиться проявления
дефекта и убедиться в его наличии. После внесения исправлений в приложение
разработчик фактически должен полагаться только на свой профессионализм,
т.к. даже многократное прохождение по шагам воспроизведения в таком случае
не гарантирует, что дефект был исправлен (возможно, через ещё 10–20
повторений он бы проявился).
• Важность показывает степень ущерба, который наносится проекту
существованием дефекта. В общем случае выделяют следующие виды
важности:
— Критическая — существование дефекта приводит к масштабным последствиям
катастрофического характера, например: потеря данных, раскрытие
конфиденциальной информации, нарушение ключевой функциональности
приложения и т.д.
— Высокая — существование дефекта приносит ощутимые неудобства многим
пользователям в рамках их типичной деятельности, например: недоступность
вставки из буфера обмена, неработоспособность общепринятых клавиатурных
комбинаций, необходимость перезапуска приложения при выполнении типичных
сценариев работы.
19.
— Средняя — существование дефекта слабо влияет на типичные
сценарии работы пользователей, и/или существует обходной путь
достижения цели, например: диалоговое окно не закрывается
автоматически после нажатия кнопок «OK»/«Cancel», при распечатке
нескольких документов подряд не сохраняется значение поля
«Двусторонняя печать», перепутаны направления сортировок по
некоему полю таблицы.
— Низкая — существование дефекта редко обнаруживается
незначительным процентом пользователей и (почти) не влияет на их
работу, например: опечатка в глубоко вложенном пункте меню
настроек, некоторое окно при отображении расположено неудобно
(нужно перетянуть его в удобное место), неточно отображается время
до завершения операции копирования файлов.
20.
• Срочность показывает, как быстро дефект должен быть устранён. В общем
случае выделяют следующие виды срочности:
1. Наивысшая срочность указывает на необходимость устранить дефект
настолько быстро, насколько это возможно.
2. Высокая срочность означает, что дефект следует исправить вне очереди,
т.к. его существование или уже объективно мешает работе, или начнёт
создавать такие помехи в самом ближайшем будущем.
3. Обычная срочность означает, что дефект следует исправить в порядке
общей очерёдности. Такое значение срочности получает большинство
дефектов.
4. Низкая срочность означает, что в обозримом будущем исправление
данного дефекта не окажет существенного влияния на повышение
качества продукта.
21.
• Симптом — позволяет классифицировать дефекты по их типичному проявлению. Не
существует никакого общепринятого списка симптомов.
В качестве примера рассмотрим следующие значения симптомов дефекта.
1. Косметический дефект — визуально заметный недостаток интерфейса, не влияющий
на функциональность приложения (например, надпись на кнопке выполнена
шрифтом не той гарнитуры).
2. Повреждение/потеря данных — в результате возникновения дефекта искажаются,
уничтожаются (или не сохраняются) некоторые данные (например, при копировании
файлов копии оказываются повреждёнными).
3. Проблема в документации (— дефект относится не к приложению, а к документации
(например, отсутствует раздел руководства по эксплуатации).
4. Некорректная операция — некоторая операция выполняется некорректно
5. Проблема инсталляции — дефект проявляется на стадии установки и/или
конфигурирования приложения.
6. Ошибка локализации — что-то в приложении не переведено или переведено
неверно на выбранный язык интерфейса.
7. Нереализованная функциональность — некая функция приложения не выполняется
или не может быть вызвана (например, в списке форматов для экспорта документа
отсутствует несколько пунктов, которые там должны быть
22.
8. Проблема масштабируемости — при увеличении количества доступных
приложению ресурсов не происходит ожидаемого прироста
производительности приложения
9. Низкая производительность — выполнение неких операций занимает
недопустимо большое время
10. Крах системы — приложение прекращает работу или теряет способность
выполнять свои ключевые функции
11. Неожиданное поведение — в процессе выполнения некоторой типичной
операции приложение ведёт себя необычным (отличным от общепринятого)
образом (например, после добавления в список новой записи активной
становится не новая запись, а первая в списке).
12. Недружественное поведение — поведение приложения создаёт
пользователю неудобства в работе (например, на разных диалоговых окнах в
разном порядке расположены кнопки «OK» и «Cancel»).
13. Расхождение с требованиями — этот симптом указывают, если дефект сложно
соотнести с другими симптомами, но тем не менее приложение ведёт себя не
так, как описано в требованиях.
14. Предложение по улучшению — во многих инструментальных средствах
управления отчётами о дефектах для этого случая есть отдельный вид отчёта
23.
Часто у одного дефекта может быть сразу несколько симптомов.
15. Возможность обойти — показывает, существует ли альтернативная
последовательность действий, выполнение которой позволило бы
пользователю достичь поставленной цели (например, клавиатурная
комбинация Ctrl+P не работает, но распечатать документ можно, выбрав
соответствующие пункты в меню). В некоторых инструментальных
средствах управления отчётами о дефектах это поле может просто
принимать значения «Да» и «Нет», в некоторых при выборе «Да»
появляется возможность описать обходной путь. Традиционно
считается, что дефектам без возможности обхода стоит повысить
срочность исправления.
16. Комментарий— может содержать любые полезные для понимания и
исправления дефекта данные.
17. Вложения — представляет собой не столько поле, сколько список
прикреплённых к отчёту о дефекте приложений (копий экрана,
вызывающих сбой файлов и т.д.).
Буквы:
1
2
3
4
5
6
7
Чем же они отличаются? Почитайте веселую историю и вспомнить отличие будет легко без подсматривания в гугл!
В летней школе тестировщиков Алексей Баранцев вел тренинг для продвинутых, как искать баги и исследовать приложение. Он задал простой вопрос → «Чем отличаются ошибка, дефект и сбой?». Предположения были самыми разнообразными, но уловить тонкую грань отличий никто не смог. Алексей мог зачитать умные слова из справочника 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.
Человек может допустить ошибку, которая приводит к дефекту (к неисправности, багу) в коде, в софте или системе, или документе. Если дефект в коде исполняется, система не сможет сделать то, что должна (или то, что не должна), что вызовет сбой. Дефекты в программном обеспечении, системах или документах, могут вызвать неисправности, но не все дефекты вызывают их.
© Оригинальный блог-пост
Сможете ли вы без подглядки в гугл ответить на вопрос — чем отличаются:
— Ошибка.
— Дефект.
— Сбой.
Практика показывает, что нет 
Три года назад (кошмар, сколько времени прошло!) я была в летней школе тестировщиков. Алексей Баранцев вел тренинг для продвинутых, как искать баги и исследовать приложение. Он задал простой вопрос → «Чем отличаются ошибка, дефект и сбой?». Предположения были самыми разнообразными, но уловить тонкую грань отличий никто не смог.
Алексей мог зачитать умные слова из справочника 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.
Человек может допустить ошибку, которая приводит к дефекту (к неисправности, багу) в коде, в софте или системе, или документе. Если дефект в коде исполняется, система не сможет сделать то, что должна (или то, что не должна), что вызовет сбой. Дефекты в программном обеспечении, системах или документах, могут вызвать неисправности, но не все дефекты вызывают их.
1.
Лекция 3.
Дефекты.
Ошибки, сбои, отказы
2.
Дефект — расхождение ожидаемого и фактического результата. Или дефект —
отклонение фактического результата от ожиданий наблюдателя, сформированных на
основе требований, спецификаций, иной документации или опыта и здравого смысла.
Ожидаемый результат — поведение системы, описанное в требованиях.
Фактический результат — поведение системы, наблюдаемое в процессе тестирования.
Ошибки совершает человек , которые приводят к возникновению дефектов в коде,
которые, в свою очередь, приводят к сбоям и отказам приложения (однако сбои и отказы
могут возникать и из-за внешних условий, таких как электромагнитное воздействие на
оборудование и т.д.). Таким образом, упрощённо можно изобразить следующую схему
3.
Ошибка (error , mistake) — действие человека, приводящее к некорректным
результатам.
Дефект (defect, bug, problem, fault) — недостаток в компоненте или системе, способный
привести к ситуации сбоя или отказа.
Дефекты могут быть в документации, настройках, входных данных и т.д.
Сбой или отказ — отклонение поведения системы от ожидаемого.
В ГОСТ 27.002-89 даны краткие определения сбоя и отказа:
Сбой — самоустраняющийся отказ или однократный отказ, устраняемый
незначительным вмешательством оператора.
Отказ — событие, заключающееся в нарушении работоспособного состояния объекта.
Сбои и отказы являются тем, что тестировщик замечает в процессе тестирования и
отталкиваясь от чего, проводит исследование с целью выявить дефект и его причины.
Отчёт о дефекте и его жизненный цикл
При обнаружении дефекта тестировщик создаёт отчёт о дефекте.
Отчёт о дефекте — документ, описывающий обнаруженный дефект, а также
содействующий его устранению
4.
Отчёт о дефекте пишется со следующими основными целями:
• предоставить информацию о проблеме — уведомить проектную команду
и иных заинтересованных лиц о наличии проблемы, описать суть
проблемы; приоритизировать проблему — определить степень опасности
проблемы для проекта и желаемые сроки её устранения;
• содействовать устранению проблемы — качественный отчёт о дефекте не
только предоставляет все необходимые подробности для понимания сути
случившегося, но также может содержать анализ причин возникновения
проблемы и рекомендации по исправлению ситуации.
Хорошо написанный отчёт о дефекте — половина решения проблемы для
программиста. От полноты, корректности, аккуратности, подробности и
логичности отчёта о дефекте зависит очень многое — одна и та же
проблема может быть описана так, что программисту останется исправить
пару строк кода, а может быть описана и так, что сам автор отчёта на
следующий день не сможет понять, что же он имел в виду.
5.
Отчёт о дефекте (и сам дефект вместе с ним) проходит определённые стадии
жизненного цикла, которые схематично можно показать так (рисунок 2на
следующем слайде):
• Обнаружен (submitted) — начальное состояние отчёта (иногда называется
«Новый» (new)), в котором он находится сразу после создания. Некоторые
средства также позволяют сначала создавать черновик (draft) и лишь потом
публиковать отчёт.
• Назначен (assigned) — в это состояние отчёт переходит с момента, когда кто — то
из проектной команды назначается ответственным за исправление дефекта.
Назначение ответственного производится или решением лидера команды
разработки, или коллегиально, или по добровольному принципу, или иным
принятым в команде способом или выполняется автоматически на основе
определённых правил.
• Исправлен (fixed) — в это состояние отчёт переводит ответственный за
исправление дефекта член команды после выполнения соответствующих
действий по исправлению.
• Проверен (verified) — в это состояние отчёт переводит тестировщик,
удостоверившийся, что дефект на самом деле был устранён. Как правило,
такую проверку выполняет тестировщик, изначально написавший отчёт о
дефекте.
6.
Свежий взгляд человека, ранее не знакомого с данным дефектом, позволяет ему в
процессе верификации с большой вероятностью обнаружить новые дефекты.
Жизненный цикл отчёта о дефекте с наиболее типичными переходами между состояниями
7.
Набор стадий жизненного цикла, их наименование и принцип перехода от
стадии к стадии может различаться в разных инструментальных средствах
управления жизненным циклом отчётов о дефектах. Более того — многие
такие средства позволяют гибко настраивать эти параметры.
• Закрыт (closed) — состояние отчёта, означающее, что по данному дефекту
не планируется никаких дальнейших действий.
Здесь есть некоторые расхождения в жизненном цикле, принятом в разных
инструментальных средствах управления отчётами о дефектах:
В некоторых средствах существуют оба состояния — «Проверен» и
«Закрыт», чтобы подчеркнуть, что в состоянии «Проверен» ещё могут
потребоваться
какие-то
дополнительные
действия
(обсуждения,
дополнительные проверки) в то время как состояние «Закрыт» означает «с
дефектом покончено, больше к этому вопросу не возвращаемся».
• В некоторых средствах одного из состояний нет (оно поглощается другим)
8.
В некоторых средствах в состояние «Закрыт» или «Отклонён» отчёт о дефекте
может быть переведён из множества предшествующих состояний с резолюциями
наподобие:
• «Не является дефектом» — приложение так и должно работать, описанное
поведение не является аномальным.
• «Дубликат» — данный дефект уже описан в другом отчёте.
• «Не удалось воспроизвести» — разработчикам не удалось воспроизвести
проблему на своём оборудовании.
• «Не будет исправлено» — дефект есть, но по каким-то серьёзным причинам его
решено не исправлять.
• «Невозможно исправить» — непреодолимая причина дефекта находится вне
области полномочий команды разработчиков, например существует проблема в
операционной системе или аппаратном обеспечении, влияние которой
устранить разумными способами невозможно. В подобных случаях будет
переведён в состояние «Закрыт», в некоторых — в состояние «Отклонён», в
некоторых — часть случаев закреплена за состоянием «Закрыт», часть — за
«Отклонён».
9.
• Открыт заново (reopened) — в это состояние (как правило, из состояния
«Исправлен») отчёт переводит тестировщик, удостоверившийся, что дефект
попрежнему воспроизводится на билде, в котором он уже должен быть
исправлен.
• Рекомендован к отклонению (to be declined) — в это состояние отчёт о дефекте
может быть переведён из множества других состояний с целью вынести на
рассмотрение вопрос об отклонении отчёта по той или иной причине. Если
рекомендация является обоснованной, отчёт переводится в состояние
«Отклонён» (см. следующий пункт).
• Отклонён (declined) — в это состояние отчёт переводится в случаях, подробно
описанных в пункте «Закрыт», если средство управления отчётами о дефектах
предполагает использование этого состояния вместо состояния «Закрыт» для
тех или иных резолюций по отчёту.
• Отложен (deferred) — в это состояние отчёт переводится в случае, если
исправление дефекта в ближайшее время является нерациональным или не
представляется возможным, однако есть основания полагать, что скоро
ситуация исправится (выйдет новая версия библиотеки, вернётся из отпуска
специалист по данной технологии, изменятся требования заказчика и т.д.).
10.
Атрибуты (поля) отчёта о дефекте
Общий вид всей структуры отчёта о дефекте представлен на рисунке
11.
12.
• Идентификатор представляет собой уникальное значение, позволяющее однозначно
отличить один отчёт о дефекте от другого и используемое во всевозможных ссылках. В
общем случае идентификатор отчёта о дефекте может представлять собой просто
уникальный номер, но может быть : включать префиксы, суффиксы и иные
осмысленные компоненты, позволяющие быстро определить суть дефекта и часть
приложения (или требований), к которой он относится.
• Краткое описание должно в предельно лаконичной форме давать исчерпывающий
ответ на вопросы «Что произошло?» «Где это произошло»? «При каких условиях это
произошло?».
Например: «Отсутствует логотип на странице приветствия, если пользователь
является администратором»:
— Что произошло? Отсутствует логотип.
— Где это произошло? На странице приветствия.
— При каких условиях это произошло? Если пользователь является
администратором.
Заполнение поля «краткое описание», которое одновременно должно:
— содержать предельно краткую, но в то же время достаточную для
понимания сути проблемы информацию о дефекте;
— быть достаточно коротким, чтобы полностью помещаться на экране;
13.
— при необходимости содержать информацию об окружении, под
которым был обнаружен дефект;
— по возможности не дублировать краткие описания других
дефектов (и даже не быть похожими на них), чтобы дефекты
было сложно перепутать или посчитать дубликатами друг друга;
— быть законченным предложением русского или английского (или
иного) языка, построенным по соответствующим правилам
грамматики.
Для создания хороших кратких описаний дефектов рекомендуется пользоваться
следующим алгоритмом:
1. Полноценно понять суть проблемы. До тех пор, пока у тестировщика нет
чёткого понимания того, «что не работает», писать отчёт о дефекте не стоит.
2. Сформулировать подробное описание
3. 3. Убрать из получившегося подробного описания всё лишнее, уточнить
важные детали.
14.
4. Выделить в подробном описании слова (словосочетания, фрагменты фраз),
отвечающие на вопросы, «что, где и при каких условиях случилось».
5. Оформить получившееся в пункте 4 в виде законченного грамматически
правильного предложения.
6. Если предложение получилось слишком длинным, переформулировать
его, сократив длину (за счёт подбора синонимов, использования
общепринятых аббревиатур и сокращений). К слову, в английском языке
предложение почти всегда будет короче русского аналога.
Пример применения этого алгоритма.
Тестированию подвергается некое веб-приложение, поле описания товара должно
допускать ввод максимум 250 символов; в процессе тестирования оказалось, что
этого ограничения нет.
1. Суть проблемы: исследование показало, что ни на клиентской, ни на
серверной части нет никаких механизмов, проверяющих и/или
ограничивающих длину введённых в поле «О товаре» данных.
2. Исходный вариант подробного описания: в клиентской и серверной части
приложения отсутствуют проверка и ограничение длины данных, вводимых в
поле «О товаре» на странице http://testapplication/admin/goods/edit.
15.
3. Конечный вариант подробного описания:
— Фактический результат: в описании товара (поле «О товаре»,
http://testapplication/admin/goods/edit/) отсутствуют проверка и
ограничение длины вводимого текста (MAX=250 символов).
— Ожидаемый результат: в случае попытки ввода 251+ символов
выводится сообщение об ошибке.
4. Определение «что, где и при каких условиях случилось»:
— Что: отсутствуют проверка и ограничение длины вводимого текста.
— Где: описание товара, поле «О товаре»,
http://testapplication/admin/goods/edit/.
— При каких условиях: – (в данном случае дефект присутствует всегда, вне
зависимости от каких бы то ни было особых условий).
5. Первичная формулировка: отсутствуют проверка и ограничение
максимальной длины текста, вводимого в поле «О товаре» описания товара.
6. Сокращение (итоговое краткое описание): нет ограничения максимальной
длины поля «О товаре». Английский вариант: no check for «О товаре» max
length.
16.
• Подробное описание представляет в развёрнутом виде необходимую
информацию о дефекте, а также (обязательно!) описание фактического
результата, ожидаемого результата и ссылку на требование (если это
возможно).
Пример подробного описания:
Если в систему входит администратор, на странице приветствия отсутствует
логотип. Фактический результат: логотип отсутствует в левом верхнем углу
страницы. Ожидаемый результат: логотип отображается в левом верхнем
углу страницы. Требование: R245.3.23b.
В отличие от краткого описания, которое является одним предложением,
здесь нужно давать подробную информацию. Если одна и та же проблема
(вызванная одним источником) проявляется в нескольких местах
приложения, можно в подробном описании перечислить эти места.
• Шаги по воспроизведению описывают действия, которые необходимо
выполнить для воспроизведения дефекта.
17.
Это поле похоже на шаги тест-кейса, за исключением одного отличия: здесь
действия прописываются максимально подробно, с указанием конкретных
вводимых значений и самых мелких деталей, т.к. отсутствие этой информации в
сложных случаях может привести к невозможности воспроизведения дефекта.
Пример шагов воспроизведения:
1. Открыть http://testapplication/admin/login/.
2. Авторизоваться с именем «defaultadmin» и паролем «dapassword». Дефект: в
левом верхнем углу страницы отсутствует логотип (вместо него отображается
пустое пространство с надписью «logo»).
Воспроизводимость показывает, при каждом ли прохождении по шагам
воспроизведения дефекта удаётся вызвать его проявление. Это поле принимает
всего два значения: всегда или иногда. Можно сказать, что воспроизводимость
«иногда» означает, что тестировщик не нашёл настоящую причину возникновения
дефекта. Это приводит к серьёзным дополнительным сложностям в работе с
дефектом:
• Тестировщику нужно потратить много времени на то, чтобы удостовериться в
наличии дефекта (т.к. однократный сбой в работе приложения мог быть вызван
большим количеством посторонних причин).
18.
• Разработчику тоже нужно потратить время, чтобы добиться проявления
дефекта и убедиться в его наличии. После внесения исправлений в приложение
разработчик фактически должен полагаться только на свой профессионализм,
т.к. даже многократное прохождение по шагам воспроизведения в таком случае
не гарантирует, что дефект был исправлен (возможно, через ещё 10–20
повторений он бы проявился).
• Важность показывает степень ущерба, который наносится проекту
существованием дефекта. В общем случае выделяют следующие виды
важности:
— Критическая — существование дефекта приводит к масштабным последствиям
катастрофического характера, например: потеря данных, раскрытие
конфиденциальной информации, нарушение ключевой функциональности
приложения и т.д.
— Высокая — существование дефекта приносит ощутимые неудобства многим
пользователям в рамках их типичной деятельности, например: недоступность
вставки из буфера обмена, неработоспособность общепринятых клавиатурных
комбинаций, необходимость перезапуска приложения при выполнении типичных
сценариев работы.
19.
— Средняя — существование дефекта слабо влияет на типичные
сценарии работы пользователей, и/или существует обходной путь
достижения цели, например: диалоговое окно не закрывается
автоматически после нажатия кнопок «OK»/«Cancel», при распечатке
нескольких документов подряд не сохраняется значение поля
«Двусторонняя печать», перепутаны направления сортировок по
некоему полю таблицы.
— Низкая — существование дефекта редко обнаруживается
незначительным процентом пользователей и (почти) не влияет на их
работу, например: опечатка в глубоко вложенном пункте меню
настроек, некоторое окно при отображении расположено неудобно
(нужно перетянуть его в удобное место), неточно отображается время
до завершения операции копирования файлов.
20.
• Срочность показывает, как быстро дефект должен быть устранён. В общем
случае выделяют следующие виды срочности:
1. Наивысшая срочность указывает на необходимость устранить дефект
настолько быстро, насколько это возможно.
2. Высокая срочность означает, что дефект следует исправить вне очереди,
т.к. его существование или уже объективно мешает работе, или начнёт
создавать такие помехи в самом ближайшем будущем.
3. Обычная срочность означает, что дефект следует исправить в порядке
общей очерёдности. Такое значение срочности получает большинство
дефектов.
4. Низкая срочность означает, что в обозримом будущем исправление
данного дефекта не окажет существенного влияния на повышение
качества продукта.
21.
• Симптом — позволяет классифицировать дефекты по их типичному проявлению. Не
существует никакого общепринятого списка симптомов.
В качестве примера рассмотрим следующие значения симптомов дефекта.
1. Косметический дефект — визуально заметный недостаток интерфейса, не влияющий
на функциональность приложения (например, надпись на кнопке выполнена
шрифтом не той гарнитуры).
2. Повреждение/потеря данных — в результате возникновения дефекта искажаются,
уничтожаются (или не сохраняются) некоторые данные (например, при копировании
файлов копии оказываются повреждёнными).
3. Проблема в документации (— дефект относится не к приложению, а к документации
(например, отсутствует раздел руководства по эксплуатации).
4. Некорректная операция — некоторая операция выполняется некорректно
5. Проблема инсталляции — дефект проявляется на стадии установки и/или
конфигурирования приложения.
6. Ошибка локализации — что-то в приложении не переведено или переведено
неверно на выбранный язык интерфейса.
7. Нереализованная функциональность — некая функция приложения не выполняется
или не может быть вызвана (например, в списке форматов для экспорта документа
отсутствует несколько пунктов, которые там должны быть
22.
8. Проблема масштабируемости — при увеличении количества доступных
приложению ресурсов не происходит ожидаемого прироста
производительности приложения
9. Низкая производительность — выполнение неких операций занимает
недопустимо большое время
10. Крах системы — приложение прекращает работу или теряет способность
выполнять свои ключевые функции
11. Неожиданное поведение — в процессе выполнения некоторой типичной
операции приложение ведёт себя необычным (отличным от общепринятого)
образом (например, после добавления в список новой записи активной
становится не новая запись, а первая в списке).
12. Недружественное поведение — поведение приложения создаёт
пользователю неудобства в работе (например, на разных диалоговых окнах в
разном порядке расположены кнопки «OK» и «Cancel»).
13. Расхождение с требованиями — этот симптом указывают, если дефект сложно
соотнести с другими симптомами, но тем не менее приложение ведёт себя не
так, как описано в требованиях.
14. Предложение по улучшению — во многих инструментальных средствах
управления отчётами о дефектах для этого случая есть отдельный вид отчёта
23.
Часто у одного дефекта может быть сразу несколько симптомов.
15. Возможность обойти — показывает, существует ли альтернативная
последовательность действий, выполнение которой позволило бы
пользователю достичь поставленной цели (например, клавиатурная
комбинация Ctrl+P не работает, но распечатать документ можно, выбрав
соответствующие пункты в меню). В некоторых инструментальных
средствах управления отчётами о дефектах это поле может просто
принимать значения «Да» и «Нет», в некоторых при выборе «Да»
появляется возможность описать обходной путь. Традиционно
считается, что дефектам без возможности обхода стоит повысить
срочность исправления.
16. Комментарий— может содержать любые полезные для понимания и
исправления дефекта данные.
17. Вложения — представляет собой не столько поле, сколько список
прикреплённых к отчёту о дефекте приложений (копий экрана,
вызывающих сбой файлов и т.д.).