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

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

редачи кода пользователю. Расходы компании поддаются

приблизительной оценке;

• убытки, которые несет компания, потому что баг не был

найден до передачи кода пользователю. Объективная оценка

убытков в большинстве случаев невозможна.

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

Стоимость бага в первом случае:

Если баг был допущен на уровне спека и найден во время тестирования

кода, его стоимость вычисляется как

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

часов, потраченных на разработку "неправильной" части спека

(стоимость спека), плюс + стоимость программирования

"неправильной" части спека плюс + стоимость тестирования

"неправильной" части спека плюс + стоимость фиксирования бага и

проблем, из него вытекающих.

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

Стоимость бага во втором случае:

Если баг был допущен на уровне спека, но не придушен до релиза и найден

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

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

выгоду), например:

• время службы поддержки;

• компенсации пользователю потерянных денег;

• иски против компании;

• навсегда утраченная потенциальная оплата услуг компании ушед-

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

ушедших никогда не заглянут на ваш веб-сайт,

а также множество других плохих и неприятных вещей.

Наиболее важное в концепции стоимости бага — это то, что чем раньше

будет найден баг, тем он будет дешевле для компании.

Таким образом, баг (а это, как мы знаем, может быть и отклонение от

здравого смысла), найденный на уровне идеи, — это самый дешевый

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

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

объективной оценке.

Как видим, QA и тестирование — это не только обеспечение счастья

пользователей, но и путь САМОСОХРАНЕНИЯ любой интернет-

компании.

Вернемся к юнит-тестированию. Вот две рекомендации:

1. Юнит-тесты должны планироваться в письменной фор-

ме ДО написания кода.

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

95

В таком случае программист после получения спека не бежит

сломя голову писать код, а садится за документацию о дизайне

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

Полезность такого подхода заключается в том, что,

во-первых, программист абстрагируется от непосредственного

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

ципиальные ошибки в алгоритмах и,

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

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

писании кода будет работать по принципу "предупрежден — зна-

чит вооружен".

2. Требования к юнит-тестам должны быть формализованы

в стандартах о юнит-тестировании.

Например, каждая функция должна иметь по крайней мере один

тест-кейс с одним конкретным вводом и одним конкретным вы-

водом (ожидаемым результатом).

Принципиально, думаю, понятно. А так как написание и испол-

нение юнит-тестов — это дело программистов, то мы закончим

рассуждения о нем и пойдем дальше, у нас, тестировщиков, своих

дел по горло.

8. РЕАЛЬНЫЕ ФИНАНСОВЫЕ РЫЧАГИ

СТИМУЛЯЦИИ НАПИСАНИЯ ЭФФЕКТИВНОГО И

"ЧИСТОГО" КОДА

Здесь все элементарно — менеджмент не должен жмотиться, если

люди горбатятся на проект день и ночь, а в итоге не узнают своих

подросших детей и называют своих жен Ленами (по имени колле-

ги, сидящей за соседним компьютером и ставшей почти родной).

• Хорошая заработная плата с возможностью увеличения;

• билеты в "Ленком";

• премии за хорошую работу;

• неограниченные чипсы и диет-кола;

• оплата абонемента в бассейн и гимнастический зал;

• месячные проездные;

• выезды для игры в пейнтбол;

• беспроцентный кредит на машину;

• помощь при первоначальном взносе на квартиру —

96

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

чем больше заботы проявит компания о сотрудниках (и не только

программистах), тем добросовестнее они будут работать, тем