ции кода с целью улучшения перформанса (скорости работы сайта).
Обратно к 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 в ствол. Следовательно,
в следующем релизе баг появляется снова.
В связи со статусом запомним две вещи:
• ВСЕ найденные баги должны заноситься в СТБ. Исклю-
чений быть не может. Ваша работа как тестировщика —
искать баги. Единственный и неповторимый результат вашей
работы — баг, занесенный в СТБ. Умные программисты ни-
когда на вас не обидятся, так как качество их работы измеря-
ется не количеством багов, ими допущенных, а скоростью,
с которой они эти баги чинят (почти по Глебу Жеглову);
• занесенные в СТБ баги НИКОГДА не удаляются из СТБ.
Чтобы ни случилось, пока живет компания, ее СТБ вклю-
чает ВСЕ баги, найденные в продукте. Администратор СТБ
