Ошибка дефект отказ отличия

Дефекты. Ошибки, сбои, отказы

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

Ожидаемый результат — поведение системы, описанное в требованиях.

Фактический результат — поведение системы, наблюдаемое в процессе тестирования.

Ошибки совершает человек , которые приводят к возникновению дефектов в коде, которые, в свою очередь, приводят к сбоям и отказам приложения (однако сбои и отказы могут возникать и из-за внешних условий, таких как электромагнитное воздействие на оборудование и т.д.). Таким образом, упрощённо можно изобразить следующую схему

Ошибка (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 не работает, но распечатать документ можно, выбрав соответствующие пункты в меню). В некоторых инструментальных средствах управления отчётами о дефектах это поле может просто принимать значения «Да» и «Нет», в некоторых при выборе «Да» появляется возможность описать обходной путь. Традиционно считается, что дефектам без возможности обхода стоит повысить срочность исправления.
• Комментарий— может содержать любые полезные для понимания и исправления дефекта данные.
• Вложения — представляет собой не столько поле, сколько список прикреплённых к отчёту о дефекте приложений (копий экрана, вызывающих сбой файлов и т.д.).

• Схема
• Cтатусы багов
• Другие статусы (этапы цикла)
• Действия в багтрекере
• Указания
• Ошибка, дефект, отказ
• Инвалиды и дубликаты
• Еще нюансы
• Жизненный цикл дефекта в Bugzilla (схемы)

В процессе разработки всегда возникают дефекты (баги), которые тестировщики стараются найти, а разработчики пофиксить, то есть устранить. В баг-трекинговой системе фиксируется статус дефекта, и действия участников команды. Все происходит упорядоченно (поэтапно), нередко бывают повторные этапы. Баг проходит от «рождения» (Новый) до «смерти» (Закрыт). Этот процесс называется жизненным циклом дефекта.

Дефектом называют ошибку в компьютерной программе, возникающую в процессе проектирования или написания кода программы. Ошибка заключается в некорректном поведении программы. Цель QA-команды состоит в обнаружении дефектов как можно раньше, и как можно большего количества дефектов, что повышает итоговое качество программы. Продукт без дефектов соответствует требованиям заказчика и предоставляет услуги пользователям на должном уровне.

Понятия баг и дефект, а также жизненный цикл дефекта и жизненный цикл бага в данной статье взаимозаменяемы. 

Жизненный цикл бага

Цикл обработки дефекта (бага), с присвоением ему различных статусов после выполнения различных действий — начиная с регистрации нового бага в системе и до закрытия после устранения. 

Некоторые этапы цикла могут зависеть от компании и принятых в ней процедур, методик тестирования и инструментов, а главным образом от используемого баг-трекера (поэтому схемы в разных источниках отличаются).

Общая схема жизненного цикла дефекта (например, в Jira):

Список статусов бага

1. Новый

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

1. Назначен

Когда новый дефект подтвержден и принят в обработку, получает статус Назначен (Assigned). Как правило назначается ответственный за устранение этого бага (поэтому статус еще может называться «Назначен НА кого-то»). 

1. Открыт

Open-статус означает, что дефект приняли разработчики и начали процесс устранения.

На этом этапе возможен переход в статус «Отклонен» или «Отложен», то есть разработчик может «не принять» этот дефект — отклонить или отложить.

1. Устранен

Или Решен/Исправлен (Fixed, Resolved). Разработчики поработали с кодом, внесли нужные правки, пометили статусом «Исправлен», и возвращают тестировщикам для повторной проверки.

1. Ожидает повторного тестирования

В статусе Pending Retest дефект ожидает, когда тестировщики повторно проверят его, убедившись что все ОК, код теперь исправлен.

1. Повторно тестируется

Retest: тестировщик еще раз проверяет этот дефект, и убедившись что он устранен разработчиками, верифицирует это и закрывает дефект, а в противном случае переоткрывает.

1. Повторно открыт

Если повторное тестирование не смогло устранить баг, обнаруживается снова, ему присваивается статус Reopen. Баг открывается опять и еще раз проходит по циклу.

1. Проверен

Тестировщик еще раз проверяет (верифицирует) баг, повторно исправленный разработчиком, и если теперь он не проявляется, присваивается статус Verified.

1. Закрыт

Разработчики и тестировщики общими усилиями нашли и устранили дефект, он больше не появляется, и можно присвоить статус Closed.

Другие статусы в баг-трекерах

1. Отклонен

Разработчик отклонил этот дефект, присвоив статус Rejected, потому что дефект или является дубликатом (уже внесен в систему кем-то из коллег), дефект не воспроизводится, или вообще не считается дефектом. 

1. Отложен

