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

написан тест-кейс приоритета 1. Этот тест-кейс добавляется к группе

тест-кейсов для регрессивного тестирования соответствующей функ-

циональности.

Совместим наш цикл разработки ПО с открытостью бранчей.

1. Во время стадии кодирование, например, для версии 3.0

бранч с версией 3.0 является открытым.

2. Во время стадии тестирование и ремонт багов бранч явля-

ется условно закрытым — никакой код не может сохра-

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

для конкретного бага, при сохранении кода в CVS програм-

мист обязан указать номер открытого бага в СТБ, иначе CVS

не разрешит checkin. Именно такой статус у бранча после

заморозки кода и передачи кода тестировщикам.

3. После того как произошел релиз на машину для пользова-

телей и в этом релизе найден баг, у нас есть два варианта:

а) если баг некритический (например, отсутствует проверка

е-мейла пользователя на два "@"), то его можно отре

монтировать в следующем релизе, т.е. мы фиксируем код

только в стволе;

б) если баг критический (например, невозможно совершить

покупку), то нужно отремонтировать его и выпустить патч-

Цикл разработки ПО

119

релиз как можно быстрее. Для такого срочного ремонта

нужен формальный документ: процедура о неотложном

ремонте багов (Emergency Bug Fix Procedure).

Кстати, не хочу вас путать, но есть одна важная для понимания вещь:

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

для пользователей, и это изменение не связано с багами. В таком

случае тоже заносится запись в СТБ, но с типом "Feature Request" —

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

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

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

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

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

менить код.

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

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

релиза?

Ответ: В том, что дополнительный релиз — это плановый релиз,

когда было заранее решено, что такие-то функциональности уви-

дят свет, но включены они будут не в основной, а в дополнитель-

ный релиз.

Процедура о неотложном ремонте багов должна содержать:

• приоритет багов, которые подлежат НРБ. Например, это

могут быть только П1 баги;

• список лиц, имеющих право инициировать процесс НРБ;

• последовательность действий между лицами, участвую-

щими в НРБ, например:

1) программист, извещенный о проблеме, фиксирует баг;

2) исправление кода заверяется одним из его коллег через

рассмотрение кода (code review);

3) релиз-инженер делает билд для регрессивного тести-

рования;

4) тестировщик производит тестирование;

5) релиз-инженер делает патч-релиз на машину для поль-

зователей;

• коммуникацию между лицами, участвующими в НРБ. На

пример, в начале и конце каждого из этапов ответственное

лицо отвечает всем на последний е-мейл этой цепочки.

Причем в начале этапа посылается е-мейл типа "Начал де

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

120

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

срок до завершения операции — 30 минут". В конце этапа

посылается е-мейл типа "Билд для регрессивного тестиро-

вания завершен. Тестировщики. Ау!".

Во многих компаниях для быстрого и эффективного исправления

проблем после основного релиза по примеру полицейских созда-

ются SWAT-команды (Special Weapons and Tactics teams — под-

разделения оперативного реагирования), по минимуму состоящие

из продюсера, программиста, релиз-инженера и тестировщика.

Допустим, у нас есть четыре такие команды. Для каждой их

них устанавливается расписание на каждый день (по шесть

часов каждая) на 10 дней после релиза, так чтобы по звонку в

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

разделения были готовы сорваться, приехать в офис и сидеть до

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

зователей.

В начале завершения разговора о релизах поговорим о бета-

тестировании.

Иногда интернет-компании производят бета-релиз (читается как

"бэта") (beta release). Идея бета-релиза заключается в следую-

щем: перед тем как мы сделаем основной "официальный" релиз,

т.е. откроем новый код всем пользователям, мы откроем новый

код лишь ограниченной группе пользователей, которые нам его и

протестируют. Эти пользователи (или "бета-тестировщики" —

beta testers) должны являться представителями целевой аудито-