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

и билд-скриптом) после запуска на тест-машину билда с отре-

монтированным кодом, т.е. Build in Progress приходит на смену

Fixed.

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

237

Здесь нужно заметить, что если даже баг найден на машине для

пользователей, патч-релиз происходит только после того, как ре-

монт протестирован на тест-машине.

Держатель бага — релиз-инженер.

Verify (проведи регрессивное тестирование)

Это значение резолюции выбирается релиз-инженером (а иногда

и билд-скриптом) после того, как билд на тест-машину завершен.

Держатель бага — лицо, чье имя указано в Verifier. Если у вери-

фаера нет возможности проверить ремонт, то он может просто

выбрать другое значение Verifier так, чтобы его коллега принял

груз ответственности.

Fix is Verified (ремонт был успешен)

Регрессивное тестирования бага состоит из двух частей, следую-

щих одна за другой в таком порядке:

Часть 1:

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

четко следуем инструкциям из "Описания и шагов..." для вос-

произведения бага. Если функциональность работает как сле-

дует, то баг действительно был починен.

Часть 2:

проверка того, что ремонт бага не наплодил других багов.

Код — это тонкая материя, состоящая из множества взаимо-

зависимых компонентов, и чем сложнее ПО, тем труднее пред-

угадать, как изменение кода в одном месте отразится на рабо-

те всех закоулков системы. Если программист не указывает в

комментариях, какая часть ПО может быть попутно затронута

ремонтом, я в зависимости от ситуации

• прохожу по приоритетному флоу функциональности,

код которой был отремонтирован, и/или

• делаю энд-ту-энд-тест.

Пример с энд-ту-энд-тестом

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

не мог изменить количество книг. Энд-ту-энд-тест, который бы я сделал:

а) добавить в корзину книгу,

б) изменить количество книг и

в) произвести оплату.

238

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

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

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

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

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

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

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

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

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

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

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

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

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

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

починил код.

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

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

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

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

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

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

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

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

тающий код.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

239

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

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

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

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

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

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

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

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