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

Считать отложенным

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

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

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

Как же быть, когда вы не согласны с резолюцией руководителя проек­та или программиста, не согласны с определенным для проблемы приори­тетом или столкнулись с явным саботажем?

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

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

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

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

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

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

Каким должен быть отчет о проблеме

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

Реальный документ

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

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

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

Нумерация

Отчет о проблеме, как и всякий настоящий документ, должен иметь уникальный номер. В компьютеризованной базе данных этот номер должен быть ключевым полем таблицы отчетов, т.е. однозначным идентификатором