• Определение Bug-а
• Разница между болезнью (багом) и её проявлениями (симптомами)
• Составляющие бага, что “внутри”
• Как правильно искать баги? - техники и подходы
• Что такое bug Investigation?
• Как правильно записывать баги
• Жизненный цикл бага
• виды и типы багтрекинговых систем

В программировании баг (англ. bug — первичные значения: клоп, любое насекомое, вирус) — жаргонное слово, обычно обозначающее ошибку впрограмме или системе, из-за которой программа выдает неожиданное поведение и, как следствие, результат. Большинство багов возникают из-за ошибок, допущенных разработчиками программы в её исходном коде, либо в её дизайне. Также некоторые баги возникают из-за некорректной работы компилятора, вырабатывающего некорректный код. Программу, которая содержит большое число багов и/или баги, серьёзно ограничивающие её работоспособность, называют нестабильной или, на жаргонном языке, «глючной», «глюкнутой», «забагованной», «бажной», «баг(а)нутой»).

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

«Баги» локализуются и устраняются в процессе тестирования и отладки программы.

Этимология термина «баг»

Запись в тех.журнале

В значении неуловимой технической ошибки слово жучок (англ. bug) употреб***ялось задолго до появления компьютеров персоналом телеграфных и телефонных компаний в отношении неполадок с электрооборудованием и радиотехникой. В 1878 году Томас Эдисон писал[1]:

«Так было со всеми моими изобретениями. Первый шаг — интуиция, которая приходит как вспышка, затем возникают трудности — устройство отказывается работать, и именно тогда проявляются «жучки» — как называют эти мелкие ошибки и трудности — и требуются месяцы пристального наблюдения, исследований и усилий, прежде чем дело дойдёт до коммерческого успеха или неудачи».

Во время Второй мировой войны словом «bugs» назывались проблемы с радарной электроникой.

По одной из версий, в отношении программной ошибки этот термин впервые применила в 1946 году Грейс Хоппер, программировавшая в Гарвардском университете вычислительную машину Harvard Mark II (англ.)русск.. Проследив ошибку в работе программы до электромеханического реле машины, она нашла мотылька, застрявшего между контактами. Извлечённое насекомое было вклеено скотчем в технический дневник с сопроводительной надписью: «Первый реальный случай обнаружения жучка» (англ. First actual case of bug being found)[2].

Значение и классификация ошибок программного обеспечения

В зависимости от этапа разработки ПО, на котором выявляется ошибка выделяют:

• синтаксические ошибки (распознаваемые в качестве таковых транслятором и делающие компиляцию невозможной) — например отсутствие или несоответствие открывающей и закрывающей скобок;
• предупреждения (warnings) компилятора — например, использование неинициализированной переменной. В этом случае компилятор может заметить, что программист делает что-то необычное (вероятно неверное), и сообщает об этом, однако программист сам принимает решение игнорировать сообщение или нет;
• ошибки времени исполнения, смысловые ошибки (семантические) — например вычитание переменных вместо сложения или ошибка сегментации.

По размеру:

• Showstoppers;
• Серьёзные;
• Незначительные баги;

По времени появления:

• Постоянно, при каждом запуске;
• Иногда («плавающий» тип);
• Только на машине у клиента (зависит от локальных настроек у клиента);

По месту и направлению:

• Ошибки пользовательского интерфейса;
• Системы обработки ошибок;
• Ошибки, связанные с граничными условиями;
• Ошибки вычислений;
• Ошибки управления потоком;
• Ошибки обработки или интерпретации данных;
• При состоянии гонки;
• Повышение нагрузки;
• Ошибки контроля версии и индентификаторов;
• Ошибки тестирования;

В зависимости от характера ошибки, программы и среды исполнения, ошибка может проявляться сразу или наоборот — долгое время оставаться незамеченной (например Проблема 2038 года).

Также ошибка может проявляться в виде уязвимости, делающей возможным несанкционированный доступ к системе или DoS-атаку.

Разновидности

