ется на v. 2.0, начав подготовку к тестированию кода, раз-

рабатываемого сейчас программистом на стадии кодиро-

вание v. 2.0.

А в это время

• программист пишет код на стадии кодирование v. 2.0;

• продюсер разрабатывает дизайн продукта на стадии ди-

зайн и документация v. 3.0;

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

идеи на стадии идея v. 4.O.

Таким образом, мы рассмотрели полностью цикл разработки

версии 1.0 проекта www.testshop.rs. Дальше все идет по ана-

логии.

126

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

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

Большая картина — это всего лишь модель, и в реальной

жизни все так гладко, красиво и гармонично не бывает. На-

пример, во время стадии идея v. 2.0 маркетолог может генери-

ровать как краткосрочные идеи цикла v. 2.0, так и долгосрочные

цикла v. 4.0 и v. 5.0.

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

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

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

127

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

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

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

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

1. Процедуры, стандарты, спеки, тест-кейсы и контактная

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

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

2. Такие вещи, как утверждение спека, рассмотрение тест-

кейсов или инспекция кода, — это не какие-то полицей-

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

ческим и свободным личностям. Совершенно наоборот —

это средства, позволяющие

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

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

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

Оговорка:

В аквариумах интернет-компаний кроме продюсеров, програм-

мистов, тестировщиков и начальников обитает еще много других

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

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

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

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

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

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

Мы их всех любим, ценим и, как видите, не забываем. Просто

нужно было сделать допустимое упрощение для удобства вос-

приятия нового материала и, например, свести написание кода

только к программистам, в то время как JavaScript-кол обычно

пишется веб-дизайнерами.

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

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

кумент о неотложном ремонте бага, — это возможность посмот-

реть в будущее, предугадать и предотвратить возможные про-

блемы и/или баги.

Эффективное планирование — это одна из важнейших со-

ставляющих процесса разработки ПО.

128

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

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

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

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

во время тестирования?

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

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

рукций?

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

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

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

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

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

10. Что такое инспекция кода и как она помогает вывести на чистую воду