tестирование dot com
Шрифт:
а) если баг некритический (например, отсутствует проверка
е-мейла пользователя на два "@"), то его можно отре
монтировать в следующем релизе, т.е. мы фиксируем код
только в стволе;
б) если баг критический (например, невозможно совершить
покупку), то нужно отремонтировать его и выпустить патч-
Цикл разработки ПО
119
релиз как можно быстрее. Для такого срочного ремонта
нужен формальный документ: процедура о неотложном
ремонте
Кстати, не хочу вас путать, но есть одна важная для понимания вещь:
иногда нужно незамедлительно изменить код приложения на машине
для пользователей, и это изменение не связано с багами. В таком
случае тоже заносится запись в СТБ, но с типом "Feature Request" —
запрос о новой функциональности (подробнее об этом в разговоре
о СТБ), и релиз такого кода регулируется этой же процедурой.
Примером, в котором нужен быстрый, не связанный с багами
релиз, может послужить ситуация, когда у нас есть решение суда
(например, о нарушении патента), которое обязывает срочно из-
менить код.
Релиз такого кода также называется патч-релизом.
Вопрос: В чем отличие такого патч-релиза от дополнительного
релиза?
Ответ: В том, что дополнительный релиз — это плановый релиз,
когда было заранее решено, что такие-то функциональности уви-
дят свет, но включены они будут не в основной, а в дополнитель-
ный релиз.
Процедура о неотложном ремонте багов должна содержать:
• приоритет багов, которые подлежат НРБ. Например, это
могут быть только П1 баги;
• список лиц, имеющих право инициировать процесс НРБ;
• последовательность действий между лицами, участвую-
щими в НРБ, например:
1) программист, извещенный о проблеме, фиксирует баг;
2) исправление кода заверяется одним из его коллег через
рассмотрение кода (code review);
3) релиз-инженер делает билд для регрессивного тести-
рования;
4) тестировщик производит тестирование;
5) релиз-инженер делает патч-релиз на машину для поль-
зователей;
• коммуникацию между лицами, участвующими в НРБ. На
пример, в начале и конце каждого из этапов ответственное
лицо
Причем в начале этапа посылается е-мейл типа "Начал де
лать билд для регрессивного тестирования. Примерный
120
Тестирование Дот Ком. Часть 1
срок до завершения операции — 30 минут". В конце этапа
посылается е-мейл типа "Билд для регрессивного тестиро-
вания завершен. Тестировщики. Ау!".
Во многих компаниях для быстрого и эффективного исправления
проблем после основного релиза по примеру полицейских созда-
ются SWAT-команды (Special Weapons and Tactics teams — под-
разделения оперативного реагирования), по минимуму состоящие
из продюсера, программиста, релиз-инженера и тестировщика.
Допустим, у нас есть четыре такие команды. Для каждой их
них устанавливается расписание на каждый день (по шесть
часов каждая) на 10 дней после релиза, так чтобы по звонку в
любое время дня и ночи головорезы соответствующего под-
разделения были готовы сорваться, приехать в офис и сидеть до
посинения, пока патч-релиз не вылетит на машину для поль-
зователей.
В начале завершения разговора о релизах поговорим о бета-
тестировании.
Иногда интернет-компании производят бета-релиз (читается как
"бэта") (beta release). Идея бета-релиза заключается в следую-
щем: перед тем как мы сделаем основной "официальный" релиз,
т.е. откроем новый код всем пользователям, мы откроем новый
код лишь ограниченной группе пользователей, которые нам его и
протестируют. Эти пользователи (или "бета-тестировщики" —
beta testers) должны являться представителями целевой аудито-
рии (target group), для удовлетворения потребностей которой и
был затеян весь сыр-бор от идеи до поддержки. Бета-тестиров-
щики служат подопытными кроликами, ценность которых заклю-
чается в том, что они, являясь типичными пользователями, будут
делать с бета-версией веб-сайта те же вещи, что и остальные
пользователи после официального релиза, и, следовательно, зара-
нее столкнутся с непойманными (нами) багами, о которых они и