• Борбаг — легко обнаруживаемый стабильный баг
• Гейзенбаг — сложно обнаруживаемый, периодически исчезающий и меняющий свойства баг при попытке его обнаружения
• Мандельбаг — баг с очень сложным, хаотичным, поведением
• Шрёдинбаг — критическая ошибка, которая не проявляется пока кто-нибудь на неё не наткнется в исходном коде, после чего программа совершенно перестает работать

Поиск и исправление ошибок

Для отладки программы (англ. debugging) разработчиками ПО используются специальные программы-отладчики (англ. debugger). Например, в операционной системе Windows можно использовать программу WinDbg из пакета Microsoft Debugging Tools for Windows. Для GNU/Linux и ряда другихUNIX-подобных операционных систем существует отладчик GDB (GNU Debugger).

См. также: Патч

Отчёты об ошибках

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

Например, в операционную систему Windows встроена утилита Dr. Watson, которая по умолчанию отлавливает ошибки в приложениях пользователя и отправляет отчёт на специальный Сервер компании Microsoft. Также в качестве примера можно привести аналогичные библиотеки Breakpad[3] и CrashRpt[4].

Последствия остоящих компьютерных багов в истории.

• Ошибки в программном обеспечении медицинского ускорителя Therac-25 привели к превышению доз облучения нескольких людей.

См. также

• Отчет об ошибке
• Система отслеживания ошибок
• Фича
• GIGO

Система отслеживания ошибок

Система отслеживания ошибок (англ. bug tracking system) — прикладная программа, разработанная с целью помочь разработчикам программного обеспечения (программистам, тестировщикам и др.) учитывать и контролировать ошибки и неполадки, найденные в программах, пожелания пользователей, а также следить за процессом устранения этих ошибок и выполнения или невыполнения пожеланий.

Содержание

• 1Состав информации о дефекте
• 2Жизненный цикл дефекта
• 3Примеры систем отслеживания ошибок
• 4Примечания
• 5См. также
• 6Ссылки

Состав информации о дефекте

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

• номер (идентификатор) дефекта;
• короткое описание дефекта;
• кто сообщил о дефекте;
• дата и время, когда был обнаружен дефект;
• версия продукта, в которой обнаружен дефект;
• серьёзность (критичность) дефекта и приоритет решения[1];
• описание шагов для выявления дефекта (воспроизведения неправильного поведения программы);
• ожидаемый результат и фактический результат;
• кто ответственен за устранение дефекта;
• обсуждение возможных решений и их последствий;
• текущее состояние (статус) дефекта;
• версия продукта, в которой дефект исправлен.

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

Жизненный цикл дефекта

Как правило, система отслеживания ошибок использует тот или иной вариант «жизненного цикла» ошибки, стадия которого определяется текущим состоянием, или статусом, в котором находится ошибка.

Типичный жизненный цикл дефекта:

1. Новый — дефект зарегистрирован тестировщиком
2. Назначен — назначен ответственный за исправление дефекта
3. Разрешён — дефект переходит обратно в сферу ответственности тестировщика. Как правило, сопровождается резолюцией, например:
   • Исправлено (исправления включены в версию такую-то)
   • Дубль (повторяет дефект, уже находящийся в работе)
   • Не исправлено (работает в соответствии со спецификацией, имеет слишком низкий приоритет, исправление отложено до следующей версии и т.п.)
   • Невоспроизводимо (запрос дополнительной информации об условиях, в которых дефект проявляется).
4. Далее тестировщик проводит проверку исправления, в зависимости от чего дефект либо снова переходит в статус Назначен (если он описан как исправленный, но не исправлен), либо в статус Закрыт.
5. Открыт повторно — дефект вновь найден в другой версии.

Система может предоставлять администратору возможность настроить, какие пользователи могут просматривать и редактировать ошибки в зависимости от их состояния, переводить их в другое состояние или удалять.

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

Примеры систем отслеживания ошибок

Свободно распространяемые

