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

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" —

запрос о новой функциональности (подробнее об этом в разговоре

о СТБ), и релиз такого кода регулируется этой же процедурой.

Примером, в котором нужен быстрый, не связанный с багами

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

(например, о нарушении патента), которое обязывает срочно из-

менить код.

Релиз такого кода также называется патч-релизом.

Вопрос: В чем отличие такого патч-релиза от дополнительного

релиза?