ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013 Системная и программная инженерия. Тестирование программного обеспечения. Часть 1. Понятия и определения

Приложение С
(справочное)

     
Тестирование в различных моделях жизненного цикла

С.1 Общие сведения

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

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

- динамичная;

- эволюционная;

- последовательная (т.е. каскадная модель).

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

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

С.2 Динамичная разработка и тестирование

С.2.1 Принципы динамичной разработки

Динамичная разработка обычно соответствует нижеперечисленным принципам:

- разработка по этапам - результатом каждого цикла являются полезные и применимые продукты;

- цикличность разработки - в ходе разработки допускается развитие требований (то есть изменение и добавление);

- разработка ориентирована на людей - опора на качество проектной группы (например, разработчиков и тестеров), а не на точно определенные процессы; обеспечение самоуправления быстрой и динамичной команды; ежедневное взаимодействие группы разработчиков с бизнес-заинтересованными сторонами;

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

Существует множество методик и схем динамичной разработки, включая: Экстремальное программирование (ХР), Scrum, Crystal, Kanban и Feature-Driven Development. В то время как все они используют различные подходы, они следуют принципам динамичной разработки, изложенным в манифесте динамичной разработки (Agile Manifesto, см. http//:agilemanifesto.org/). Поскольку в рамках настоящего стандарта невозможно рассмотреть его использование при реализации всех методов и схем динамичной разработки, то в качестве примера в настоящем стандарте будет использована схема метода Scrum. Метод Scrum не является методологией разработки (то есть он не предлагает лучших методов описания требований или записи кода), а определен как схема менеджмента проектов, в которой разработчиками используется динамичная методология (часто используется ХР).

Проект Scrum состоит из множества итераций, называемых спринтами. Результатом каждого спринта обычно является новая функциональность, которая может быть предоставлена пользователям, как показано на рисунке С.1. Подобная новая функциональность может представлять собой улучшение предшествующей функциональности или дополнение ее новыми возможностями. Продолжительность каждого спринта обычно составляет от одной до четырех недель. Зачастую количество спринтов в начале проекта неизвестно, поскольку в начале типичных динамичных проектах требования не определены полностью. В ходе проекта требования развиваются. Требования потребителя собираются в Портфеле Продукта обычно в виде истории пользователей.

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

С.2.2 Менеджмент тестирования в динамичной разработке

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

    
Рисунок С.1 - Проект Scrum в качестве примера жизненного цикла проекта (динамичная разработка)

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

В начале разработки спринта команда Scrum и потребитель (владелец продукта) приходят к соглашению, какие из историй пользователя из портфеля продукта должны быть реализованы в этом спринте. Отобранные истории включаются в портфель спринта. Затем команда разрабатывает план спринта, планируя разработку и тестирующие действия и присваивая роли и обязанности членам команды. Динамичная разработка осуществляется посредством тех же общих процессов, присущих любой разработке и тестированию продукта, как это показано на примере спринта Scrum на рисунке С.2.

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

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