• Redmine — не относится к системам отслеживания ошибок, но многие компании его используют.
• BUGS - the Bug Genie http://www.thebuggenie.com/
• Bugzilla http://www.bugzilla.org/features/
• eTraxis https://www.etraxis.com/
• GNATS
• Launchpad
• Mantis bug tracking system
• Trac
• EmForge
• Picket
• Flyspray (сайт)
• DEVPROM

Проприетарные

• Atlassian JIRA
• Bontq
• PVCS Tracker
• Project Kaiser
• TrackStudio Enterprise
• YouTrack

Разное

• BugTracker.NET
• BugNet
• ClearQuest
• Intland CodeBeamer
• LifeTask.ru
• FlySpray
• StarTeam

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

Баг Репорт (Bug Report)

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

Для получения более детальной информации о баг репорте, мы рекомендуем Вашему вниманию следующую информацию, ознакомившись с которой вы получите исчерпывающее представление о структуре, особенности написания и некоторых других нюансах, необходимых для написания, хороших баг репортов:

• Структура баг репорта
• Серьезность и Приоритет дефекта
• Написание баг репортов
• Жизненный цикл бага

Основные поля баг / дефект репорта

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

Шапка
Короткое описание (Summary)	Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.
Проект (Project)	Название тестируемого проекта
Компонент приложения (Component)	Название части или функции тестируемого продукта
Номер версии (Version)	Версия на которой была найдена ошибка
Серьезность (Severity)	Наиболее распространена пятиуровневая система градации серьезности дефекта: S1 Блокирующий (Blocker) S2 Критический (Critical) S3 Значительный (Major) S4 Незначительный (Minor) S5 Тривиальный (Trivial) (подробнее смотрите ниже в разделе Серьезность дефекта)
Приоритет (Priority)	Приоритет дефекта: P1 Высокий (High) P2 Средний (Medium) P3 Низкий (Low) (подробнее смотрите ниже в разделе Приоритет дефекта)
Статус (Status)	Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle)
Автор (Author)	Создатель баг репорта
Назначен на (Assigned To)	Имя сотрудника, назначенного на решение проблемы
Окружение
ОС / Сервис Пак и т.д. / Браузера + версия / ...	Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования - имя и версия браузера и т.д.
...
Описание
Шаги воспроизведения (Steps to Reproduce)	Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.
Фактический Результат (Result)	Результат, полученный после прохождения шагов к воспроизведению
Ожидаемый результат (Expected Result)	Ожидаемый правильный результат
Дополнения
Прикрепленный файл (Attachment)	Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы

Серьезность и Приоритет Дефекта

Разные системы баг трекинга предлагают нам разные пути описания серьезности и приоритета баг репорта, неизменным остается лишь смысл, вкладываемый эти поля. Все знают такой баг-трекер, как Atlassian JIRA. В нем, начиная с какой-то версии вместо одновременного использования полей Severity и Priority, оставили только Priority, которое собрало в себе свойства обоих полей: Originally, JIRA did have both a Priority and a Severity field. The Severity field was removed for a number of reasons...Таким образом, те кто привык работать с JIRA не всегда понимают разницу между этими понятиями, так как не имели опыта их совместного использования. Исходя из личного опыта, я настаиваю на разделении этих понятий, а точнее на использовании обоих полей Severity и Priority, так как смысл, вкладываемый в них, различный:

Серьезность (Severity) - это атрибут, характеризующий влияние дефекта на работоспособность приложения.

Приоритет (Priority) - это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.

Градация Серьезности дефекта (Severity)

S1 Блокирующая (Blocker)
Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.

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

S3 Значительная (Major)
Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.

