Дефект.

9 сентября 1945 года в Гарварде был построен электронный калькулятор MarkII. Между неизолированными проводами попалась моль,что привело к останову машины. Это был первый случай попадания насекомого в плату. Ученые записали в это своем отчете. Отсюда и пошло использование слова ‘bug’в смысле ‘компьютерная/программная’ ошибка.

Дефект (баг) - от англ. defect (bug)

• Несоответствие продукции установленным требованиям.

• Причина, приведшая к отказу при устройстве, агрегата.

Документирование и жизненный цикл дефекта

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

Общий вид записи дефекта:

Name<Title> - название ошибки;

Pre-Conditions – предусловия, т.е. условия в которых она происходит;

Steps – шаги необходимые для полного воспроизведения ошибки;

Attachments – дополнительные файлы (скриншоты, сервер логи и т.д.).

При занесении нового дефекта в багтрегинговую систему так же указываутся, следующая информация:

1. Наименование подсистемы, функционала, в которой обнаружен дефект (пример: Поиск, Регистрация, ГУИ (GUI – graphical user interface).

2. Версия продукта (номер build ), на котором дефект был найден.

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

4. Описание дефекта (Name<Title>, Steps, Attachments).

5. Описание процедуры (шагов, необходимых для воспроизведения дефекта – steps to reproduce).

6. Уровень дефекта, то есть степень его серьезности с точки зрения критериев качества продукта или заказчика.

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

NTBF (not to be fixed)

Deferred (to future releases)

Open.

В случае признания дефекта достаточно важным для текущего состояния приложения, он переводится в статус Open. Далее, руководитель группы разработчиков прикрепляет его к определенному разработчику (переводит его в статус – Assigned, это значит, что над дефектом ведется работа определенным разработчиком). После исправления дефект переводится разработчиком в состояние "Resolved или Fixed”. При этом разработчик должен указать следующую информацию:

1. Причину возникновения дефекта.

2. Место исправления, как минимум, с точностью до исправленного файла.

3. Краткое описание того, что было исправлено.

После этого тестировщик проверяет, действительно ли дефект был исправлен и если это так, переводит его в состояние "Verified". Если тестировщик не подтвердит факт исправления дефекта, то состояние дефекта изменяется снова на "Open".

Конечно, возможен более упрощенный цикл:

New -> Fixed -> Closed (или Reopen).

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

Тогда в бой вступает здравый смысл и опыт тестировщика. Например, по умолчанию понятно, что кнопка «Сортировать по возрастанию» должна данный список отсортировать по возрастанию (если это цифры) или по алфавиту (если это слова). А что если список содержит как слова, так и цифры? А только ли русские слова? И т.д. Такие моменты необходимо согласовывать с заказчиком, для чего заводится дефект-вопрос, назовем его: CN – clarification needed.

Если же требования не удовлетворяют некоторым из перечисленных выше свойств, то это (не всегда, конечно) можно исправить, указав на это аналитику либо непосредственно заказчику. Такого типа дефекты будем называть DD – documentation defect. Например: В требованиях на одной странице кнопка имеет название Search, а на другой Searching. Для приведения в соответствие, заводится DD.

Бывает такое, что в процессе разработки приложения, заказчику приходит в голову ввести новый функционал, либо в корне поменять старый, либо же расширить его. В общем случае, это не было предусмотрено ни требованиями, ни архитектурой, ни планом разработки приложения. В таких случаях заводятся дефекты типа CR – change request. Например: Необходимо добавить возможность экспорта списка доступных товаров в файл *.xls.

Итак, пример дефекта для веб-приложения «Электронный магазин»:

Summary: Покупатель может положить в корзину товаров на сумму бОльшую, чем есть в его кошельке.

Functionality: Система покупателя

Build: 1.0.301

Environment: Windows XP SP2, IE 7.0

Description: Покупатель может положить в корзину товаров на сумму бОльшую, чем есть в его кошельке. Согласно спецификации, при попытке совершить такое действие, покупателю должно быть выведено сообщение «Вы превышаете лимит покупок. Пополните пожалуйста свой кошелек».

Steps to Reproduce:

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

2. Войдите в «Магазин». Выделите товары на сумму, превышающаю сумму денег в кошельке у покупателя. Нажмите на кнопку «Купить».

Результат: Покупателю предлагается оплатить все выбранные товары. Блокирующее сообщение не выводится

Priority: Major.