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

Савин Роман

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

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

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

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

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

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

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

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

Такие,

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

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

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

вильно.

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

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

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

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

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

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

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

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

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

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

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

мых файлов);

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

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

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

89

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ром мы поговорим

уже через 30 секунд);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

90

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

Пример

Программист приходит к продюсеру с просьбой объяснить некую часть

спека. Продюсер говорит, что он сейчас слишком занят. "Давай завтра,

добро?"

Очень часто после пары "давай завтра" программист что делает? Пра-

вильно! Он пишет код так, как его понимает, — без всякой гарантии, что

сей код отразит требуемое.

Следующий аспект:

программист (как и все остальные участники цикла) никогда не

должен стесняться спрашивать (хоть двести раз!) и подтверждать

свое понимание е-мейлами типа: "Просто хотел уточнить, что я

правильно понял, что пункт 12.2 такого-то спека говорит..." Если

же программисту не отвечают, когда он подходит, прекрасно —

нужно послать е-мейл и сохранить этот е-мейл, как и е-мейлы "Я

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

идти к своему менеджеру и просить его принять меры. И это не

стукачество, а деловая практика — business is business.

Следующий аспект:

Менеджмент должен регулярно устраивать так называемые Team

Building Activities (мероприятия по сплочению коллектива) с той

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

сиональных налаживались и человеческие контакты. Причем, как

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