ГОСТ Р 56920—2016
С.3.2 Менеджмент тестирования в последовательной разработке
В Организационной Стратегии Тестирования должно быть отражено, что разработка соответствует после
довательной модели разработки. В ведущей разработку организации, если там используется сочетание разных
моделей разработки для различных проектов, включая последовательную, обычно существует одна или несколь ко
конкретных организационных стратегии тестирования для используемых моделей разработки. Организацион ная
Стратегия Тестирования должна использовать терминологию, применяемую в соответствующем типе проекта,
в противном случае, содержание Организационной Стратегии Тестирования будет зависеть от соотве тствующего
профиля риска для проектов и продуктов, а не от типа используемой модели разработки.
Последовательный проект управляется менеджером проекта. Для большинства проектов также определе
ны роли менеджера по развитию и менеджера по тестированию. В зависимости от размера проекта эти роли могут
выполняться различными людьми или несколько ролей могут выполняться одним и тем же человеком.
Планы последовательной разработки создаются для всего проекта, хотя в ходе проекта они должны разви
ваться. Проекты последовательной разработки могут быть относительно велики, и в начале проекта детальное
планирование всего проекта может быть невозможно. Необходима также и разработка Плана Тестирования Про
екта. Этот план обычно оформляется в виде отдельного документа, но может быть и частью общего плана проек
та. Возможна разработка отдельных планов подпроцессов тестирования при условии, что выполнение этих
подпроцессов тестирования предусмотрено Планом Тестирования Проекта. В последовательной разработке пла
ны обычно документируются формально.
С.3.3 Подпроцессы тестирования в последовательной разработке
Подпроцессы тестирования, определенные для эволюционной разработки в С.З, имеют также большое зна
чение для тестирования в последовательном проекте, хотя они выполняются только один раз (один проход через
последовательную модель разработки).
Рисунок С.З — Пример подпроцесса тестирования в последовательном жизненном цикле разработки
Следует обратить внимание на то. что рисунок С.З выполнен не в масштабе — относительный размер пока
занных подпроцессов тестирования не соответствует фактическим размерам подпроцессов тестирования с точки
зрения, например, затраченных времени, усилий или средств.
Определяются тестирование Архитектуры, тестирование Детального Проектирования и тестирование
Исходного Кода. Для каждого из них соответствующий этап разработки может быть закончен на основе результа тов
завершения тестирования, то есть после того, как все детально разработанные элементы были проверены
индивидуально.
Фаза кодирования включает в себя два различных подпроцесса тестирования. Первым из них является под
процесс тестирования исходного кода, представляющий собой статическое тестирование исходного кода, а вто
рым — покомпонентное тестирование, то есть динамическое тестирование исполнимого или интерпретируемого
кода. Эти подпроцессы тестирования могут использоваться совместно, идинамическое тестирование компонента
может зависеть от успешного статического тестирования исходного кода.
Конечным результатом фазы интеграции является завершенная система. На этом этапе может начинаться
выполнение действий тестирования системы, предполагая, что они уже были запланированы и подготовлены на
основе требований.
Подпроцессы тестирования, показанные здесь в качестве примера, описаны далее в приложении Е.
С.4 Эволюционная разработка и тестирование
С.4.1 Эволюционные принципы разработки
Эволюционная разработка основывается на двух основных принципах: итерации и инкрементной разработ
ке. Итерация позволяет разработчикам создавать систему в виде совокупности более мелких частей и для улуч-
35