Некоторые дефекты могут счесть не очень важными, не приоритетными, следовательно их можно отложить на потом и устранить в следующих релизах, присвоив статус Deferred и исключив из цикла сейчас.

1. Дубликат

Этот дефект уже зарегистрирован другим тестировщиком, или суть дефекта та же, тогда присваивается статус Duplicate.

1. Не дефект

Баг может и есть, но ни на что не влияет, ни в чем не ухудшает функциональность и юзабельность — отмечается статусом Not a Defect.

1. Не воспроизводится

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

1. Невозможно устранить

Бывают ситуации, когда баг устранить невозможно по какой-то причине: недостатки технологии, стоимость, нехватка времени, недостаточная квалификация или просто лень. Он переводится в статус Can’t be fixed.

1. Требует уточнения

Статус Need more information по сути близок к «Не воспроизводится» выше, но с нюансами. Такой статус присваивается, когда разработчики не сумели воспроизвести баг по шагам, предоставленным тестировщиком, или если тестировщик составил не очень подробный репорт.

Подробнее о действиях в баг-трекере

В словесной форме (и в других баг-трекерах кроме Jira) это выглядит примерно так:

• Дефект обнаруживается тестировщиком.
• Тестировщик присваивает ему статус «Новый».
• О новом дефекте тотчас узнает проджект-менеджер, который исследует ситуацию — является ли дефект действительно дефектом, стОит ли устранять сейчас и пр.
• Если нет, дефекту присваивается статус «Отклонен».
• Если дефект действительно существует, и стОит внимания сейчас, проджект-менеджер проверяет, является ли дефект дубликатом и если да, обозначается как дубликат.
• Если не дубликат, дефект передается в работу разработчику, который начинает действия по устранению проблемы, с присвоением статуса «In Progress», и по завершению — «Исправлен».
• Далее дефект возвращается в зону ответственности тестировщика под статусом «Повторно тестируется». Тестировщик снова запускает тест-кейсы, и если дефект опять проявляется, повторно открывает его и возвращает разработчику.
• А если все хорошо, дефект закрывается, с присвоением соответствующего статуса «Закрыт».

Указания по эффективности жизненного цикла

• Важно, чтобы все команды, участвующие в проекте, понимали этапы жизненного цикла и свою ответственность на этапах
• Это позволит избежать недопонимания и «сваливания ответственности»
• От тестировщиков особо требуется четкое и понятное описание сути дефекта, и почему присвоен тот или иной статус
• От разработчиков требуется оперативнее устранять дефекты, не откладывая «на потом»

Ошибка, дефект (баг) и отказ в контексте жизненного цикла дефекта

• Ошибка (error) — например когда разработчик видит отличие между тем как приложение себя ведет и тем как должно себя вести, в процессе разработки
• Дефект (баг) — случается когда тестировщик обнаруживает несоответствие между реальным и предполагаемым поведением приложения в процессе тестирования
• Отказ (failure) — несоответствие реального и предполагаемого поведения обнаруживается уже в процессе пользования приложением конечным пользователем, клиентом, или тестировщиком на этапе приемочного тестирования.

Инвалиды и дубликаты

• Имеются в виду «невалидные» дефекты в баг-репортах, то есть те которые возникают не из-за ошибок в коде, допущенных разработчиком, а из-за некорректно работающего тестового окружения, или просто по ошибке в процессах тестирования; такой дефект считается «не валидным», не подтвержденным, поэтому отклоняется
• Дубликат дефекта возникает, когда по этой проблеме уже открыт/заведен как минимум один дефект; дубликат закрывается
• Над процессами в жизненном цикле дефекта надзирает тест-менеджер/старший тестировщик/лид/проджект-менеджер, в зависимости от того как в команде выстроены процессы. Присвоение статусов в конечном счете решается ими, на основе стоимости, времени и усилий, нужных на устранение дефекта
• Также ими решается вопрос, какие присвоить приоритет и серьезность

Что еще нужно помнить о жизненном цикле багов

• Дефекты могут возникать на любом этапе разработки и тестирования
• Чем раньше дефект обнаружен и устранен, тем лучше (выгоднее для компании)
• В идеале — на том же этапе, когда дефект найден (тогда «стоимость дефекта» минимальная)
• Статическое тестирование (анализ кода без выполнения), проводимое на раннем этапе разработки, выгоднее чем дебаг на позднем

Жизненный цикл дефекта в Bugzilla (в принципе релевантно для любого багтрекера)

Сложнее, но с объяснениями:

***

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. Вложения — представляет собой не столько поле, сколько список
прикреплённых к отчёту о дефекте приложений (копий экрана,
вызывающих сбой файлов и т.д.).

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

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

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

© Оригинальный блог-пост