102 Часть /: Основы

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

Целью составления отчета об ошибке является ее исправление.

Если вы хотите, чтобы найденная ошибка была быстро и надежно ис­правлена, прежде всего сделайте следующее.

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

• Тщательно проанализируйте ошибку, чтобы описать ее предельно кратко. Слишком пространное описание проблемы затрудняет по­нимание ее сути. Кроме того, встретив длинный отчет, программист подумает, что речь идет о чем-то сложном, и с большой вероятно­стью отложит его рассмотрение.

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

Отчет следует составлять немедленно

Обнаружив ошибку, следует сразу же составить о ней отчет. Хотя в нем довольно много граф, не стоит откладывать его заполнение, написав лишь короткие заметки. Очень важно, чтобы во время составления отчета все, о чем вы пишете, было у вас перед глазами, особенно это касается описания процедуры воспроизведения ошибки. Отчет ни в коем случае нельзя состав­лять по памяти, иначе очень легко ошибиться — программист не сможет повторить ситуацию и отложит отчет. Эта проблема довольно типична: тестировщики жалуются, что программисты постоянно игнорируют их от­четы, утверждая, что не могут воспроизвести ошибку. На самом же деле причина в неаккуратности самих тестировщиков.

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

Глава 5: Документирование и анализ ошибок 103

Структура отчета о проблеме

Во всех компаниях, занимающихся разработкой и тестированием про- I раммного обеспечения, форма отчета о проблеме одна и та же. Разумеет­ся. порядок и названия его полей могут несколько отличаться, но представленная в нем информация неизменна. На рис. 5.1 показана фор­ма отчета, которую предлагаем мы, а далее подробно описываются все ее поля.

Программа

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

Выпуск и версия

В отчете обязательно должно быть указано, к какой именно версии программного кода он относится. Например, идентификатор версии может быть таким: 1.01д. Он означает, что речь идет о пятой (д) черновой версии выпуска программы номер 1.01.

Поскольку программа все время находится в процессе усовершенство­вания, программист может не найти ошибку в ее текущей версии. В этом случае он посмотрит, с какой версией работал тестировщик, и обратится к пей, чтобы все-таки воспроизвести ошибку и гарантировать, что она ис­правлена.

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

Тип отчета

В графе Тип отчета указывается тип обнаруженной проблемы.

1. Ошибка кодирования. Программа ведет себя не так, как должна по мнению тестировщика. Например, если программа утверждает, что

2 + 2 = 3, то это явная ошибка кодирования. Программист же в от­вет на отчет о такой ошибке вполне может написать Соответствует проекту.