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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

компании.

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

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

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

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

95

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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