tестирование dot com
Шрифт:
ходил из одной лаборатории в другую по морозной улице.
240
Тестирование Дот Ком. Часть 3
Так как он был заядлым курильщиком, то перед выходом на улицу, что-
бы освободить руки для зажигалки и сигареты, он клал пробирку
с веществом "ближе к сердцу" — во
и, таким образом, жидкость в пробирке не охлаждалась, как это было
с коллегами N., которые не курили и переносили пробирки в руках.
Мораль сей истории такова: порой мельчайший нюанс может иметь
радикальное влияние на конечный результат.
Кстати,
условием (а вернее, одним из необходимых условий) для воспроизве-
дения вещества было недопущение охлаждения жидкости в пробирке.
Причиной же появления того или иного итогового вещества были хи-
мические процессы.
Итак, стремитесь к тому, чтобы программисты никогда не воз-
вращали вам баги с резолюцией Can't reproduce.
Держатель — тот, кто занес баг в СТБ.
Duplicate (дубликат)
Эта резолюция выбирается после того, как повторный баг был
занесен СТБ для той же проблемы.
Даже в стартапах в СТБ заносятся сотни и тысячи новых багов, и
порой физически нет возможности просмотреть каждый из них,
так чтобы постоянно быть в курсе дел и не занести баг — дубли-
кат уже существующего. На помощь может прийти модификация
ваших персональных настроек СТБ, где можно предусмотреть,
что вы будете извещаться е-мейлом о всех багах, имеющих опре-
деленные значения определенных атрибутов (например, слово
"корзина" в кратком описании).
Такая резолюция позволяет закрыть баг.
Держатель — тот, кто занес баг в СТБ.
Not a bug (не баг)
Это значение резолюции присваивается, как правило, программи-
стом, когда возникает ситуация "it's not a bug, it's a feature " ("это
не баг, а фича"), т.е. тестировщик принял за баг то, что, по мне-
нию программиста, работает правильно.
Когда возникают подобные ситуации? Например, когда тести-
ровщик создал тест-кейсы, руководствуясь
мист создал код, руководствуясь чем-то иным.
Жизнь замечательных багов
241
Почему возникает "руководствуясь чем-то иным"? Из-за плохих
спеков, когда программист фактически делает работу продюсера,
придумывая то, как должны работать функциональности, либо же
из-за того, что программист решает просто "забить", скажем, на
часть спека и сделать по-своему.
Бывает также, что либо тестировщик, либо программист, либо оба
из них неправильно поняли спек.
Бывает также, что программист просто "пропустил" часть спека
и не написал для этой части код.
Причин множество.
Как правило, после того как программист возвращает мне баг с
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 имя продюсера и пишу в комментариях, чтобы тот