testirovanie_dot-com

означает "Пользуйтесь на свой страх и риск. Код свежий. Вполне возможны баги ". Так как данная ситуация не укладывается в идею бета-релиза, то мы назовем такой релиз псевдобета-релизом.

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

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

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

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

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

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

Альфа-тестированием называется любое тестирование кода ДО передачи его пользователям (включая бета-пользователей).

Юнит-тестирование, о котором мы уже говорили, является видом альфа-тестирования. Продюсер может попросить у программиста покопаться на плэйграунде последнего, когда код уже работает, и проверить, как были воплощены в жизнь его (продюсера) мечты из спека, и это тоже будет альфа-тестирование.

Родственное в альфа- и бета-тестировании — это то, что цель каждого из них — поиск багов.

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

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

подчеркнем, что тестировщики интернет-компаний находятся в привилегированном положении по сравнению с их коллегами из всех других сфер бизнеса. В случае пропуска серьезного бага на машину для пользователей этот баг можно устранить в течение получаса, иногда дажес минимальной стоимостью и без ведома большинствапользователей отом, чтобаг вообщекогда-тосуществовал.

А что, если баг обнаружен в подвеске автомобиля? Из-за отзыва целого модельного ряда (нормальная деловая практика западных автокомпаний) и негативной рекламы бренда убытки будут просто неизбежны!

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

•Релиз проводится в то время, когда большинство пользователей неактивны. Как правило, это ночь. Время подберете сами исходя из того, в каком часовом поясе находится большинство ваших пользователей.

•Во время релиза на www.testshop.rs вывешивается табличка, что, мол, "Производим техническую поддержку, не отчаивайтесь, примерно в 6.00 по Москве все вернется на круги своя. Просим извинить за временные неудобства".

Пример

Пользователь, первый раз сделавший покупку на www.testshop.rs, проснулсяв часночи ихочетпроверитьстатуссвоего заказа. Оннабирает в браузере www.testshop.rs и видит "404 file not found". Конечно, он проведет остаток ночи в терзаниях, а потом эмоционально расскажет всем своим друзьям (и правильно сделает), какие редиски работают в www.testshop.rs, что вот полночи не спал из-за того, что мысленно прощался с честно заработанными 300 рублей.

Обратная же ситуация будет, когда опять же в час ночи пользователь увидит на www.testshop.rs сообщение, подробно объясняющее обычную для on-line-бизнеса ситуацию, завершающееся вежливым "Извините".

В бизнесе любой интернет-компании наступают сезонные всплески активности пользователей, например, в США это канун католического Рождества и Нового года. В такие периоды на все релизы, кроме патч-релизов, фиксирующих серьезные баги, должен быть введен мораторий. Логика тут проста: любой релиз — это риск. И мы не хотим идти на этот риск в то время, как

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

•наш бизнес делает наибольшие деньги.

Как и было обещано, переходим к следующей стадии, а перед переходом запомним, что часто наряду со словом "релиз" или вместо него употребляется равнозначное push — "толчок".

Большая картина цикла разработки ПО

Пример

Допустим, у нас есть

•мама (продюсер),

•сын 7 лет (программист, тестировщик, релиз-инженер и

служба поддержки),

•папа (пользователь) и

•неограниченное количество разнообразных деталей конструктора для строительства игрушечного дома.

Мама говорит сыну: "Давай сделаем папе приятное и построим для него одноэтажный дом (идея), который должен выглядеть вот так и вот так

(дизайн продукта)".

Сын собирает отдельно

крышу, стены, двери и

окна (кодирование).

Потом происходит соединение всех частей (интеграция), в результате которой крыша оказалась меньше, чем нужно, выпуклости дверей не совпадают с выпуклостями стен, а окна не подходят по цвету. Сын переделывает компоненты, успешно соединяет и начинает пинать домик ногами, бросать вниз с семнадцатого этажа и оставлять на ночь в наполненной ванной (тестирование). В результате обнаруживаются некоторые недоработки (баги), которые постепенно устраняются (фиксирование багов). Когда все нормально, домик передается папе (релиз), который иногда просит (е-мейл/звонок в службу поддержки пользователей), чтобы некоторые проблемы, такие, как неровности крыши, с которой падает кружка с пивом (пострелиз-баги), были немедленно исправлены (фиксирование пострелиз-багов).

Вернемся к нашему www.testshop.rs.

Давайте рассмотрим большую картину цикла разработки ПО в

динамике.

Сначала обобщим знания об игроках, их ролях и стадиях цикла с их участием.

1.Итак, начнем с бара, вернее, с идеи версии 1.0, которая в этом баре пришла.

2.После того как идея v. 1.0 была принята за путеводную звезду дляпервогорелиза, наступила стадиядизайн и документация v. 1.0 этой идеи. Основное действующее лицо— продюсер.

