Software Test

Трекинг. Часть I. Основы.

Введение
Определение
Bug report (пункты)
Bug report (детали)

Введение.

Думаю, буду не далек от истины, если возьмусь утверждать, что главной деятельностью тестировщика является обнаружение багов. Но ошибку мало найти. О найденной проблеме нужно сообщить программисту, который затем исправит ее, или другому ответственному за это члену команды. Однако и это еще не все: После того как ошибка исправлена, необходимо будет провести тест, который выявлял ее ранее, еще раз - чтобы убедится, что это исправление действительно имеет место, кроме того необходимо будет провести целый набор тестов для того, чтобы удостоверится в том, что сделанное исправление не нарушило работу других частей программы. Не буду углубляться в дальнейший процесс тестирования - это удел других статей. Цель этой статьи несколько иная - разобраться в том, что же делать с обнаруженным багом, а точнее из чего состоит отчет о проблеме. Эта статья - первая из цикла <Трекинг>.

Определение.

Вначале определимся, что такое отчет о проблеме (Bug Report) и в чем состоит отслеживание проблем (bug tracking).

Итак, отслеживание проблемы (bug tracking) в простейшем варианте - это процесс, включающий в себя обнаружение ошибки, ее описание, исправление и проверку этого исправления, т.е. процесс <слежения> за багом в течение всего как его жизненного цикла, так и жизненного цикла разработки в целом.

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

Bug report (пункты).

Итак, тест проведен, ошибка найдена, при этом сомнений в том, что ошибка имеет место - нет. Что делать дальше? Необходимо сообщить разработчику (программисту) о том, что ошибка найдена, т.е. написать отчет о проблеме (bug report).

Что необходимо писать в таком отчете? Давайте попробуем разобраться...

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

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

Bug report (детали).

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

Название тестируемой программы.

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

Вносится - тестировщиком.

Модифицируется - тем, кто внес или уполномоченным лицом (руководителем или менеджером).

Номер версии тестируемой программы.

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

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

Вносится в первую очередь самим тестировщиком, а в большинстве случаев - только им.

Модифицируется - тем, кто внес или уполномоченным лицом (руководителем или менеджером).

Номер сборки программы.

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

В бумажной версии - заполняется соответствующая графа.

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

Вносится - тестировщиком.

Модифицируется - тем, кто внес или уполномоченным лицом (руководителем или менеджером).

Сам процесс нумерации версии, ее сборок, отслеживания изменений в них и т.п. не является материалом данной статьи, и поэтому перейдем к следующему пункту.

Функциональная область.

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

В бумажной версии - заполняется соответствующая графа.

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

Вносится - тестировщиком.

Модифицируется - тем, кто внес или уполномоченным лицом (руководителем или менеджером).

ФИО лица составившего отчет.

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

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

Мне попадались системы, где вместо имени/фамилии использовался username аккаунта, которой может не иметь ничего общего с реальным именем. На мой взгляд, такой подход не очень удобен.

В бумажной версии - заполняется соответствующий пункт.

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

Вносится - тестировщиком или автоматически.

Модифицируется - чаще всего не модифицируется или модифицируется тем, кто внес или уполномоченным лицом (руководителем или менеджером).

Дата составления.

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

В бумажной версии - заполняется соответствующий пункт отчета.

В электронной - вносится автоматически.

Вносится - автоматически при составлении отчета тестировщиком.

Дата последней модификации.

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

В бумажной версии - заполняется соответствующий пункт отчета.

В электронной - вносится автоматически.

Вносится - автоматически при составлении отчета тестировщиком.

Серьезность проблемы (Severity).

Данный пункт позволяет классифицировать баги по их серьезности, т.е. на сколько сильно данная проблема "вредит" функциональности. Перечень Severity и их количество может варьироваться в различных компаниях. Наиболее употребительными могут быть следующие:

