Глава 10: Тестирование документации 257

• Подумайте, какие еще вопросы требуют отдельного освещения.

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

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

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

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

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

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

• Проверьте сообщения об ошибках. Скоре всего, технический писа тель включил в приложение список сообщений об ошибках С пп.н

) 1-78

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

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

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

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