tестирование dot com
Шрифт:
сообщат в нашу компанию. Наша интернет-компания отремонти-
рует эти баги и выпустит официальный релиз, более качествен-
ный, чем бета. Примером, когда было использовано бета-тести-
рование (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-бизнеса ситуацию, завершающееся вежливым "Извините".
В бизнесе любой интернет-компании наступают сезонные вспле-
ски активности пользователей, например, в США это канун като-
лического Рождества и Нового года. В такие периоды на все ре-
лизы, кроме патч-релизов, фиксирующих серьезные баги, должен
быть введен мораторий. Логика тут проста: любой релиз — это
риск. И мы не хотим идти на этот риск в то время, как
• огромное количество пользователей нуждаются в беспере-
бойной работе нашего веб-сайта и