Fatal (Critical, Causing crash) - проблемы, приводящие к зависанию и/или разрушению системы, потере данных, не имеющие workaround и т.д.
Serious - ошибки в функциональности имеющие workaround.
Minor (Cosmetic) - мелкие ошибки не мешающие работе программы.
Suggestion (Enhancement) - предложение по улучшению (например, интрефейса).
Question (Вопрос) - отчет о проблеме, если существует сомнение в том, является ли описываемая ситуация багом (например, в документации не описано поведение программы в данной ситуации и тестировщик сомневается, является ли полученный в ходе тестирования результат правильным).

Кроме того, Severity могут вообще не иметь названия, а быть просто пронумерованы.

Последние два значения (Suggestion и Question) могут входить в состав графы Тип отчета, если таковая присутствует в используемой системе трекинга (подробнее см. ниже).

Более подробно об этом очень важном пункте в отчете о проблеме можно почитать на сайте в разделах Статьи. К вопросу о ведении базы. и Школа. Классификация багов.

В бумажной версии - заполняется соответствующий пункт отчета.

В электронной - выбирается из списка.

Вносится - тестировщиком.

Приоритет (Priority).

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

Очень высокий (very high) - ошибки с этим приоритетом исправляются в первую очередь.
Высокий (high) - исправляются после того, как ликвидированы все ошибки very high.
Низкий (low) - проблемы с таким приоритетом "чинятся" по мере возможности.
Очень низкий (very low) - исправление этих ошибок может быть отложено на неопределенный срок, если останется на них время.

или 3:

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

Сэм Канер с соавторами в своей книге "Тестирование программного обеспечения" пишет об использовании 5-10 бальной системы приоритетов, при этом приводит в качестве примера 6-ти бальную систему:
"(1) Исправить немедленно - ошибка задерживает работу других сотрудников.
(2) Исправить как можно быстрее.
(3) Исправить в текущей версии (альфа, бета и т.д.).
(4) Исправить до выхода окончательной версии.
(5) Исправить, если возможно.
(6) Не обязательно - сделайте, как посчитаете нужным."

Более подробно о приоритетах можно почитать на сайте в разделах Статьи. К вопросу о ведении базы. и Школа. Классификация багов.

В бумажной версии - заполняется соответствующий пункт отчета.

В электронной - выбирается из списка.

Вносится - только руководителем проекта или менеджером.

Модифицируется - руководителем проекта или менеджером.

Статус (состояние) (Status).

Статус позволяет определить, на какой стадии своего жизненного цикла находится баг. Иными словами статус характеризует, на какой стадии в настоящий момент находится работа над багом. Кроме того, в электронных системах трекинга данное поле может использоваться для составления фильтров, с помощь которых пользователями системы будет вестись поиск багов в зависимости от их роли в проекте. Например, программист будет вести поиск по статусам Новый (New (Open)) и Переделать (Re-do (Re-open)), а тестер - по статусу Исправлено (Fixed (Added)) и т.д.

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

Новый (New (Open)) - статус, присваиваемый только что составленному отчету о проблеме.
В работе (In process) - статус, говорящий о том, что в настоящий момент идет работа по исправлению (или принятию иного решения).
Исправлено (Fixed (Added)) - описанная ошибка исправлена, необходима проверка исправления.
Переделать (Re-do (Re-open)) - в ходе проверки исправления баг обнаружен повторно.
Закрыто (Closed (Verified)) - описанная ошибка проверена, исправление действительно имеет место, дальнейшая работа над описанным в рапорте багом остановлена.
Отложено (Deffered) - исправление отложено на неопределенный срок.

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

Более подробно о состояниях можно почитать на сайте в разделах Статьи. Состояния багов. и Статьи. К вопросу о ведении базы.

Сэм Канер с соавторами в упомянутой выше книге рекомендуют несколько иные состояния:

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

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

В бумажной версии - заполняется соответствующий пункт отчета.

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

Вносится - тестировщиком.

Модифицируется - тестировщиком (New, Re-do (Re-open), Closed (Verified)); программистом (В работе (In process), Исправлено (Fixed (Added))); руководителем проекта или менеджером (в зависимости от роли в проекте список доступных статусов может различаться. Например, тестировщик не может выставлять статус "исправлено", а программист - выставлять статус "закрыто").

