tестирование dot com
Шрифт:
пользователем, то к стоимости, вычисляемой по формуле предыдущего
случая, могут прибавиться десятки других убытков (включая упущенную
выгоду), например:
• время службы поддержки;
• компенсации пользователю потерянных денег;
• иски против компании;
• навсегда
шими пользователями и пользователями, которые по рекомендации
ушедших никогда не заглянут на ваш веб-сайт,
а также множество других плохих и неприятных вещей.
Наиболее важное в концепции стоимости бага — это то, что чем раньше
будет найден баг, тем он будет дешевле для компании.
Таким образом, баг (а это, как мы знаем, может быть и отклонение от
здравого смысла), найденный на уровне идеи, — это самый дешевый
баг, соответственно баг, найденный после релиза, — это самый
дорогой баг. Причем убытки от последнего, как правило, не поддаются
объективной оценке.
Как видим, QA и тестирование — это не только обеспечение счастья
пользователей, но и путь САМОСОХРАНЕНИЯ любой интернет-
компании.
Вернемся к юнит-тестированию. Вот две рекомендации:
1. Юнит-тесты должны планироваться в письменной фор-
ме ДО написания кода.
Цикл разработки ПО
95
В таком случае программист после получения спека не бежит
сломя голову писать код, а садится за документацию о дизайне
кода с параллельным созданием юнит-тестов.
Полезность такого подхода заключается в том, что,
во-первых, программист абстрагируется от непосредственного
кодирования и, видя "большую картину", может предугадать прин-
ципиальные ошибки в алгоритмах и,
во-вторых, он сможет заранее представить, КАК он будет тести-
ровать код, это "КАК" занозой засядет у него в голове и при на-
писании кода
чит вооружен".
2. Требования к юнит-тестам должны быть формализованы
в стандартах о юнит-тестировании.
Например, каждая функция должна иметь по крайней мере один
тест-кейс с одним конкретным вводом и одним конкретным вы-
водом (ожидаемым результатом).
Принципиально, думаю, понятно. А так как написание и испол-
нение юнит-тестов — это дело программистов, то мы закончим
рассуждения о нем и пойдем дальше, у нас, тестировщиков, своих
дел по горло.
8. РЕАЛЬНЫЕ ФИНАНСОВЫЕ РЫЧАГИ
СТИМУЛЯЦИИ НАПИСАНИЯ ЭФФЕКТИВНОГО И
"ЧИСТОГО" КОДА
Здесь все элементарно — менеджмент не должен жмотиться, если
люди горбатятся на проект день и ночь, а в итоге не узнают своих
подросших детей и называют своих жен Ленами (по имени колле-
ги, сидящей за соседним компьютером и ставшей почти родной).
• Хорошая заработная плата с возможностью увеличения;
• билеты в "Ленком";
• премии за хорошую работу;
• неограниченные чипсы и диет-кола;
• оплата абонемента в бассейн и гимнастический зал;
• месячные проездные;
• выезды для игры в пейнтбол;
• беспроцентный кредит на машину;
• помощь при первоначальном взносе на квартиру —
96
Тестирование Дот Ком. Часть 1
чем больше заботы проявит компания о сотрудниках (и не только
программистах), тем добросовестнее они будут работать, тем
меньше будут получать втыков от жен — любительниц Louis
Vuitton и тем больше будут радеть за свое место и качество кода,
включая разработку дополнительных (от себя) юнит-тестов.
В общем нужно сделать так, чтобы профессионал не думал о
том, как свести концы с концами, а работал, зная, что его
труд будет достойно оценен, и видел, что компания заботится
о нем.
9. НАЛИЧИЕ ПОНЯТИЙ "КАЧЕСТВО" И "СЧАСТЬЕ
ПОЛЬЗОВАТЕЛЯ" КАК ОСНОВНЫХ СОСТАВЛЯЮЩИХ
КОРПОРАТИВНОЙ ФИЛОСОФИИ
Менеджмент должен сделать так, чтобы персонал понимал, что
"качество" и "счастье пользователя" — это не фикция, а путь к
финансовому успеху компании и соответственно лучшей жизни
каждого, кто работает над проектом. Если менеджеры по-
смеиваются над мерами по улучшению качества и отпускают