tестирование dot com полностью

3. На странице register, htm пользователь вводит имя, е-мейл и прочие

данные и отправляет форму, нажав кнопку "Зарегистрироваться".

88

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

4. Через веб-сервер эта форма, т.е. запрос о регистрации, поступает

на сервер с приложением, которое

• обрабатывает этот запрос;

• запрашивает базу данных, есть ли уже эккаунт с таким е-мейлом;

• обрабатывает ответ от базы данных;

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

нии записи для нового пользователя;

• формирует ответ для пользователя;

• в виде веб-страницы с подтверждением регистрации или веб-стра-

ницы с ошибкой посылает пользователю ответ через веб-сервер.

Так вот, программисты разрабатывают код вышеупомянутого

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

тировщикам, в злорадном предвкушении потирающим ручонки и

знающим, что причинами возникновения багов в коде явля-

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

нету, так и другие объективные вещи:

а. Некачественные и/или изменяющиеся спецификации

Об этом мы уже говорили.

б. Личностные качества программиста

Такие, как халатность, невнимательность и лень.

в. Отсутствие опыта

Программист может просто не знать, как нужно сделать пра-

вильно.

г. Пренебрежение стандартами кодирования

О стандартах чуть позже.

д. Сложность системы

Современные интернет-проекты отличаются такой сложностью,

что мозг простого смертного порой просто не в состоянии про-

анализировать все последствия создания/изменения/удаления

кода и предугадать появление проблемы.

е. Баги в ПО третьих лиц, т.е. баги

• в операционных системах;

• в компайлерах (compiler — ПО для переведения (напри-

мер, C++) кода в машинный язык и создания исполняе-

мых файлов);

• в веб-серверах;

• в базах данных и др.

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

89

ж. Отсутствие юнит-тестирования,

х.е. тестирования кода самим программистом: "И вообще, почему

я должен искать баги в своем коде, когда есть тестировщики?"

(Поговорим о юнит-тестировании через минуту.)

з. Нереально короткие сроки для разработки

Об этом мы тоже скоро поговорим.

Возможности оздоровления кода и превентирования багов до

передачи кода тестировщикам (иллюстрации последуют не-

медленно) включают:

1. Наличие требований к содержанию спеков и следова-

ние правилам их изменения;

2. Возможность прямой, быстрой и эффективной комму-

никации между программистами и программистами и

продюсерами;

3. Инспекции кода;

4. Стандарты программирования;

5. Реальные сроки;

6. Доступность документации;

7. Требования к проведению юнит-тестирования (о кото-

ром мы поговорим уже через 30 секунд);

8. Реальные финансовые рычаги стимуляции написания

эффективного и "чистого" кода;

9. Наличие понятий "качество" и "счастье пользователя"

как основных составляющих корпоративной философии.

Подробности.

1. НАЛИЧИЕ ТРЕБОВАНИЙ К СОДЕРЖАНИЮ СПЕКОВ

И СЛЕДОВАНИЕ ПРАВИЛАМ ИХ ИЗМЕНЕНИЯ

О спеках мы уже говорили.

2. ВОЗМОЖНОСТЬ ПРЯМОЙ, БЫСТРОЙ И ЭФФЕКТИВНОЙ

КОММУНИКАЦИИ МЕЖДУ ПРОГРАММИСТАМИ

И ПРОГРАММИСТАМИ И ПРОДЮСЕРАМИ

Здесь есть следующие аспекты:

а. Психологические аспекты

Очень важно привить в культуру компании следующее правило:

"Если к тебе обратились — помоги".

90

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

Пример