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

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

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

Похожие отчеты

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

Десяток отчетов об одной и той же проблеме — это явно недопустимая трата времени программиста и руководителя проекта. Если ее можно избе­жать, следует сделать для этого все возможное.

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

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

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

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

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

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

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

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

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

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

Регистрация различных мнений

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

• Степень важности и Приоритет. Степень важности проблемы опре­деляет тестировщик, а ее приоритет задает руководитель проекта. Если в системе будет только одно из этих полей, постоянные спо-