Ав это время

• маркетолог тоже не сидит без дела, а генерирует идеи для следующего релиза на стадии идея v. 2.O.

3.После того как дизайн и документация v. 1.0 завершены, наступает стадия кодирование v. 1.0. Основное действующее лицо — программист.

Ав это время

•тестировщик планирует, как он будет тестировать код, разрабатываемый сейчас программистом;

•продюсер работает уже над стадией дизайн и документация v. 2.0, переданной после стадии идея v. 2.0;

•маркетолог работает над стадией идея v. 3.0.

Итак, большая картина цикла разработки ПО.

Большая картина — это всего лишь модель, и в реальной жизни все так гладко, красиво и гармонично не бывает. На-

пример, во время стадии идея v. 2.0 маркетолог может генерировать как краткосрочные идеи цикла v. 2.0, так и долгосрочные цикла v. 4.0 и v. 5.0.

В завершение беседы о цикле разработки ПО давайте •

поставим акцент на паре важных моментов,

•сделаем одну оговорку,

•остановимся на одной ценной мысли и

•ответим на практические вопросы.

Пара важных моментов:

1.Процедуры, стандарты, спеки, тест-кейсы и контактная информация должны быть задокументированы (пусть даже

вэлектронном виде) и доступны на интранете.

2.Такие вещи, как утверждение спека, рассмотрение тесткейсов или инспекция кода, — это не какие-то полицейские мероприятия, призванные подрезать крылышки творческим и свободным личностям. Совершенно наоборот — это средства, позволяющие

•улучшить качество,

•прикрыть спину,

•стать хорошим людям еще лучше.

Оговорка:

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

•веб-дизайнеры;

•системные администраторы и администраторы баз данных;

•народ из службы поддержки и маркетинга;

•бухгалтеры (хлещущие чай);

•спецы по железу (хлещущие пиво) и др.

Мы их всех любим, ценим и, как видите, не забываем. Просто нужно было сделать допустимое упрощение для удобства восприятия нового материала и, например, свести написание кода только к программистам, в то время как JavaScript-кол обычно пишется веб-дизайнерами.

Ценная мысль:

Акт планирования, будь то спек, дизайн кода, тест-кейс или документ о неотложном ремонте бага, — это возможность посмотреть в будущее, предугадать и предотвратить возможные проблемы и/или баги.

Эффективное планирование — это одна из важнейших составляющих процесса разработки ПО.

Вопросы и задания для самопроверки

1.Перечислите стадии цикла разработки ПО.

2.Какой баг дороже: пойманный не во время написания спека или во время тестирования?

3.Перечислите болезни спеков.

4.Почему продюсер не должен давать в спеке технических инструкций?

5.Для чего нужно утверждение спека?

6.Для чего нужно замораживание спека?

7.Почему спеки нужно хранить в CVS?

8.Перечислите и прокомментируйтепричины появления багов кода.

9.Что такое юнит-тест?

10.Что такое инспекция кода и как она помогает вывестина чистую воду подлецов, которые считают, что чем запутаннее код, тем лучше?

11.Для чего нужно замораживание кода?

12.Каковы преимущества постоянной интеграции кода?

13.Какие баги ловятся компайлером (интерпретатором)?

14.Какие баги НЕ ловятся компайлером (интерпретатором)?

15.Почему файлы с тест-комплектами нужно хранить в CVS?

16.Почему рассмотрение тест-кейсов выгодно не только компании, но и самому тестировщику?

17.Что такое тест приемки?

18.Что случается, если тест приемки не пройден?

19.В чем отличия тестирования новых функциональностей от регрессивного тестирования?

20.У нас после каждого релиза появляются тест-кейсы, которые мы должны исполнять в последующих релизах для регрессивного тестирования. Соответственно наступает момент, когда столько тест-кейсов для регрессивного тестирования, что нет никакой возможности их исполнить в пределах временных рамок без ущерба для исполнения тест-кейсов для новых функциональностей. Что делать? (Ответ будет в одном из следующих разговоров.)

21.Придумайте аналогию из жизни, чтобы проиллюстрировать слово "релиз".

22.Перечислите виды релизов.

23.Может ли быть в основном релизе код с зафиксированными багами предыдущего релиза?

24.Если ответ на предыдущий вопрос положительный, то почему мы не выпустили патч-релиз, а ждали следующего релиза?

25.Что означает номер релиза 11.44?

26.Обоснуйте необходимость CVS для процесса разработки ПО и релиза.

27.Что такое бранч CVS и для чего он нужен?

28.Назовите состояния бранча и условия для этих состояний.

29.Чтотакоепроцедураонеотложномремонтебаговизачемонанужна?

30.Почему для бета-тестирования набирают народ из типичных пользователей?