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

Савин Роман

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

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

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

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

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

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

• навсегда

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

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

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

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

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

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

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

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

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

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

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

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

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

компании.

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

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

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

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

95

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

дел по горло.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

96

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

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

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

меньше будут получать втыков от жен — любительниц Louis

Vuitton и тем больше будут радеть за свое место и качество кода,

включая разработку дополнительных (от себя) юнит-тестов.

В общем нужно сделать так, чтобы профессионал не думал о

том, как свести концы с концами, а работал, зная, что его

труд будет достойно оценен, и видел, что компания заботится

о нем.

9. НАЛИЧИЕ ПОНЯТИЙ "КАЧЕСТВО" И "СЧАСТЬЕ

ПОЛЬЗОВАТЕЛЯ" КАК ОСНОВНЫХ СОСТАВЛЯЮЩИХ

КОРПОРАТИВНОЙ ФИЛОСОФИИ

Менеджмент должен сделать так, чтобы персонал понимал, что

"качество" и "счастье пользователя" — это не фикция, а путь к

финансовому успеху компании и соответственно лучшей жизни

каждого, кто работает над проектом. Если менеджеры по-

смеиваются над мерами по улучшению качества и отпускают