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