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

Тестирование разработчиком

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

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

Независимое тестирование

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

"Цель независимого тестирования - взглянуть на продукт с другой точки зрения, а следовательно, выполнить другие тесты; таким образом, выполняется более разностороннее [...] тестирование, чем если бы тестированием занимались только разработчики". [BEI95]

Независимое тестирование заинтересованными лицами

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

Наконец, к этой категории независимого тестирования RUP относится понятие тестирования клиентами в терминологии XP.

Тестирование модулей

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

Тестирование интеграции

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

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

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

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

Тестирование системы

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

Приемка

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

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

Примечание о последовательности и времени выполнения разных уровней тестирования

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