Глава 12; Планирование и документация 353

фикации или руководства и, если да, какие из документов правиль­ны? Какие еще предстоят значительные изменения?

• Утверждение. Сотрудники, ответственные за предоставляемые ма­териалы, должны подписать данный документ, подтверждая, что все элементы готовы к тестированию.

Тестовый сценарий

Этого документа в стандарте 829 нет. О его назначении и содержании уже рассказывалось в разделе “Сценарий теста для неопытного тестиров­щика”. Вот из чего он состоит.

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

• Начало. В этом разделе приводится описание процесса настройки среды и подготовки к выполнению теста.

• Пошаговые инструкции для выполнения каждого теста.

• Квадратики для отметок о прохождении каждого шага и отметок о результатах.

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

Журнал тестирования

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

• Идентификатор журнала тестирования.

• Описание. Тестируемый объект, включая номер версии, место про­ведения тестирования, аппаратное обеспечение (тип компьютера, объем памяти, принтер и т.п.), информация о программной конфи­гурации (операционная система, номер ее версии и т.п.).

• Действия и события. Что происходило в процессе тестирования. Запись может включать следующие составляющие.

12 '-^п

354 Часть П: Приемы и тс\1ш>ш.’1ш пи\ти[нтанш1

• Процесс. Какой была процедура тестирования, кп> iii.i i снидсте- лем происходящего и какой была роль этого человек;! в выполне- нии теста.

• Результаты. Что произошло, что вы видели, слышали и т.п., где записаны выходные данные.

• Аномальные события. Неожиданные события (как правило, объясняющиеся ошибками в программе). Что происходило до и после них.

• Идентификаторы отчетов об инцидентах. Номера составленных отчетов о проблемах.

Отчет об инциденте во время тестирования

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

Итоговый отчет

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

• Идентификатор итогового отчета.

• Описание. Что тестировалось (включая номера версий), в какой среде, как вы оцениваете полученные результаты? Приведите ссылки на спецификации тестов.

• Отклонения. В чем и почему процедура тестирования отличалась от описанной в спецификации?

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

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

• Оценка. Общая оценка каждого из элементов (программ, модулей) на основе результатов его тестирования. Каков риск, связанный с его реальной эксплуатацией, и вероятность сбоев (необязательно)?

/'шва /.’ // кшированш' и (и>кумгнтацаи 355

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

• Утверждение.

Документация в файлах данных и управляющих файлах

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

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

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

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

Заключение

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

Часть

Управление проектами и группами