из-за того, что программист решает просто "забить", скажем, на

часть спека и сделать по-своему.

Бывает также, что либо тестировщик, либо программист, либо оба

из них неправильно поняли спек.

Бывает также, что программист просто "пропустил" часть спека

и не написал для этой части код.

Причин множество.

Как правило, после того как программист возвращает мне баг с

Not a bug, я читаю его комментарии и принимаю решение о за-

крытии бага или возврате его программисту (меняю резолюцию

на Assigned и меняю мое имя в Assigned to на имя программиста)

с моими комментариями.

Кстати, в зависимости от СТБ и ее настроек значения атрибутов могут быть

а) взаимозависимыми или

б) нет.

Примеры

а) значение атрибута Assigned to меняется автоматически в зависи

мости от резолюции:

если программист выбрал Not a bug, значение Assigned to само ме-

няется на имя лица, занесшего баг в СТБ;

б) значение атрибута Assigned to статично:

после того как программист выбрал резолюцию Not a Bug, он дол-

жен самостоятельно изменить значение Assigned to на имя лица,

занесшего баг в СТБ.

Обратно к Not a bug.

Если нужно, я уточняю у самого программиста дополнительные

детали, и если мы не приходим к консенсусу о том, закрывать баг

либо начать ремонт, то я меняю Not a bug на Assigned, выбираю в

Assigned to имя продюсера и пишу в комментариях, чтобы тот

принял решение, что с этим багом делать.

Важный момент: если проблема была в спеке, то продюсер ста-

новится держателем бага (после того как я изменю Not a bug на

Assigned и выберу имя продюсера в Assigned to), и он должен из-

менить резолюцию на Verify после того, как спек будет изменен.

Я поменяю резолюцию на Fix is Verified, если своими глазами

242

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

увижу, что спек на самом деле был изменен, изменение было

правильным и спек находится в том месте интранета компании,

где он должен находиться.

Кстати, в некоторых компаниях качество работы тестировщика оцени-

вается (конечно, наряду с прочими факторами) по тому, сколько багов

было закрыто с резолюцией Not a bug от общего количества найден-

ных им багов в том смысле, что, чем больше нот-э-багов, тем хуже по-

работал тестировщик.

В случае если баг, возвращенный с Not a bug, на самом деле не баг,

то держателем становится автор бага и баг может быть закрыт.

3rd party bug (не наш баг)

Во всех интернет-компаниях уже используют ПО, написанное дру-

гими софтверным компаниями, например интерпретатор для лю-

бимого мною языка Python. Допустим, что я нахожу баг и заношу

его в СТБ. Программист начинает поиск причины бага и видит,

что его код работает чики-пики и корень зла находится в "не на-

шем" ПО, которое каким-либо образом связано с нашим кодом.

Что делает программист? Правильно — возвращает мне баг с ре-

золюцией 3rd party bug.

Что может быть дальше?

Вариант 1: мы не можем повлиять на производителей "не нашего'"