tестирование dot com

может вернуть вам баг с резолюцией Not a Bug (если это был не

баг, а недопонимание того, как работает не наше ПО) либо же

вернуть вам баг (путем Assigned to) с той же резолюцией — 3rd

party bug, и вы в обоих случаях спокойно его закроете.

Жизнь замечательных багов

245

Важно: в обоих случаях (когда мы не можем/можем повлиять на

производителя не нашего ПО) наш программист может ошибочно

допустить, что проблема в не нашем ПО, хотя на самом деле это

наш баг. В этом случае тестировщик делает:

Resolution — Assigned

Assigned to — имя программиста.

No longer applicable (поезд ушел)

Такое значение резолюции присваивается багу, который раньше

действительно был багом, но теперь по какой-то причине тако-

вым не является.

Например

мы исполняем тест-кейс по проверке одного из флоу функционально-

сти "Оплата" и видим, что отсутствует поле для ввода номера CW2. Мы

заносим баг и получаем его обратно с резолюцией No Longer Applicable

и комментарием программиста, что согласно багу #7723 с типом "Fea-

ture Request" мы больше не должны спрашивать CW2 у пользователя.

Таким образом, до занесения продюсером бага #7723 ситуация с от-

сутствующим CW2 была бы багом, а теперь это не баг.

Баги, возвращенные с резолюцией No longer applicable, как пра-

вило, возникают из-за отсутствия информации.

В моей практике, если фактический результат после исполнения

тест-кейса расходится с ожидаемым результатом по этому тест-кей-

су, я пытаюсь воспроизвести баг заново, и если он воспроизводится,

то я сразу же заношу его в СТБ. Если же я вижу проблему, которая

не связана с моим ожидаемым результатом и/или функциональ-

ностью, о которой я имею полную информацию, то обычно контак-

тирую с коллегами-тестировщиками, которые владеют вопросом

о функциональности, в которой, как мне кажется, есть баг.

Резолюция No longer applicable позволяет закрыть баг, если он на

самом деле больше не баг.

Процесс трэкинга багов

Теперь, после того как мы поговорили об атрибутах СТБ, посмот-

рим на блок-схему. На ней мы воочию видим основу процесса

трэкинга багов. Эта основа сама по себе является стандартной

версией процесса, и интернет-компании используют ее в таком

либо измененном виде.

246

Тестирование Дот Ком. Часть 3

Процесс трэкинга багов

Жизнь замечательных багов

247

Кстати, для упрощения допустим, что баг заносится тестиров-

щиком (хотя мы знаем, что баг может заноситься кем угодно)

и против кода программиста (хотя мы знаем, что существуют

и баги спека, которые заносятся против продюсера).

Давайте сделаем так:

• сначала рассмотрим процесс концептуально, затем

• привяжем к каждой его стадии наши атрибуты (детальное

рассмотрение процесса), затем

• приведем конкретный пример.

Концептуальное рассмотрение процесса трэкинга багов

Задача 1: После того как мы нашли проблему в ПО, заносим новый

баг.

Задача 2: Программист получает баг, старается понять, в чем про-

блема, и если это действительно баг, то

Задача 3: Программист начинает ремонт.

Задача 4: После того как ремонт закончен, программист

должен сделать checkin кода в CVS.

Задача 5: Релиз-инженер запускает новый билд, чтобы от-

ремонтированный код пришел из CVS на тест-ма-

шину.

Задача 6: Тестировщик проводит регрессивное тестирова-

ние, и если починка НЕ удалась, то

Задача 7: Баг возвращается программисту на но-

вый ремонт.

Если же починка удалась, то

Задача 8: Баг закрывается. Goodbye my love, Goodbye.

Идем обратно к развилке после задачи 2. Допустим, программист

не считает, что зарапортованная ситуация является багом. Тогда он:

Задача 9: Возвращает баг.

Задача 10: Тестировщик старается понять свою ошибку, и

если ошибка имела место и баг соответственно

места не имел, то

Задача 8: Баг закрывается.

Если же тестировщик считает, что это все-таки баг, то

баг отправляется обратно программисту.

Задача 2: Программист снова пытается понять, баг ли это. И т.д.

248

Тестирование Дот Ком. Часть 3

Детальное рассмотрение процесса