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

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

77

3. После утверждения — Утверждено (Approved или Final).

Если на митинге все закричали "Ура!" или получены по-

ложительные отзывы от всех реципиентов, утвержденный

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

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

компании, которому положено его видеть. Если же спек не

принят, то все начинается с пункта 1.

Постановка мозгов

Факт утверждения спека не означает, что тестировщик и программист

объявили спек идеальным. Факт утверждения спека означает, что в

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

был признан годным для дальнейшей работы. Политический момент:

спек — это ответственность продюсера, и продюсер остается ответ-

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

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

проблемы.

Идем дальше.

Спасский после игры с Фишером неделями ходит и думает: "А вот

здесь нужно было бы его конем пришкварить", но, к сожалению,

исправить ему уже ничего нельзя, "можно только забыть".

Продюсер же может проснуться утром с идеей улучшения спека

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

дании спека, и, придя на работу, подредактировать спек и заме-

нить файл со старой редакцией файлом с новой редакцией на

упомянутом внутреннем сервере... И так пять раз.

Далее.

Обычно спек распечатывается непосредственно перед началом

работы по нему. Учитывая, что время начала работы по спеку у

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

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

ция, когда

программисты и тестировщики хотя и работают над одним

проектом, но руководствуются разными редакциями спека.

Причем даже если у программистов и тестировщиков будут рас-

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

ния их работа в той или иной части все равно не будет иметь

смысла, так как они руководствовались устаревшей редакцией.

78

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

Пример

11 ноября. Спек утвержден Ножовым, Ложкиным и Тарелкиным. Про-

дюсер Буханкин.

12 ноября. Спек распечатывает тестировщик Ножов. Работа по спеку

началась.

14 ноября. У Буханкина новая идея. Спек по-тихому изменен.

15 ноября. Спек распечатывает для себя программист Ложкин. Работа

по спеку началась.

16 ноября. У Буханкина новая идея. Спек по-тихому изменен.

17 ноября. Спек распечатывает для себя программистТарелкин. Работа

по спеку началась.

18 ноября. У Буханкина новая идея. Спек по-тихому изменен.

19 ноября. Спек распечатывает для себя программист Салфетка, рабо-

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

и своего спека. Работа по спеку началась.

25 декабря. Все выясняется. 30

декабря.

17:00 — начало празднования Нового года в офисе компании.

17:30 — начало избиения Буханкина руками Ножова, Ложкина и Та-

релкина.

18:00 — начало избиения Буханкина ногами Ножова, Ложкина и Та-

релкина.

18:30 — в офис влетает Салфетка, вернувшийся после разговора с

менеджером, разбрасывает в стороны подуставших Ножова,

Ложкина и Тарелкина и добивает Буханкина контрольным

ударом клавой по голове.

Надо отметить, что во многих случаях спек меняется не по воле

продюсера, а по приказу сверху.

Ситуация

25 марта.

Менеджер присылает продюсеру е-мейл, что необходимо срочно

изменить спек #8337.

За день до этого, т.е. 24 марта.

Представьте себя на месте продюсера:

продюсер уже вовсю работает над новым спеком и надеется, что

релиз функциональностей согласно спеку #8337 пройдет без сучка

без задоринки.

Представьте себя на месте программиста: код для спека

#8337 написан, влегкую протестирован самим программистом,

частично позабыт и уже кажется частью безвозвратно потерянной

юности.

Представьте себя на месте тестировщика:

документация для тестирования спека #8337 написана. Новые проекты