•Процент ошибок падает ниже заданного уровня.

Помимо этого существуют некоторые физические пределы, обычно фиксированные, которыми, в конечном счете, определяется заверше% ние тестирования:

•Достижение предельных сроков (тестирования или сдачи готового продукта). Разработка обладает неприятным свойством затягивать% ся и съедать время, предназначавшееся для тестирования, что тре% бует тщательного административного контроля.

•Израсходование средств, выделенных на тестирование (достойный сожаления критерий остановки).

•Окончание срока альфа% или бета%тестирования.

В большинстве организаций решение о прекращении тестирования и поставке продукта принимается в связи с достижением предельных сроков. Это компромисс между известными остающимися ошибками, степенью их тяжести и частотой проявления с одной стороны и необхо% димостью выхода на рынок – с другой. Тесты позволяют принять обос% нованное решение относительно степени готовности продукта.

Вопросы личного характера

1.Для какой части своего кода вы пишете тесты? Вас это удовлетворяет? Входят ли ваши тесты в процедуру автоматизированной сборки? Как вы проводите тестирование остального кода? Адекватно ли оно? Соби раетесь ли вы изменить свою процедуру?

Не считайте себя обязанным писать тесты для каждого кусочка кода. Но не забывайте и головой думать. Чтобы реализовать простую функ% цию, обычно не требуется особых размышлений – потому и пишут ее не задумываясь, откуда и результат: глупые ошибки. Поскольку для простой функции и тест нужен простой, может быть, стоит его напи% сать. В моей фирме действует простое правило: для каждого фрагмен% та кода есть свой тест, иначе он не включается в базовый код.

Важно осуществлять адекватное и достаточное тестирование, чувст% вуя за него ответственность, а не уклоняться от неприятной задачи. Спросите себя, от скольких ошибок, с которыми вы столкнулись в по% следнее время, можно было бы уберечься при наличии хорошего набо% ра тестов? Так обеспечьте себе его!

Если ваши тесты не входят в систему сборки, как вы можете гаранти% ровать их выполнение и прохождение через них всего кода?

2.Какие у вас отношения с сотрудниками отдела QA? Какое мнение у них сложилось о вас?

Очень важно установить хорошие рабочие отношения между отделом QA и разработчиками программного обеспечения. Между ними часто возникает соперничество; тестирующее подразделение рассматривает% ся как кучка людей, стремящихся помешать разработке и затруднить

выпуск окончательной версии, а не тех, кто помогает создать стабиль% ный продукт. Обычно тестеры и разработчики сидят в разных концах и не слушают никого, кроме своих предводителей.

Покончите с этим.

Угостите их кофе. Пригласите на ленч. Отправьтесь вместе в бар. При% мите все меры для прекращения разделения на своих и чужих.

Наладьте профессиональные рабочие отношения. Старайтесь предо% ставлять им добротный, протестированный код, а не все, что вы впо% пыхах написали. Если вы будете кидать им мусор, с которым они вы% нуждены будут разбираться, у них сложится впечатление, что вы от% носитесь к ним как к слугам, а не как к коллегам по работе.

3. Как вы обычно поступаете, обнаружив ошибку в своем коде?

Реакция бывает разной:

•Отвращение и разочарование

•Желание обвинить кого%то другого

•Счастье или просто восторг

•Пытаетесь делать вид, что этого не было, не обращаете внимания, надеетесь, что все уладится (как будто такое возможно).

Кое%что из перечисленного настолько ошибочно, что, я надеюсь, вы до этого не опускаетесь. Вам кажется, что только ненормальный может предположить, что можно испытывать счастье при обнаружении ошиб% ки? Но это вполне рациональная реакция для программиста, озабочен% ного проблемами качества; гораздо лучше, если ошибки обнаружатся во время разработки, чем пользователи найдут их во время работы.

Степень вашего восторга будет зависеть от того, на какой стадии раз% работки будет найдена ошибка. Обнаружение критической ошибки за день до выпуска продукта никого не сделает счастливым.

4. Пишете ли вы отчет по каждой обнаруженной в коде проблеме?

На самом деле нет необходимости делать это для каждой отдельной ошибки. Если вы не записываете отчет об ошибке в базу данных, то нужно методически делать заметки, чтобы не забыть о ней. По этой причине может оказаться удобнее использовать с самого начала систе% му отслеживания ошибок. Необходимость подачи сообщений об ошиб% ках может возникнуть в том случае, если продукт отгружается с таким запозданием, что нужно известить людей об остающихся проблемах.

Как только вы делаете доступной очередную версию кода, следует публиковать данные обо всех имеющихся ошибках. Это должно де% монстрировать, что вы знаете обо всех проблемах и работаете над их решением.

Обнаружив ошибку в коде, нужно написать тест, который ее демонст% рирует, и включить его в свой комплект автоматических проверок,