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

рии (target group), для удовлетворения потребностей которой и

был затеян весь сыр-бор от идеи до поддержки. Бета-тестиров-

щики служат подопытными кроликами, ценность которых заклю-

чается в том, что они, являясь типичными пользователями, будут

делать с бета-версией веб-сайта те же вещи, что и остальные

пользователи после официального релиза, и, следовательно, зара-

нее столкнутся с непойманными (нами) багами, о которых они и

сообщат в нашу компанию. Наша интернет-компания отремонти-

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

ный, чем бета. Примером, когда было использовано бета-тести-

рование (beta testing), может послужить сервис Gmail компании

Google (кстати, основанной москвичом Сергеем Брином).

В некоторых случаях компания не организует бета-тестирова-

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

релиз и помещает картинку или текст со словом "Beta", что

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

121

означает "Пользуйтесь на свой страх и риск. Код свежий. Вполне

возможны баги ". Так как данная ситуация не укладывается в идею

бета-релиза, то мы назовем такой релиз псевдобета-релизом.

Истинные и псевдобета-релизы, как правило, имеют место в двух

случаях:

1. Первый релиз в жизни интернет-компании, например ре-

лиз версии 1.0 сайта www.testshop.rs.

2. Релиз большого и важного подпроекта, являющегося ча-

стью основного проекта, например сервис Gmail, являю-

щийся частью проекта Google.

Логичным будет вопрос: "Если есть бета-тестирование, должно

быть и альфа-тестирование?" Ответ: "Правильно".

Рассказываю:

Альфа-тестированием называется любое тестирование кода ДО

передачи его пользователям (включая бета-пользователей).

Юнит-тестирование, о котором мы уже говорили, является видом

альфа-тестирования. Продюсер может попросить у программиста

покопаться на плэйграунде последнего, когда код уже работает, и

проверить, как были воплощены в жизнь его (продюсера) мечты

из спека, и это тоже будет альфа-тестирование.

Родственное в альфа- и бета-тестировании — это то, что цель

каждого из них — поиск багов.

Чуждое в альфа- и бета-тестировании — это то, что в подавляю-

щем большинстве случаев альфа-тестирование исполняется внут-

ренними ресурсами компании, а бета-тестирование — внешними.

В продолжение завершения разговора о релизе

подчеркнем, что тестировщики интернет-компаний находятся в

привилегированном положении по сравнению с их коллегами из

всех других сфер бизнеса. В случае пропуска серьезного бага на

машину для пользователей этот баг можно устранить в течение

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

шинства пользователей о том, что баг вообще когда-то существовал.

А что, если баг обнаружен в подвеске автомобиля? Из-за отзыва

целого модельного ряда (нормальная деловая практика западных

автокомпаний) и негативной рекламы бренда убытки будут про-

сто неизбежны!

122

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

В завершение завершения разговора о релизе:

• Релиз проводится в то время, когда большинство пользова-

телей неактивны. Как правило, это ночь. Время подберете

сами исходя из того, в каком часовом поясе находится

большинство ваших пользователей.

• Во время релиза на www.testshop.rs вывешивается таблич-

ка, что, мол, "Производим техническую поддержку, не от-

чаивайтесь, примерно в 6.00 по Москве все вернется на

круги своя. Просим извинить за временные неудобства".

Пример

Пользователь, первый раз сделавший покупку на www.testshop.rs, про-

снулся в час ночи и хочет проверить статус своего заказа. Он набирает

в браузере www.testshop.rs и видит "404 file not found". Конечно, он

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

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

www.testshop.rs, что вот полночи не спал из-за того, что мысленно

прощался с честно заработанными 300 рублей.

Обратная же ситуация будет, когда опять же в час ночи пользователь

увидит на www.testshop.rs сообщение, подробно объясняющее обычную

для on-line-бизнеса ситуацию, завершающееся вежливым "Извините".

В бизнесе любой интернет-компании наступают сезонные вспле-

ски активности пользователей, например, в США это канун като-

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

лизы, кроме патч-релизов, фиксирующих серьезные баги, должен

быть введен мораторий. Логика тут проста: любой релиз — это

риск. И мы не хотим идти на этот риск в то время, как

• огромное количество пользователей нуждаются в беспере-

бойной работе нашего веб-сайта и