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

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

		Текущие заплаты 08/07/98
Программа СаЫод		Выпуск 2.10
Серьезная	9996	Неверное число отображается в правом нижнем углу
Незначительная	10000 Хочу выделить столбец полужирным шрифтом
Фатальная	9998	Бесконечный цикл по таблицам, в которых более 100 строк

РИСУНОК 6.10. Сводный отчет о текущих заплатах

Дополнительные замечания о документировании проблем

Главным принципом построения и эксплуатации системы отслеживания проблем должна быть концентрация на выявлении и устранении ошибок. Никакой политики, никаких оценок, никаких административных функций

— только ошибки.

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

Выработка критериев оценки важности выявляемых проблем

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

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

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

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

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

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

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

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

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