S4 Незначительная (Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.

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

Градация Приоритета дефекта (Priority)

P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.

P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.

P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

Порядок исправления ошибок по их приоритетам:

High -> Medium -> Low

Требования к количеству открытых багов

Хотим предложить вам следующий подход к определению требований к количеству открытых багов:

• Наличие открытых дефектов P1, P2 и S1, S2, считается неприемлемым для проекта. Все подобные ситуации требуют срочного решения и идут под контроль к менеджерам проекта.
• Наличие строго ограниченного количества открытых ошибок P3 и S3, S4, S5 не является критичным для проекта и допускается в выдаваемом приложении. Количество же открытых ошибок зависит от размера проекта и установленных критериев качества.

Все требования к открытым ошибкам оговариваются и документируются на этапе принятия решения о качестве разрабатываемого продукта. Как пример документирования подобных требований - это пунктКритерии окончания тестирования в плане тестирования

Написание баг репорта

Баг репорт - это технический документ и в связи с этим хотим отметить, что язык описания проблемы должен быть техническим. Должна использоваться правильная терминология при использовании названий элементов пользовательского интерфейса (editbox, listbox, combobox, link, text area, button, menu, popup menu, title bar, system tray и т.д.), действий пользователя (click link, press the button, select menu item и т.д.) и полученных результатах (window is opened, error message is displayed, system crashed и т.д.).

Требования к обязательным полям баг репорта

Отметим, что обязательными полями баг репорта являются: короткое описание (Bug Summary),серьезность (Severity), шаги к воспроизведению (Steps to reproduce), результат (Actual Result),ожидаемый результат (Expected Result). Ниже приведены требования и примеры по заполнению этих полей.

Короткое описание

Название говорит само за себя. В одном предложение вам надо уместить смысл всего баг репорта, а именно: коротко и ясно, используя правильную терминологию сказать что и где не работает. Например:

1. Приложение зависает, при попытке сохранения текстового файла размером больше 50Мб.
2. Данные на форме "Профайл" не сохраняются после нажатия кнопки "Сохранить".

В дополнение предлагаем вам изучить Принцип "Где? Что? Когда?", описанный на страницах блога"QA Nest":

"В чем этот принцип состоит?
Составьте предложение, в котором факты дефекта изложены в следующей последовательности:

• Где?: В каком месте интерфейса пользователя или архитектуры программного продукта находится проблема. Причем, начинайте предложение с существительного, а не предлога.
• Что?: Что происходит или не происходит согласно спецификации или вашему представлению о нормальной работе программного продукта. При этом указывайте на наличие или отсутствие объекта проблемы, а не на его содержание (его указывают в описании). Если содержание проблемы варьируется, все известные варианты указываются в описании.
• Когда?: В какой момент работы программного продукта, по наступлению какого события или при каких условиях проблема проявляется.

Почему последовательность должна быть именно такой?
В таком виде незнакомые дефекты удобнее сортировать по summary как показывает практика (ведь, скорее всего, именно среди дефектов других инженеров будет производиться поиск дубликатов). Если вы другого мнения - придумайте свою последовательность, но она должна стать единой для всех без исключения членов проекта, иначе вы не добьетесь необходимого результата."

Серьезность

В двух словах можно отметить, что если проблема найдена в ключевой функциональности приложения и после ее возникновения приложение становится полностью недоступно, и дальнейшая работа с ним невозможна, то она блокирующая. Обычно все блокирующие проблемы находятся во время первичной проверки новой версии продукта (Build Verification Test, Smoke Test), т.к. их наличие не позволяет полноценно проводить тестирование. Если же тестирование может быть продолжено, то серьезность данного дефекта будет критическая. На счет значительных, незначительных и тривиальныхошибок вопрос достаточно прозрачный и на наш взгляд не требует лишних объяснений.

Шаги к воспроизведению / Результат / Ожидаемый результат

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

Например:

Шаги к воспроизведению
1. Войдите в системы: Пользователь Тестер1, пароль xxxXXX
--> Вход в систему осуществлен
2. Кликните линк Профайл
--> Страница Профайл открылась
3. Введите Новое имя пользователя: Тестер2
4. Нажмите кнопку Сохранить
Результат
На экране появилась ошибка. Новое имя пользователя не было сохранено
Ожидаемый результат
Страница профайл перегрузилась. Новое значение имени пользователя сохранено.

Основные ошибки при написании багов репортов

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

Определение серьезности
Очень часто происходит либо завышение, либо занижение серьезности дефекта, что может привести к неправильной очередности при решении проблемы.

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

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

Заполнение полей баг репорта

В описанной ниже таблице представлены основные поля баг репорта и роль работника, ответственного за заполнение данного поля. Красным цветом выделены обязательные для заполнения поля:

Поле	Ответственный за заполнение поля
Короткое описание (Summary)	Автор баг репорта (обычно это Тестировщик)
Проект (Project)	Автор баг репорта (обычно это Тестировщик)
Компонент приложения (Component)	Автор баг репорта (обычно это Тестировщик)
Номер версии (Version)	Автор баг репорта (обычно это Тестировщик)
Серьезность (Severity)	Автор баг репорта (обычно это Тестировщик), однако данный атрибут может быть изменен вышестоящим менеджером
Приоритет (Priority)	Менеджер проекта или менеджер ответственный за разработку компонента, на который написан баг репорт
Статус (Status)	Автор баг репорта (обычно это Тестировщик), но многие системы баг трекинга выставляют статус по умолчанию
Автор (Author)	Устанавливается по умолчанию, если нет, то указывается имя автора баг репорта
Назначен на (Assigned To)	Менеджер проекта или менеджер ответственный за разработку компонента, на который написан баг репорт
ОС / Сервис Пак и т.д. / Браузера + версия / ...	Автор баг репорта (обычно это Тестировщик)
Шаги воспроизведения (Steps to Reproduce)	Автор баг репорта (обычно это Тестировщик)
Фактический Результат (Result)	Автор баг репорта (обычно это Тестировщик)
Ожидаемый результат (Expected Result)	Автор баг репорта (обычно это Тестировщик)
Прикрепленный файл (Attachment)	Автор баг репорта (обычно это Тестировщик), а также любой член командной группы, считающий, что прикрепленные данные помогут в исправлении бага

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

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

Теперь переходим к описанию данной схемы.

Допустим вы нашли баг и зарегистрировали его в баг трекинг системе. Согласно нашей блок-схеме он получит статус “Новый”. Тестировщик, ответственный за валидацию новых баг репортов, или координатор проекта (в зависимости от распределения ролей в вашей команде) может перевести его в один из следующих статусов:

• “Отклонен”, если данный баг невалидный или повторный, или же его просто не смогли воспроизвести
• “Отсрочен”, если данный баг не нужно исправлять в данной итерации
• “Открыт”, если исправление бага необходимо

Рассмотрим теперь по порядку каждый из вариантов.

1. Отклонен. В этом случае вы можете либо поспорить о судьбе вашего багрепорта, изменив статус на “Переоткрыт” либо закрыть его - статус “Закрыт”
2. Отсрочен. Баг репорт в статусе “Отсрочен” можно перевести в статус “Открыт”, когда потребуется исправление либо в статус “Закрыт”, если уже не потребуется.
3. Открыт. Именно в таком состоянии разработчик получает баг репорт для исправления. Он может отклонить (дальнейшие действия смотрите в пункте 1) или исправить баг. Баг репорт в статусе “Исправлен” переводится на тестировщика для проверки. В случае если проблема все еще воспроизводится, выставляется статус “Переоткрыт” и баг репорт направляется назад на доработку к разработчику. Если же исправление было успешным, то баг репорт переводится в статус “Закрыт”.

* * *

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

Примечание 1: в некоторых системах баг трекинга созданный баг репорт сразу получает статус “Открыт” без дополнительной валидации

Примечание 2: многие баг трекинговые системы позволяют переоткрывать закрытые баги, однако лично я против такой практики, поэтому и не описывал подобный переход в выше представленном жизненном цикле

Примечание 3: Рассмотренный выше жизненный цикл основан на том, что в команде есть кто-то, ответственный за назначение баг репортов. В случае, если такой роли на проекте нет, то баги назначаются разработчиками самостоятельно, и тогда во избежании путанницы, есть смысл ввести еще один промежуточный статус “В разработке” (In progress), показывающий, что данный баг репорт уже назначен и находится на стадии исправления. Пример реализации подобного жизненного цикла на базе JIRA можно увидеть на следующем рисунке: