Читаем tестирование dot com полностью

ции кода с целью улучшения перформанса (скорости работы сайта).

Обратно к Feature request.

Баг с типом Feature request заносится в СТБ с именем продюсера

или программиста в Assigned to, когда у вас родилась идея об

улучшении некой существующей фича или о новой фича.

Значение типа Feature request также используется в баге, служа-

щем основанием для патч-релиза, в случае, когда появилась не-

234

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

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

вателей и это изменение не связано с багом (как отклонением

фактического от ожидаемого).

Логичным будет вопрос: почему мы употребили выражение

"срочное изменение"?

Вот ответ: если нужна новая функциональность, то продюсер

пишет спек, программист его кодирует и т.д. в соответствии с про-

цессом разработки ПО. Каждая стадия процесса имеет свои вре-

менные рамки, которые привязаны к расписанию релизов (release

schedule). А что, если у нас появилась незапланированная потреб-

ность в новой фича и ее нужно срочно выпустить?

Пример

Допустим, мы выпускаем один основной релиз в месяц. Сегодня 10

ноября, и последний основной релиз (7.0) состоялся 31 октября.

Если сегодня (Ю ноября) появилась новая идея (например, о добавле-

нии кепча на страницу регистрации), то если мы включим ее в наш

процесс разработки как любую очередную идею, то наша многостра-

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

релизе 8.0 (так как все спеки релиза 8.0 уже заморожены), а 1 января

в релизе 9.0. Таким образом, придется ждать больше полутора меся-

цев. Что делать, если у нас нет полутора месяцев, а есть полтора часа ?

Нужно занести баг "Feature request" с приоритетом П1. Если же фича

может подождать до 8.0, то опять же заносим баг с типом "Feature re-

quest", но уже с приоритетом ПЗ.

Вот такие дела...

STATUS (СТАТУС)

Это ниспадающее меню со значениями:

• Open (Открыт),

• Closed (Закрыт),

• Re-Open (Повторно открыт).

Значение Open присваивается багу автоматически при занесении бага.

Закрыть баг можно только при соответствующей резолюции (об этом

через минуту).

Значение Re-Open выбирается тестировщиком, когда он возрож-

дает к жизни закрытый баг.

Почему возникают ситуации, когда баги приходится открывать

заново?

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

235

Например

• программист сделал изменение в коде и поломал отремонтиро-

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

чае говорят о том, что баг был reintroduced ("заново внесен на рас-

смотрение" — так себе перевод, но ничего лучше я не нашел);

• баг был найден на машине для пользователей. Программист сде-

лал checkin отремонтированного кода в бранч-версии машины для

пользователей и позабыл сделать checkin в ствол. Следовательно,

в следующем релизе баг появляется снова.

В связи со статусом запомним две вещи:

• ВСЕ найденные баги должны заноситься в СТБ. Исклю-

чений быть не может. Ваша работа как тестировщика —

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

работы — баг, занесенный в СТБ. Умные программисты ни-

когда на вас не обидятся, так как качество их работы измеря-

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

с которой они эти баги чинят (почти по Глебу Жеглову);

• занесенные в СТБ баги НИКОГДА не удаляются из СТБ.

Чтобы ни случилось, пока живет компания, ее СТБ вклю-

чает ВСЕ баги, найденные в продукте. Администратор СТБ