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

Цели тестировщика документации

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

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

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

Необходимо проверить, не пропущены ли в документации какие-нибудь функции продукта. Писатели опираются на спецификацию, собственные заметки и слухи.

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

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

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

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

Для взаимодействия с техническими писателями формальная система отслеживания проблем обычно не применяется. Большинство комментари­ев вносится прямо в копию руководства.

Сохраняйте копии комментариев и проверяйте по ним очередные вер­сии документации. Договоритесь с техническим писателем о том, как бу­дут выделяться в тексте правки и комментарии.

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

Как тестирование документации повышает надежность программного продукта

Многие тестировщики халатно относятся к тестированию документации, считая, что оно отрывает их от “настоящей” работы, заключающейся в тестировании программы. Они очень ошибаются.

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

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