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

Таким тестом мы проверяем, что флоу, в которое включен отремонти-

рованный компонент, все еще работает.

Изменить резолюцию на Fix is Verified можно непосредственно

после успешного завершения части 1.

При значении Fix is Verified можно закрыть баг. После закрытия

бага у него нет держателя, так как его некуда больше передавать.

После того как резолюция стала Fix is Verified и до закрытия бага

держателем бага является товарищ, который выбрал эту резолюцию.

Verification Failed (ремонт был неуспешен)

Если первая часть регрессивного тестирования показала неус-

пешность ремонта, т.е. баг все еще существует в коде, то мы не

делаем второй части, а просто выбираем это значение резолюции,

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

починил код.

Can Ч Reproduce (не могу воспроизвести)

Эта неприятная для тестировщика резолюция выбирается про-

граммистом после того, как перед починкой кода он пытается

воспроизвести проблему и не может сделать этого. Как правило,

Can 7 Reproduce имеет место в следующих случаях:

• "Описание и шаги..." содержат неполную, неверную или

нечеткую информацию о том, как воспроизвести баг, и/или

• бага нет, т.е. тестировщик принял за баг правильно рабо-

тающий код.

Одной из основных вещей в отношении багов в ПО является идея

об их воспроизводимости, т.е. если баг существует, его можно

воспроизвести. Бывает так, что тестировщик, найдя баг в ПО,

сразу же открывает СТБ, заносит новый баг и, довольный собой,

продолжает работу. Программист же соответственно бросает ра-

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

удачных попыток посылает его обратно тестировщику с резолю-

цией Can't Reproduce. Особенно неприятна ситуация, когда опи-

сание бага содержит сложную и долгую процедуру, необходимую

для воспроизведения.

Лучшим средством превентирования подобных вещей является

правило: "Перед тем как занести новый баг, воспроизведи его

еще раз", т.е., после того как найден баг, необходимо воспроиз-

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

239

вести его повторно. Это, казалось бы, простое правило поможет и

тестировщику, и программисту быть немного счастливее, а наше

счастье — это счастье пользователей.

Бывают такие случаи, когда очень сложно выявить условия, ко-

торые привели к появлению бага.

Кстати, проведем границу между условиями возникновения бага и

причинами возникновения бага.

Условие появления бага — это непосредственная ситуация, воспроиз-

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

добавить кредитную карту с датой истечения действия в прошлом.

Причина появления бага — это конкретная ошибка программиста или

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

ошибка в логике кода).

Идем дальше.

Например, мы увидели баг и не можем воспроизвести его, совер-

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

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

мы оставляем наши попытки, так как, если баг существует, его

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

тот же баг и снова не можем его воспроизвести.

Что я могу сказать? Именно такие ситуации бросают вызов на-

шему профессионализму. Если баг появился один раз и мы никак

не смогли воспроизвести его, то после его второго появления мы

ОБЯЗАНЫ найти условия, в результате которых он появляется.

Такие условия есть всегда, как порой ни сложно найти их.

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

В одной фармацевтической лаборатории работали четыре сотрудника.

Один из них, сотрудник N., изобрел уникальное вещество, которое

должно было послужить основой нового лекарства. N. составил под-

робный рецепт, но никто из его коллег не смог изготовить то же веще-