Введение.
Мы не будем останавливаться на том, насколько важно «найти и обезвредить» ошибки в разрабатываемом программном обеспечении, исходя из того, что, если Вы посетили наш сайт, то уже самостоятельно пришли к пониманию этого или же выбрали довольно непростую профессию тестера. Поэтому начнем с самого главного.
Определение.
Что такое баг (bug)? Ответить на этот вопрос одновременно и легко и сложно. Прежде всего под багом понимают ошибку в программе, проявляющуюся при ее использовании. Багом можно назвать так же и недокументированные или нежелательные, «побочные» реакции программы на те или иные действия пользователя равно как и при использовании ее одновременно с другим ПО или в другой аппаратной конфигурации.
Существуют и другие определения багов. Например в своей книге «Тестирование программного обеспечения» Сэм Канер с соавторами приводят определения Myers и Beizer: «Если программа не делает того, чего пользователь от нее вполне обосновано ожидает, значит налицо программная ошибка (Майерс (Myers, 1976, c.6)).
Не существует ни абсолютного определения ошибок, ни точного критерия наличия их в программе. Можно лишь сказать, насколько программа не справляется со своей задачей, — это исключительно субъективная характеристика (Бейзер (Beizer, 1984, с.12)).»
Они же (Канер с соавторами) указывают, что определение ошибок как расхождения между программой и ее спецификацией — не верно. Так как даже точно соответствующая спецификации программа содержит ошибки в том случае, если есть ошибки и в самой спецификации.
Роберт Калбертсон с соавторами в своей книге «Быстрое тестирование» приводит такое определение программным ошибкам: «Говоря простыми словами, программная ошибка — не что иное, как изъян в разработке программного продукта, который вызывает несоответствие ожидаемых результатов выполнения программного продукта и фактически полученных результатов. Дефект может возникнуть на стадии кодирования, на стадии формулирования требований или на стадии проектирования, либо же его причина может крыться в некорректной конфигурации или данных. Дефектом может быть также что-то другое, что не соответствует ожиданиям заказчика и что может быть, а может и не быть определено в спецификации программного продукта.»
Как видим, в литературе можно встретить целый ряд синонимов этого понятия. Помимо бага довольно часто встречаются такие термины как ошибка (error), проблема (problem), деффект (defect), неисправность (fault) и конечно же «жаргонный» глюк. Но какой бы термин мы не использовали суть его остается не изменной.
Не следует путать баги (ошибки, дефекты и т.п.) с т.н. фичами (feature). Мы склонны объединять под этим понятием прежде всего те черты и свойства программы, которых она не имеет, но на наш взгляд очень ей не помешали бы. Безусловно, фичи — сугубо субъективны. Как правило, в четко организованном и спланированном проекте их встречаться не должно, так как вся функциональность программы должна быть оговорена еще до начала разработки (см. жизненный цикл ПО). Особенно это касается тех проектов, которые делаются под определенного заказчика. Именно он (заказчик) и определяет в конечном итоге какими чертами/свойствами/функциями должна обладать программа.
Как правило, большинство систем отслеживания проблем (систем трекинга багов — bug tracking system) имеют возможность составлять не только отчеты о багах (Bug Report), но и вносить Feature Request (запрос свойства), что позволяет тестировщикам вносить свои предложения по улучшению тестируемой программы.
Классификация.
Классификаций программных ошибок существует много. Прежде всего, на мой взгляд, это связано с тем, что в основе этих классификаций лежат различные критерии. Часть классификаций носит больше теоретический характер, часть — будет полезна с практической точки зрения. К сожалению, охватить все возможные классификации — задача довольно сложная, да и вряд ли целесообразная. Попробую остановится на некоторых, наиболее важных из них.
По точке их приложения баги можно разделить на:
- Ошибки пользовательского интерфейса.
- Ошибки функциональности.
- Ошибки логики программирования.
- Ошибки инсталляции.
- Ошибки использования памяти, системных ресурсов и т.д.
Сэм Канер с соавторами в своей книге «Тестирование программного обеспечения» приводит гораздо более полную классификацию ошибок по этому признаку (с.453).
На наш взгляд более практичной является классификация, используемая в ряде программ-коллекторов (или как их принято называть — системах отслеживания проблем (системах трекинга багов), например, BugCollector Pro от Nesbitt Software Corporation и ряде других — см. раздел Софт).
К сожалению, далеко не все системы трекинга используют одну и туже классификацию. Более того, благодаря гибкости настроек большинства из них можно с легкостью менять используемые понятия на те, которые Вам более привычны или приняты в Вашей компании.
В целом ниже приведенная классификация носит чисто практический характер, является моей интерпретацией и далека от совершенства, но, тем не менее, она позволяет обеспечить достаточную преемственность между разработчиком и тестером:
Causes crash — название говорит само за себя. Под ним объединяют все те ошибки в программе, которые могут вызвать крах или зависание всей системы, нарушить стабильность ее работы.
Cosmetic — под этим понятием объединяют ошибки дизайна (например, не тот цвет линии или шрифт), пользовательского интерфейса и т.п. Иными словами все те баги, которые не мешают работать программе, но портят ее «товарный вид».
Critical — все то, что ведет к зависанию или краху самой программы, не затрагивая операционной системы в целом.
Error Handling — баги в обработке ошибок.
Functional — баги в функциональности.
Setup — баги инсталляции.
Minor — теоретически малозначимые, либо баги не уточненнного генеза.
Suggestion — т.н. предложение. На наш взгляд к ним лучше всего относить feature.
Описание бага.
Для описания багов служат специальные утилиты, так как описывать их в текстовых редакторах — занятие не только утомительное, но и бесполезное. Примером таких утилит может служить BugCollector Pro (Nesbitt Software Corporation). Мы предлагаем учитывать следующее:
Регистрационная информация:
Описание (краткое описание бага, касающееся его сути). Желательно, чтобы описание было коротким (несколько слов), уникальным, отражающим суть.
Идентификационный номер (уникальный для каждого бага).
Приоритет (позволяющий разработчику оценить очередность исправления данной ошибки).
Классификационную принадлежность (см. классификация багов).
Версию программы и ее сборку (build), в которой этот баг обнаружен.
Имя и дату тестера сообщившего об ошибке.
Кроме того может вводится дополнительная информация о статусе бага, отражающая на какой стадии находится работа над ним (например, новый (new), в процессе (in process), исправленный (fixed), проверенный (verified) т.д.); информацию о дате исправления и имени разработчика, исправившего баг; информацию о проверке, ее дате и имени тестера, проверившего это.
Рапорт (Report) — подразумевает более подробное сообщение о том, в чем именно заключается ошибка.
Шаги воспроизведения (Steps to recreate) — подробное пошаговое описание действий тестера, которые приводят к появлению описываемой ошибки.
Обходной путь (Workaround) — описание пути обхода ошибки, если таковой имеется.
Конфигурация (Сonfiguration) — описание аппаратной и софтверной конфигурации, а также конфигурационных установок в самом тестируемом ПО.
Мы привели лишь наиболее важную на наш взгляд информацию, которая должна сопутствовать каждому описанному багу. Безусловно, все эти параметры могут широко варьироваться в зависимости от вида ПО, целей разработки и тестирования, а также многих других факторов.