Тип отчета (Problem type).

Данная графа в системах трекинга, которые мне довелось видеть, не встречалась. Тем не менее она достаточно важна, так как очень часто параметры этого пункта приходится добавлять в другие (например, Suggestion и Question в пункте Severity). В этой графе указывают тип обнаруженной проблемы.

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

Некоторые системы трекинга позволяют создавать не только свои собственные параметры для отдельных полей отчета, но и сами поля. В любом случае лучше не смешивать параметры разных полей, как это сделано выше для поля Severity (Question и Suggestion). Это несколько запутывает и усложняет понимание системы в целом. Тем не менее многое зависит не только от используемой системы трекинга, но и от организации процесса отслеживания проблем и разработке в целом. И Question, и Suggestion вполне могут быть расценены как степени серьезности проблемы, что, на мой взгляд, не совсем верно.

В бумажной версии - заполняется соответствующий пункт отчета.

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

Вносится и модифицируется - тестировщиком.

Повторяемость (Recurrence).

Данная графа отчета является ответом на вопрос "Можете ли Вы воспроизвести проблему?" Т.е. стабильно ли при проведении данного теста проявляется описываемая ошибка. Вариантами ответа могут быть (по Канеру):

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

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

В бумажной версии - заполняется соответствующий пункт отчета.

В электронной - значение выбирается из списка.

Вносится и модифицируется - тестировщиком.

Идентификатор (Identifier).

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

В бумажной версии - заполняется соответствующий пункт отчета.

В электронной - значение присваивается автоматически.

Вносится - тестировщиком.

Модифицируется - после сохранения сообщения в базе данных - не модифицируется.

Краткое описание (Description).

Сжатое описание сути проблемы. Это описание используется для идентификации бага в базе данных (как и его ID), а также в различного вида отчетах и рапортах о проделанной работе. Более подробное описание и указания, как воспроизвести проблему описываются в других графах отчета. Краткая формулировка очень важна, т.к. по ней могут судить о важности проблемы. Кроме того, даже в случае схожих проблем, для которых составляются отдельные отчеты - Description должен быть разный.

В бумажной версии - заполняется соответствующий пункт отчета.

В электронной - представляет собой текстовое поле для ввода информации.

Вносится - тестировщиком.

Модифицируется - как правило после сохранения сообщения в базе данных - не модифицируется.

Детальное описание (Report).

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

В бумажной версии - заполняется соответствующий пункт отчета.

В электронной - представляет собой текстовое поле для ввода информации.

Вносится - тестировщиком.

Модифицируется - как правило после сохранения сообщения в базе данных - не модифицируется.

Шаги воспроизведения (Step to recreate).

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

В бумажной версии - заполняется соответствующий пункт отчета.

В электронной - представляет собой текстовое поле для ввода информации.

Вносится - тестировщиком.

Модифицируется - тестировщиком. Для дальнейших записей может использоваться поле Комментарий (см. ниже).

Обходной путь (Workaround).

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

Более подробно о Workaround можно почитать на сайте в разделе Школа. Классификация багов.

В бумажной версии - заполняется соответствующий пункт отчета.

В электронной - представляет собой текстовое поле для ввода информации.

Вносится - тестировщиком.

Модифицируется - тестировщиком. Для дальнейших записей может использоваться поле Комментарий (см. ниже).

Конфигурация (Configuration).

В данной графе описывается в какой аппаратной и/или программной конфигурации обнаружена описываемая проблема. В качестве вводимых данных могут использоваться как заранее "зарезервированные" названия конфигураций, так и их подробное описание. Глубина описания может варьироваться в зависимости от нужд или быть строго стандартизированной. Знание конфигурации может существенно облегчить локализацию бага или быть решающим моментом для воспроизведения отчета как программистом так и тестировщиком, особенно для тех отчетов, тип которых определен как "Взаимодействие с аппаратурой" (см).

В бумажной версии - заполняется соответствующий пункт отчета.

В электронной - представляет собой текстовое поле для ввода информации или список с заранее введенными значениями.

