Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Тестирование программного обеспечения. Фундамен...docx
Скачиваний:
3
Добавлен:
01.05.2025
Размер:
936 Кб
Скачать
☆

114 Часть I: Основы

отчета в системе. В этом случае номера должны присваиваться автомати­чески.

Простота

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

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

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

Понятность

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

Воспроизводимость

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

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

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

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

Разборчивость

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

— с неразборчивым отчетом никто не захочет иметь дело.

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

Беспристрастность

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

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

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

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