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

5.3. Общие процессы тестирования в жизненном цикле программного обеспечения

Программное обеспечение имеет ожидаемый жизненный цикл от начальной его концепции до возможного прекращения его использования. Тестирование программного обеспечения имеет место в более широком контексте разработки и сопровождения программного обеспечения. В 5.3 в качестве примера рассмотрен жизненный цикл разработки программного обеспечения и некоторые связи между его подпроцессами и процессами тестирования. В ИСО/МЭК 12207:2008 подробно рассмотрены жизненные циклы программного обеспечения. В ИСО/МЭК 15288 подробно рассмотрены процессы жизненного цикла системы. Пример жизненного цикла системы показан на рисунке 6.

 

 

Рисунок 6 - Пример жизненного цикла программного обеспечения

 

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

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

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

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

Тестирование может выполняться для оценки удовлетворения бизнес-требований к приобретаемому программному обеспечению. Основы оценки и тестирования приобретаемого готового коммерческого программного обеспечения (COTS) можно найти в ИСО/МЭК 25051.

5.3.1 Подпроцессы проекта разработки и их результаты

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

В подпроцессы разработки могут входить:

- инженерия требований;

- проектирование архитектуры;

- детальное проектирование;

- кодирование.

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

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

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

 

 

Рисунок 7 - Пример подпроцессов разработки

 

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

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

5.3.2 Текущее сопровождение и его результаты

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

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

 

 

Рисунок 8 - Пример периода корректировки

по ходу обслуживания

 

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

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

5.3.3 Процессы поддержки в жизненном цикле разработки программного обеспечения

Процессы поддержки необходимы в организации для обеспечения поддержки жизненного цикла разработки программного обеспечения. Некоторые из этих процессов:

- обеспечение качества;

- менеджмент проектов;

- менеджмент конфигурации;

- совершенствование процессов.

5.3.3.1 Обеспечение качества и тестирование

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

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

5.3.3.2 Менеджмент проектов и тестирование

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

 

                   ┌──────────────────────────────────┐

                   │   Процессы менеджмента проекта   │

                   └─┬────────────────────────────────┘

                     │  Управляющие              /\  Отчет

                     │  директивы                │   о завершении

                     │                           │

                     │  План                     │   Тестовые

                     │  проектирования           │   измерения

                     \/                          │

                   ┌─────────────────────────────┴────┐

                   │Процессы менеджмента тестирования,│

                   │  влияющие на проект тестирования │

                   └──────────────────────────────────┘

 

Рисунок 9 - Взаимосвязь всего проекта и проекта тестирования

 

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

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

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

5.3.3.3 Менеджмент конфигурации и тестирование

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

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

Рабочие продукты процесса тестирования, которые могут быть переданы в менеджмент конфигурации, включают в себя:

- Организационные Спецификации Тестирования (например, Политика Тестирования, Организационная Стратегия Тестирования).

- Планы тестирования.

- Спецификации тестирования.

- Элементы конфигурации тестовой среды, такие как инструменты тестирования, тестовые данные (основа), драйверы и заглушки.

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

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

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

Отчеты менеджмента конфигурации для процесса тестирования должны предоставить подробные результаты, которые могут потребоваться для анализа прогресса и состояния инцидентов.

5.3.3.4 Совершенствование процессов и тестирование

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

Процессы тестирования и процесс совершенствования процессов взаимодействуют двумя способами:

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

2 Сами процессы тестирования могут быть объектами совершенствования процессов.

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

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