Глава 6: Система отслеживания проблем 147

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

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

• В итоговых отчетах неверно интерпретируются текущие данные.

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

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

• Информация базы данных используется для личных нападок на ру­ководителя проекта или других сотрудников или для искаженного представления проекта и его прогресса.

Программист

Программист читает отчет о проблеме и отвечает на него. Его недоволь­ство могут вызвать следующие обстоятельства:

148 Часть II: Приемы и технологии тестирования

• Отчет не совсем четкий и понятный, он недостаточно способствует исправлению ошибки.

• Из отчета неясно, против чего возражает тестировщик или что дол­жен сделать программист. Бывает, что отчет больше похож на абст­рактное описание поведения программы. Прочитавший его человек может остаться озадаченным: “Ну хорошо, а в чем же, собственно, проблема?”

• Описанная в отчете ситуация не воспроизводится.

• Отчет, возвращенный с запросом о дополнительной информации, снова поступает программисту в исходном виде.

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

• Формулировки отчета могут быть восприняты как персональная критика.

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

Менеджер по маркетингу

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

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

Группа технической поддержки

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