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

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

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

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

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

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

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

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

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

Программа изнутри

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

Само по себе изучение кода программы для ее отладки полезно. Оно позволяет гораздо быстрее выявить некоторые специфические ошибки.