Начните с проверки плана тестирования для определения потребности в оценке. Определите, насколько точно можно оценить длительность тестирования и качество программного обеспечения, применяя выбранный подход к тестированию. Определите, предъявляют ли объекты тестирования какие-либо особые требования.

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

Возможность тестирования обеспечивается двумя факторами: разработкой программного обеспечения, пригодного для тестирования, и формированием адекватного подхода к тестированию. Возможность тестирования - важный аспект разработки ресурсов группы тестирования, а также важный элемент всего проекта разработки программного обеспечения. Обеспечение возможности тестирования (возможности эффективно тестировать программный продукт) обычно обусловлено следующими обстоятельствами:

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

Проанализируйте требования к распределению

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

Проанализируйте требования к параллелизму

Должен ли текущий комплект тестов выполняться параллельно с другими комплектами тестов? Если да, воспользуйтесь элементами обеспечения возможности тестирования, поддерживающими параллелизм. Эти элементы чаще всего будут представлять собой сочетание конкретных инструментов поддержки, обеспечивающих одновременное выполнение нескольких комплектов тестов в разных физических системах. Обеспечение параллелизма требует тщательной подготовки данных для тестирования и тщательного управления тестированием, позволяющего предотвратить возникновение нежелательных и непредвиденных побочных эффектов в ситуациях, когда два теста пытаются одновременно изменить один и тот же объект данных.

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

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

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

Для адаптации к структуре распределения работы (WBR) в конкретном коллективе может потребоваться разделить или реструктурировать отобранные наборы тестов. Это может позволить сократить вероятность возникновения конфликтов при разработке наборов тестов. Иногда инструменты автоматизации тестирования предъявляют определенные требования к организации работы с ресурсами автоматизации, и при необходимости рекомендуется реструктурировать наборы тестов для удовлетворения этих требований.

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

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

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

Эта задача в основном связана с определением порядка, в котором будут выполняться сценарии и наборы тестов. Если не будут правильно определены зависимости между тестами, повышается вероятность сбоев и получения неестественных данных при тестировании.

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

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

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

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

Поддерживайте прослеживаемость в соответствии с требованиями к прослеживаемости, изложенными в плане тестирования.

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

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

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