Вносится - тестировщиком.

Модифицируется - тестировщиком. Для дальнейших записей может использоваться поле Комментарий (см. ниже).

Аттачмент (приложения) (Attachment).

В данной графе указываются все материалы, приложенные к рапорту. Цель этих материалов - облегчить понимание, локализацию и исправление найденной ошибки. К таким материалам можно отнести логи, снимки с экрана и т.п. При описании материалов указывается их название, содержание и комментарии, а так же путь к ним (или метод получения). В ряде систем трекинга предусмотрено автоматическое копирование приложений в единый каталог доступный для использования другими членами команды или для закачки их по FTP.

В бумажной версии - заполняется соответствующий пункт отчета.

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

Вносится и модифицируется - как правило тестировщиком.

Поручено (Delegated).

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

В бумажной версии - заполняется соответствующий пункт отчета.

В электронной - список с заранее введенными значениями.

Вносится и модифицируется - как правило уполномоченным лицом (например руководителем проекта или менеджером).

Комментарии (Comments).

Это поле служит для внесения комментариев от различных членов команды на протяжении всего жизненного цикла бага. Здесь могут описываться дополнительные данные не вошедшие в основные графы отчета, вопросы, уточнения и т.д. В некоторых системах трекига, кроме Комментариев может использоваться дополнительное поле То-do, которое представляет собой список того, что необходимо сделать при работе с данным багом и может служить своеобразным планировщиком работ для любого члена команды, имеющего доступ к системе трекинга.

В бумажной версии - заполняется соответствующий пункт отчета.

В электронной - представляет собой текстовое поле для ввода информации с возможностью автоматического внесения даты, времени и ФИО лица, вносящего комментарий.

Вносится и модифицируется - всеми членами команды имеющими доступ к системе трекинга...

Резолюция (Resolution).

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

В бумажной версии - заполняется соответствующий пункт отчета.

Вносится и модифицируется - членами команды участвующими в исправлении (принятии решения о дальнейшей судьбе рапорта)...

Отложено (Deffered).

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

В бумажной версии - заполняется соответствующий пункт отчета.

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

Вносится и модифицируется - уполномоченным лицом (руководителем проекта или менеджером).

Подпись (нотификация для электронного варианта) (Signature/Notify).

В бумажной версии - подпись лица составившего отчет.

Представляет собой запись об отправке нотификации (уведомления) с указанием времени, даты и ФИО получателя.

В бумажной версии - графа, заполняемая составителем отчета.

В электронной - поле с описанной информацией.

Вносится и модифицируется в бумажном варианте - составителем отчета, а в электронном - системой трекинга (автоматически).

История (History).

Полная история всех изменений начиная с момента внесения отчета в базу данных. Включает в себя время и дату модификации, ФИО (ник, логин) лица изменившего любой пункт отчета и вид изменений.

В бумажной версии - отсутствует.

В электронной - поле с описанной информацией.

Вносится и модифицируется в электронном варианте - системой трекинга (автоматически).

Кроме используемого в данной статье синонимов понятия "баг" существует еще один - Issue (проблема). Этот термин можно рассматривать и как синоним понятия баг, и как более широкое понятие, обозначающее не только понятие "проблема", но и предложение по улучшению - "Feature request". О другом синониме Feature request уже было упомянуто выше - Enhancement (улучшение). Многие современные системы трекинга используют именно эти понятия и могут быть использованы как для трекинга багов, так и для отслеживания требований по улучшению программы. На мой взгляд, практика разделения сообщений на эти две группы существенно облегчает работу с системой.

Поля и правила составления Feature request практически не отличаются от таковых для bug report. Некоторые из описанных выше полей могут не использоваться при составлении Feature request (например, Повторяемость, Обходной путь и т.д.).

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

См. также:
Гущин Павел. Состояния багов.
Михаил Портнов. Классификация багов.
К вопросу о ведении базы.
FAQ. Что такое баг? Синонимы понятия...
Трекинг. Часть II. Критерии хорошего отчета.