tестирование dot com
Шрифт:
ведя которую мы воспроизводим баг. Например, пользователь может
добавить кредитную карту с датой истечения действия в прошлом.
Причина появления бага — это конкретная ошибка программиста или
продюсера, результатом которой является баг (например, сделана
ошибка в логике кода).
Идем дальше.
Например, мы увидели баг и не можем воспроизвести
шая, казалось бы, те же самые действия, которые привели нас к
багу в самом начале. После того как баг не был воспроизведен,
мы оставляем наши попытки, так как, если баг существует, его
можно воспроизвести, продолжаем работу, а затем снова видим
тот же баг и снова не можем его воспроизвести.
Что я могу сказать? Именно такие ситуации бросают вызов на-
шему профессионализму. Если баг появился один раз и мы никак
не смогли воспроизвести его, то после его второго появления мы
ОБЯЗАНЫ найти условия, в результате которых он появляется.
Такие условия есть всегда, как порой ни сложно найти их.
бог вам история, рассказанная моим приятелем
В одной фармацевтической лаборатории работали четыре сотрудника.
Один из них, сотрудник N., изобрел уникальное вещество, которое
должно было послужить основой нового лекарства. N. составил под-
робный рецепт, но никто из его коллег не смог изготовить то же веще-
ство, хотя они в точности выполняли все шаги. Дошло даже до того, что
троица, стоя по бокам от Л/., повторяла все его действия, и все-таки
вещество получалось только у него одного. В итоге четыре человека с
университетским образованием собрались на совещание и решили,
что они поверят в мистическое происхождение вещества, но после од-
ного последнего теста: АБСОЛЮТНО все действия N. в процессе изго-
товления вещества должны были быть засняты на видеокамеру и тща-
тельно проанализированы.
После съемки, тщательного анализа и последующих тестов разгадка
была найдена: в процессе изготовления вещества сотрудник N. пере-
ходил из одной лаборатории в другую по морозной улице.
240
Тестирование Дот Ком. Часть 3
Так как он был заядлым курильщиком, то перед выходом на улицу, что-
бы освободить руки для зажигалки и сигареты, он клал пробирку
с веществом "ближе к сердцу" — во внутренний карман пиджака,
и, таким образом, жидкость в пробирке не охлаждалась, как это было
с коллегами N., которые не курили и переносили пробирки в руках.
Мораль сей истории такова: порой мельчайший нюанс может иметь
радикальное влияние на конечный результат.
Кстати,
условием (а вернее, одним из необходимых условий) для воспроизве-
дения вещества было недопущение охлаждения жидкости в пробирке.
Причиной же появления того или иного итогового вещества были хи-
мические процессы.
Итак, стремитесь к тому, чтобы программисты никогда не воз-
вращали вам баги с резолюцией Can't reproduce.
Держатель — тот, кто занес баг в СТБ.
Duplicate (дубликат)
Эта резолюция выбирается после того, как повторный баг был
занесен СТБ для той же проблемы.
Даже в стартапах в СТБ заносятся сотни и тысячи новых багов, и
порой физически нет возможности просмотреть каждый из них,
так чтобы постоянно быть в курсе дел и не занести баг — дубли-
кат уже существующего. На помощь может прийти модификация
ваших персональных настроек СТБ, где можно предусмотреть,
что вы будете извещаться е-мейлом о всех багах, имеющих опре-
деленные значения определенных атрибутов (например, слово
"корзина" в кратком описании).
Такая резолюция позволяет закрыть баг.
Держатель — тот, кто занес баг в СТБ.
Not a bug (не баг)
Это значение резолюции присваивается, как правило, программи-
стом, когда возникает ситуация "it's not a bug, it's a feature " ("это
не баг, а фича"), т.е. тестировщик принял за баг то, что, по мне-
нию программиста, работает правильно.
Когда возникают подобные ситуации? Например, когда тести-
ровщик создал тест-кейсы, руководствуясь спеком, а програм-
мист создал код, руководствуясь чем-то иным.
Жизнь замечательных багов
241
Почему возникает "руководствуясь чем-то иным"? Из-за плохих
спеков, когда программист фактически делает работу продюсера,
придумывая то, как должны работать функциональности, либо же