Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
Глава 10: Тестирование документации 2 5 1 Цели тестировщика документации Читая и анализируя документацию, следует прежде всего уделить вни мание ее точности, полноте, ясности, простоте использования и тому, насколько она соответствует духу программного продукта. Вы наверняка найдете проблемы в каждой из этих областей. Поэтому запланируйте мно гократное тестирование печатного руководства, интерактивной справки и других документов. Тестировщик, работающий с документацией, отвечает за техническую точность каждого ее слова. Он обязан произвести самую тщательную про верку ее соответствия реальной структуре и поведению программы. И здесь тоже наверняка будет выявлено множество ошибок. Обращайте внимание на сложные и запутанные места текста. Они мо гут отражать неудачно спроектированные элементы самой программы. Технический писатель обязан описать продукт таким, каким он является на самом деле. И помочь проблеме может только изменение проекта. Наста ивать на таких изменениях важно еще и потому, что в конечном счете они обеспечат не только простоту документирования продукта, но и легкость его использования. Необходимо проверить, не пропущены ли в документации какие-нибудь функции продукта. Писатели опираются на спецификацию, собственные заметки и слухи. И хотя разработчики стараются держать технических писателей в кур се дела, они иногда забывают сообщить о новых функциях, только что внесенных в программу. И поскольку тестировщики сталкиваются с этими функциями гораздо раньше технических писателей, стоит позаботиться, чтобы их описания попали в документацию. Кроме того, если определен ная функция описана в руководстве, это не значит, что она будет описа на и в интерактивной справке. Вполне вероятно, что их пишут разные люди, и новая информация легко может потеряться. Однако не забывайте, что вы являетесь тестировщиком, а не техничес ким писателем. Не стоит думать, что вы знаете, как писать документацию лучше, чем ее авторы. Вы одинаково не имеете права требовать изменений в руководстве, так и в самом проекте. Обязанность тестировщика — выя вить проблему, а что с ней делать, решать не вам. В частности, у тестировщика нет никакого права требовать стилисти ческих изменений текста. Можно предложить такие изменения, но техни ческий писатель вправе оставить все как есть, и при этом он не обязан Доказывать вам, что поступает правильно. Именно ему, а не вам, платят за принятие решений относительно стиля документации. 2 5 2 Часть II: Приемы и технологии тестирования Для взаимодействия с техническими писателями формальная система отслеживания проблем обычно не применяется. Большинство комментари ев вносится прямо в копию руководства. Сохраняйте копии комментариев и проверяйте по ним очередные вер сии документации. Договоритесь с техническим писателем о том, как бу дут выделяться в тексте правки и комментарии. Подумайте, как облегчить вашу совместную работу и какие приемы будут удобны техническому писателю. Если вы вычитываете распечатанный текст, возможно, стоит воспользоваться некоторыми обозначениями, при меняемыми профессиональными редакторами. Возможно, стоит попросить технического писателя делать пометки о том, как решаются выявленные проблемы, но только в случае, если они вам действительно полезны. Как тестирование документации повышает надежность программного продукта Многие тестировщики халатно относятся к тестированию документации, считая, что оно отрывает их от "настоящей" работы, заключающейся в тестировании программы. Они очень ошибаются. • Вы найдете гораздо больше ошибок, чем предполагаете. Удивитель но, сколько ошибок обнаруживается при тщательном тестировании документации и сверки ее с программой опытным специалистом. Технический писатель видит программу иначе, чем программист или тестировщик, у него своя точка зрения, и потому он нередко выяв ляет проблемы, которые программисту и тестировщику даже не при ходят в голову. Мы столько раз сталкивались с подобными вещами в самых разных проектах, что практически без колебаний можем ут верждать, что в ходе тестирования документации будут выявлены очень серьезные ошибки, которых вы не найдете при стандартном тестировании программы. Не всегда в ходе тестирования документации выявляются серьезные проблемы. Тестировщики, не особенно тщательно выполняющие свою работу, не смогут обнаружить много проблем. Полноценное тестирование руководства обычно требует от одного до трех часов на каждые пять страниц текста. Ускорение этой работы означает сни жение ее качества. Об этом следует поставить в известность руко водство и при необходимости поднять вопрос о перераспределении и обучении персонала. Глава 10: Тестирование документации 2 5 3 • Документация является прекрасным источником реальных тесто вых примеров. Не стоит рассчитывать протестировать все возможные комбинации функций и опций продукта — их слишком много. Од нако можно протестировать каждую комбинацию, которая описана в документации как интересная или полезная. Если в документации упоминается, что два аспекта программы хорошо работают вместе, обязательно это проверьте. • Отчетам об ошибках, выявленных в ходе тестирования документа ции, уделяется особое внимание. Руководство представляет собой инструкции компании о том, как использовать программный про дукт. И если тестировщик пишет в отчете, что программа сбоит при выполнении инструкций и предложений, записанных в руководстве, никто не скажет, что эта ошибка "неуловима". В данном случае тесты абсолютно просты. Это то, что будут делать очень многие пользователи. И именно о таких ошибках будет злораднее всего объявлять профессиональная пресса. Такие ошибки руководителем проекта отложены не будут. Или изменится программа, или изме нится документация, но ситуация обязательно будет исправлена. Нам не раз приходилось сталкиваться с тем, что отложенные ошибки пересматриваются и исправляются после того, как они встретились снова в ходе тестирования документации. Итак, чтобы протестировать документацию, нужно сесть с ней пе ред компьютером и выполнить следующее. • В точности выполнить все действия, описанные в руководстве. Каждая указанная в нем клавиша должна быть нажата, каждый пример полностью выполнен. Следуя инструкциям, пользователи допускают ошибки. Поэтому работайте "слегка неаккуратно", чтобы посмотреть, как реагирует на это программа. Вопрос о плохой обработке ошибок встанет гораздо серьезнее, если окажется, что программа недопустимым образом реагирует на обычные допускаемые очень многими людьми ошиб ки, особенно когда они пытаются следовать руководству. • Следуйте каждому предложению, даже если оно сформулировано лишь в общих чертах. Ведь и пользователи попытаются ему после довать. • Проверяйте каждое утверждение и каждое его очевидное следствие. Поскольку руководство в определенном смысле представляет собой окончательную версию спецификации программы, пользователь в первую очередь именно по нему будет проверять, правильно ли она работает. 254 Часть II: Приемы и технологии тестирования Привлекая к работе над проектом нового тестировщика, предложите ему для начала протестировать документацию. Это принесет двойную пользу: в документации будут отражены все текущие изменения програм мы, а новый сотрудник сможет с ней быстро и обстоятельно познакомить ся. Назначьте технического редактора Лучше всего, если один из сотрудников группы тестирования будет назначен техническим редактором документации. Этот сотрудник может выполнять и другую работу, но главной его задачей должен быть анализ документации, даже если ее прорабатывают и другие тестировщики. Часто бывает, что, хотя над продуктом работают несколько человек, никто из них не несет полной ответственности за его качество. В резуль тате продукт не только не выигрывает оттого, что его проверяет большее количество людей, но еще и проигрывает, поскольку каждый подсознатель но перекладывает ответственность на другого и ожидает, что ту или иную часть работы выполнят его коллеги (Деминг (Deming, 1982)). Эту пробле му и решает назначение редактора, несущего полную ответственность за ка чество и точность технической документации. Работа с руководством в процессе его разработки Хорошее описание компонентов руководства пользователя можно найти у Мак-Джеи (McGehee, 1984). Руководство разрабатывается поэтапно. Этот процесс включает следу ющие основные стадии. • Разработка концепции и базовой структуры. Технический писатель определяет масштаб книги, ее аудиторию, решает, насколько под робно должен быть изложен материал и как он будет организован. • Подготовка. Руководство пишется, анализируется, перерабатывается и т.д. Оно находится на стадии подготовки до тех пор, пока не будет полностью завершено. • Производство. На этом этапе принимаются решения, связанные с подготовкой книги к печати. Подбираются шрифты, параметры стра ницы, общее оформление и т.п. • Публикация. В завершение руководство печатается и переплетается. Основные усилия тестировщиков сосредоточиваются на подготовке руководства. Проектированием руководства и его оформлением при подго товке к печати занимаются соответствующие специалисты. То же самое Глава 10: Тестирование документации 2 5 5 касается и публикации: автор сам проверяет, все ли страницы на месте, не распечатаны ли они вверх ногами и т.п. Подробнейшее обсуждение процес са разработки и редактирования документации можно найти у таких авто ров, как Брокман (Brockmann, 1990), Хастингс и Кинг (Hastings and King, 1986) и Прайс (Price, 1984). В ходе работы над проектом направление усилий тестировщика доку ментации меняется. В один период технический писатель более охотно работает над точностью изложенной информации, в другой — над стилем, в третий — над организацией руководства. В следующих разделах расска зывается о значении и уместности различных типов комментариев тести- ровщика в разные периоды разработки документации. Однако все сказанное относится к "типичному" техническому писателю. Поскольку все люди очень разные, обязательно поговорите с тем человеком, с которым придется работать вам, и расспросите его о его личных предпочтениях, нуждах и планах. Первый черновик С первым черновиком руководства вам не часто придется знакомиться. Даже у самых лучших технических писателей первый черновик обычно выглядит не слишком презентабельно, и они его неохотно показывают другим. Скорее к нему можно относиться как к личным заметкам техни ческого писателя. На первом черновике автор экспериментирует, не осо бенно тщательно прорабатывая его содержание. В нем может быть множество ошибок, как синтаксических, так и фактических, и написан он может быть явно плохо. Возможна, однако, ситуация, когда вас только что назначили на проект, вы не знаете, как должна работать программа, а спецификацию достать не удается. В этом случае можно попросить технического писателя дать вам хоть какую-нибудь документацию, даже если это пока еще только наброс ки, и, может быть, он согласится. В этом случае важно понимать, что это еще не документ, а именно наброски, предназначенные только для личного использования. Если технический писатель доверил их вам, то никакая критика в их адрес с вашей стороны неуместна и недопустима. Однако некоторые комментарии могут быть техническому писателю полезны. Если в тексте содержится явная ошибка, если вам кажется, что технический писатель просто чего-либо не понимает, поделитесь с ним своими знаниями. Однако облеките свои слова в форму обсуждения и совместного изучения продукта, а отнюдь не критики или комментариев. И уж во всяком случае недопустимы комментарии относительно стиля, структуры или организации руководства, если только вас об этом явно не попросили. И даже в этом случае постарайтесь говорить как можно тактич нее. 2 5 6 Часть II: Приемы и технологии тестирования Второй черновик На самом деле это может быть уже двадцать второй черновик — речь идет о первой версии руководства, которая будет передана вам для тести рования. Кроме вас, с ней познакомятся программист и руководитель про екта. Пользователи ее не увидят, разве что те из них, которые официально принимают участие в тестировании продукта. На этом этапе вам предсто ит следующая работа. • Проанализируйте структуру документа и как можно раньше со ставьте свои комментарии. Если вам не нравится порядок глав, если вы думаете, что материал нескольких из них лучше объединить в одну главу или, наоборот, разбить одну главу на несколько, скажи те об этом пораньше. С предложениями о перестановке глав можно немного подождать, но слишком затягивать тоже не стоит. Чем даль ше, тем труднее будет автору менять структуру книги. В некоторых группах документирования еще до написания первой строки руководства практикуется совместное обсуждение его плана. В хороший план включены названия всех глав и всех составляющих их разделов. В нем приведено приблизительное количество страниц каждого раздела, причем разделы длиной более 10 страниц обычно разбиты на подразделы. На такое совещание могут пригласить и представителя группы тестирования — для вас это лучшая возмож ность внести структурные предложения. Если вам кажется, что какой-либо из аспектов программы очень сложен и требует обстоятельного пояснения, а в плане ему отведе но явно мало страниц, спросите почему. Вполне возможно, что тех нический писатель еще просто недостаточно продумал этот вопрос или мало с ним знаком. Поясните его сложность в деловой и доб рожелательной манере, ни в коем случае не допуская критических или саркастических замечаний. Обоснованный и убедительный рас сказ о сложности одной из функций программы может принести проекту и дополнительную пользу: выслушав его, руководитель про екта может решить пересмотреть спецификацию и реализовать не удачную функцию более просто и удобно, в лучшем соответствии с общей идеей проекта. • Выполните общий анализ руководства. Прочитайте руководство, обращая внимание на его точность, понятность, полезность и пол ноту. Не стесняйтесь записывать такие, например, комментарии: "Чтобы понять этот раздел, мне пришлось трижды его прочесть". Даже если вы не можете объяснить, в чем сложность, все равно техническому писателю важно знать, что внимательный читатель испытывал затруднения при прочтении данного раздела. Глава 10: Тестирование документации 2 5 7 • Подумайте, какие еще вопросы требуют отдельного освещения. Возможно, в руководстве не описаны некоторые важные функции или особенности продукта. Технический писатель может о них про сто не знать, особенно если они только что появились. • Проанализируйте руководство на соответствие концепции продук та. Технический писатель может не понять простых концептуаль ных связей между функциями продукта и описать каждую из них независимо. При этом могут быть потеряны важные и тщательно продуманные идеи, заложенные в программу разработчиками. Очень важно, чтобы пользователь, читающий руководство, смог увидеть продукт в его концептуальной целостности. В руководстве может просматриваться неестественность некоторых ограничений программы. В этом случае сообщите об этом разработ чикам — вполне возможно, что они пересмотрят проект и упростят интерфейс. Стратегии, предлагаемые руководством для решения некоторых за дач, могут быть неэффективными. Это не значит, что они вообще не работают, но опытный и хорошо знающий продукт пользователь выбрал бы лучший способ их решения. Технический писатель мог не до конца понимать продукт, а возможно, лучшее решение просто не пришло ему в голову. Такие фрагменты руководства с неэффектив ными инструкциями лучше переписать как можно раньше, даже если они достаточно велики. Технический писатель должен понимать важность подобных изменений. • Поищите неточности. Некоторые примеры или описания могут быть вполне верными, но написанными так, что читатель может неверно их истолковать или необоснованно обобщить. Он может предположить, что функции или возможности программы шире, чем это есть на самом деле, или распространить на всю программу не которое утверждение, касающееся только очень конкретной ситуа ции. Возможно и обратное, когда читатель решит, что в программе имеются ограничения, которых на самом деле нет. Выявить подобные неточности лучше как можно раньше, посколь ку они могут означать, что технический писатель и сам неверно понимает продукт, и делает необоснованные обобщения. Лучше поняв программу, технический писатель может внести в руководство значительные изменения. • Проверьте сообщения об ошибках. Скоре всего, технический писа тель включил в приложение список сообщений об ошибках с пояс- 2 5 8 Часть II: Приемы и технологии тестирования нениями того, почему читатель получил такое сообщение и что ему теперь делать. Если у вас есть собственный список ситуаций, в ко торых вы получали каждое сообщение об ошибке, он может оказать техническому писателю неоценимую помощь. Технический писатель будет основывать свои пояснения и инструкции на той информации, которую предоставите ему вы, руководитель проекта и сотрудники группы технической поддержки. Для последних исключительно важ но, чтобы эти объяснения были как можно более исчерпывающими, чтобы пользователи поменьше донимали их звонками. Поэтому обя зательно протестируйте каждое сообщение и соответствующие инст рукции — вы наверняка найдете здесь приличное количество ошибок. Если в ходе тестирования выяснится что-нибудь полезное, например, дополнительное значение сообщения, новые ситуации, в которых оно появляется, или новая информация о том, как пользо вателю избегать подобных ситуаций или исправлять их последствия, то обязательно сообщите об этом техническому писателю, чтобы он дополнил руководство. |