tестирование dot com
Шрифт:
CREDITCARD, в своем коде так и запишет: "CreditCard". В итоге код не
будет работать, так как C++, ничего не знающий ни о Лехе, ни о Сане, ни о
кредитных картах, думает о CREDITCARD и CreditCard как об
абсолютно разных классах.
Стандарты могут включать:
• правила о комментариях;
• правила об именах таблиц в базе данных, классов, функций
и различных
• правила о максимальной длине строки;
• прочее.
Документ со стандартами должен быть доступен на интранете.
Стандарты программирования — это неотъемлемая часть
процесса, когда в компании работают два программиста и боль-
ше. Они по определению должны быть обязательны для всех.
5. РЕАЛЬНЫЕ СРОКИ
В стартапе изначально и по определению сроки на разработку
нереальны, и приходится балансировать между
• "поспешишь — людей насмешишь" и
• необходимостью закончить кодирование в срок.
Цикл разработки ПО
93
Несмотря на то что стопроцентно действующих рецептов нет, вот
хорошая идея для облегчения нелегкой жизни программистов:
после ознакомления со спеками программисты должны предос-
тавить менеджменту примерные оценки (сметы) сроков для
разработки кода, и исходя из этих смет менеджмент может,
если нужно
• перераспределить нагрузку и
• посмотреть, имеет ли смысл убирать что-то из менее
приоритетных функционалъностей ради того, чтобы
чисто и тщательно написать остальной код.
Единственное утешение состоит в том, что, когда стартап как
бизнес становится более зрелым, сроки и рабочие часы стабили-
зируются во многом потому, что менеджмент понимает, что луч-
ше дать реальный срок (например, перенеся некоторые из спеков
в следующие релизы), чем поступиться качеством.
6. ДОСТУПНОСТЬ ДОКУМЕНТАЦИИ
ВСЕ документы, относящиеся к разработке ПО, включая спеки,
процедуру изменения спека, стандарты программирования, тест-
комплекты, и документы, о которых мы будем говорить в даль-
нейшем, должны быть доступны в локальной сети, и их располо-
жение должно быть максимально оптимизировано для удобства и
быстроты поиска. Все должно быть сделано для того, чтобы за-
интересованный сотрудник быстро нашел нужный документ, а не
тратил свое время и время своих коллег на долгие поиски.
Несмотря на кажущуюся очевидность и легковесность этого мо-
мента, несоблюдение
на практике может принести много проблем.
7. ТРЕБОВАНИЯ
К ПРОВЕДЕНИЮ ЮНИТ-ТЕСТИРОВАНИЯ
Юнит-тестирование (unit testing) — это тестирование, произ-
водимое самим программистом. Здесь нужно подчеркнуть, что
неправильный подход к введению юнит-тестирования вызо-
вет справедливое раздражение программистов, так как за тес-
тирование платят тестировщикам, а отсутствие требований к
юнит-тестированию вообще увеличит стоимость багов.
94
Тестирование Дот Ком. Часть 1
Постановка мозгов
Стоимость бага — это
• расходы компании, чтобы найти баг и исправить его до пе-
редачи кода пользователю. Расходы компании поддаются
приблизительной оценке;
• убытки, которые несет компания, потому что баг не был
найден до передачи кода пользователю. Объективная оценка
убытков в большинстве случаев невозможна.
Подробности:
Стоимость бага в первом случае:
Если баг был допущен на уровне спека и найден во время тестирования
кода, его стоимость вычисляется как
стоимость оплаты продюсера в час, помноженная на количество
часов, потраченных на разработку "неправильной" части спека
(стоимость спека), плюс + стоимость программирования
"неправильной" части спека плюс + стоимость тестирования
"неправильной" части спека плюс + стоимость фиксирования бага и
проблем, из него вытекающих.
Как видно, слагаемые поддаются приблизительной оценке.
Стоимость бага во втором случае:
Если баг был допущен на уровне спека, но не придушен до релиза и найден