118
Тестирование Дот Ком. Часть 1
жен написать номер реального бага в комментарии при со-
хранении файла; 3) закрытый. В этом случае файл может
быть сохранен в соответствии с процедурой о неотложном
ремонте багов (о процедуре через минуту).
Кстати, когда мы говорили о замораживании спеков, используя CVS,
нужно понимать, что бранчи, в которых сохраняются спеки, не имеют
никакой связи с бранчами, в которых сохраняется код. Как правило, это
даже две CVS, установленные на двух разных машинах, но если даже
используется одна и та же CVS на одной и той же машине, то бранчи
для спеков и бранчи для кода — это как два сына одной женщины
(т.е. CVS), один из которых мочит одноклассников в сортирах, а другой
в это время читает Артура Шопенгауэра.
Кстати, часто возникает ситуация, когда программист сохранил код в
бранче для патч-релиза и забыл сохранить исправленный код в стволе,
т.е. в коде, из которого будет сделан бранч для следующего релиза.
Таким образом, может получиться ситуация, когда баг, патч для кото-
рого уже был выпущен на машину для пользователей в предыдущем
релизе, вновь появляется в следующем релизе. Чтобы избежать таких
казусов, тестировщики придерживаются железного правила: на каж-
дый баг, для которого был произведен патч-релиз, должен быть
написан тест-кейс приоритета 1. Этот тест-кейс добавляется к группе
тест-кейсов для регрессивного тестирования соответствующей функ-
циональности.
Совместим наш цикл разработки ПО с открытостью бранчей.
1. Во время стадии кодирование, например, для версии 3.0
бранч с версией 3.0 является открытым.
2. Во время стадии тестирование и ремонт багов бранч явля-
ется условно закрытым — никакой код не может сохра-
няться в таком бранче, за исключением кода с починкой
для конкретного бага, при сохранении кода в CVS програм-
мист обязан указать номер открытого бага в СТБ, иначе CVS
не разрешит checkin. Именно такой статус у бранча после
заморозки кода и передачи кода тестировщикам.
3. После того как произошел релиз на машину для пользова-
телей и в этом релизе найден баг, у нас есть два варианта:
а) если баг некритический (например, отсутствует проверка
е-мейла пользователя на два "@"), то его можно отре
монтировать в следующем релизе, т.е. мы фиксируем код
только в стволе;
б) если баг критический (например, невозможно совершить
покупку), то нужно отремонтировать его и выпустить патч-
Цикл разработки ПО
119
релиз как можно быстрее. Для такого срочного ремонта
нужен формальный документ: процедура о неотложном
ремонте багов (Emergency Bug Fix Procedure).
Кстати, не хочу вас путать, но есть одна важная для понимания вещь:
иногда нужно незамедлительно изменить код приложения на машине
для пользователей, и это изменение не связано с багами. В таком
случае тоже заносится запись в СТБ, но с типом "Feature Request" —
запрос о новой функциональности (подробнее об этом в разговоре
о СТБ), и релиз такого кода регулируется этой же процедурой.
Примером, в котором нужен быстрый, не связанный с багами
релиз, может послужить ситуация, когда у нас есть решение суда
(например, о нарушении патента), которое обязывает срочно из-
менить код.
Релиз такого кода также называется патч-релизом.
Вопрос: В чем отличие такого патч-релиза от дополнительного
релиза?
