ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТР

56921-

2016/

ISO/IEC/IEEE

29119-2:2013

СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ Тестирование программного обеспечения

Часть 2

Процессы тестирования

ISO/IEC/IEEE 29119-2:2013 Software and systems engineering — Software testing — Part 2: Test processes (IDT)

Издание официальное

Стандартинформ

2016

Предисловие

1    ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ) на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 18 мая 2016 г. № 332-ст

4    Настоящий стандарт идентичен международному стандарту ISO/IEC/IEEE 29119-2:2013 «Программная и системная инженерия. Тестирование программного обеспечения. Часть 2. Процессы тестирования» (ISO/IEC/IEEE 29119-2:2013 «Software and systems engineering — Software testing — Part 2: Test processes»).

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5 (пункт 3.5).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2016

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

4.46    Процесс Отчетности об Инцидентах Тестирования (Test Incident Reporting Process): Процесс динамического тестирования для создания отчетов для соответствующих заинтересованных сторон о проблемах, требующих дальнейших действий, которые были идентифицированы во время процесса выполнения теста.

4.47    элемент тестирования (test item): Рабочий продукт, который является объектом тестирования.

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

4.48    уровень тестирования (test level): Конкретная реализация подпроцесса тестирования.

Пример — Как подпроцессы тестирования можно рассматривать следующие общие уровни тестирования: уровень/подпроцесс покомпонентного тестирования, уровень/подпроцесс интеграционного теста, уровень/подпроцесс тестирования системы, уровень/подпроцесс приемочного испытания.

Примечание — Синонимом термина «уровень тестирования» является фаза тестирования.

4.49    менеджмент тестирования (test management): Планирование, составление графика, оценка, мониторинг, отчетность, управление и выполнение действий по тестированию.

4.50    Процесс Менеджмента Тестирования (Test Management Process): Процесс тестирования, содержащий подпроцессы, необходимые для менеджмента проекта тестирования.

Примечание — См. Процесс Планирования Тестирования, Процесс Мониторинга и Управления тестированием, процесс завершения тестирования.

4.51    Процесс Мониторинга и Управления Тестированием (Test Monitoring and Control Process): Процесс менеджмента тестирования для обеспечения соответствия выполнения тестирования плану тестирования и организационным спецификациям тестирования.

4.52    фаза тестирования (test phase): Определенная реализация подпроцесса тестирования.

Примечание — Фазы тестирования означают то же, что и уровни тестирования, поэтому примеры фаз тестирования совпадают с уровнями тестирования (например, фаза/подпроцесс тестирования системы).

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

Примечания

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

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

4.54    Процесс Планирования Тестирования (Test Planning Process): Процесс Менеджмента Тестирования, используемый для выполнения планирования тестирования и разработки Планов Тестирования.

4.55    Политика Тестирования (Test Policy): Руководящий документ, в котором описаны назначение, цели и полная предметная область применения тестирования в организации.

Примечания

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

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

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

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

ГОСТ Р 56921-2016

4.57    Спецификация Процедуры Тестирования (Test Procedure Specification): Документ, определяющий одну или более процедур тестирования, которые представляют собой наборы контрольных примеров для выполнения с определенной целью.

Примечания

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

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

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

4.59    результат тестирования (test result): Индикатор того, прошел ли определенный контрольный пример успешно или нет, т. е. соответствует ли фактический результат элемента тестирования ожидаемому результату или наблюдались отклонения.

4.60    тестовое требование (test requirement): См. «тестовое условие» согласно 4.31.

4.61    сценарий тестирования (test script): Спецификация процедуры тестирования для ручного или автоматизированного тестирования.

4.62    набор тестов (test set): Набор контрольных примеров для конкретных целей тестирования.

Примечания

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

2    Контрольные примеры для набора тестов могут быть отобраны на основе идентифицированных рисков, базиса тестирования, результатов повторного тестирования и/или регрессионного тестирования.

4.63    спецификация тестирования (test specification): Подробная документация проекта тестирования, контрольных примеров и процедур тестирования для конкретного элемента тестирования.

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

4.64    метод спецификации тестирования (test specification technique): См. «метод проектирования тестирования» согласно 4.38.

4.65    Отчет о Ходе Тестирования (Test Status Report): Отчет, который предоставляет информацию о состоянии тестирования, выполняемого в указанный отчетный период.

4.66    стратегия тестирования (test strategy): Часть Плана Тестирования, в которой описан подход к тестированию определенного проекта тестирования или процессам и подпроцессам тестирования.

Примечания

1    Стратегия тестирования — это производная от Организационной Стратегии Тестирования.

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

4.67    подпроцесс тестирования (test sub-process): Процессы менеджмента тестирования и процессы динамического (и статического) тестирования, используемые для выполнения определенного уровня тестирования (например, тестирование системы, приемочные испытания) или его определенного типа (например, тестирование удобства использования, тестирование производительности) обычно в контексте полного процесса тестирования.

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

4.68    методика тестирования (test technique): См. термин «методика проектирования тестирования» согласно 4.38.

4.69    тип тестирования (test type): Совокупность тестирующих действий, которая фокусируется на определенных показателях качества.

7

Примечание — Тип тестирования может быть выполнен одиночным подпроцессом тестирования или несколькими подпроцессами тестирования (например, тестирование производительности, выполненное в ходе подпроцесса покомпонентного тестирования и подпроцесса тестирования системы).

Примеры — Тестирование защищенности, функциональное тестирование, тестирование удобства использования и тестирование производительности.

4.70 тестирование (testing): Набор операций, проводимых для обеспечения выявления и/или оценки свойств одного или более элементов тестирования.

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

5 Многоуровневая модель процесса тестирования

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

Рисунок 1 — Уровни процессов тестирования

Задачи процессов каждого уровня:

a)    Организационный Процесс Тестирования (раздел 6):

1) Определение процесса создания и поддержки Организационных Спецификаций Тестирования, таких как Организационные Политики Тестирования, стратегии, процессы, процедуры и другие активы;

b)    Процессы Менеджмента Тестирования (раздел 7):

1)    Определение процессов, которые охватывают менеджмент тестирования в рамках всего проекта тестирования, любой фазы тестирования (например, тестирование системы) или любого типа тестирования (например, тестирование производительности) в составе проекта тестирования (менеджмент тестирования проекта, менеджмент тестирования системы, менеджмент тестирования производительности);

2)    Процессы Менеджмента Тестирования:

-    Процесс Планирования Тестирования (см. 7.2);

-    Процесс Мониторинга и Управления Тестированием (см. 7.3);

-    Процесс Завершения Тестирования (см. 7.4);

c)    Процессы Динамического Тестирования (раздел 8):

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

8

ГОСТ Р 56921-2016

2) Процессы Динамического Тестирования:

-    Процесс Разработки и Реализации Тестирования (см. 8.2);

-    Процесс Установки и Поддержки Тестовой Среды (см. 8.3);

-    Процесс Выполнения Теста (см. 8.4);

-    Процесс Отчетности об Инцидентах Тестирования (см. 8.5).

Примечание — В ИИЭР 1012 вместо термина «Процесс Динамического Тестирования» используется термин «Процесс тестирования».

Уровни модели процесса тестирования содержат разное число процессов тестирования, как показано на рисунке 2.

Организационный процесс тестирования

Г Процессы менеджмента тестирования Процесс планирования тестирования Процесс мониторинга и управления тестированием Процесс завершения тестирования Ч

Процессы динамического тестирования

Процесс Процесс Процесс Процесс разработки установки выполнения отчетности об и реализации и поддержки теста инцидентах тестирования тестовой среды тестирования

V_У

Рисунок 2 — Многоуровневая модель, в которой показаны все процессы тестирования

6 Организационный Процесс Тестирования

6.1 Введение

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

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

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

9

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

Рисунок 3 — Пример реализации организационного процесса тестирования

6.2 Организационный Процесс Тестирования

6.2.1    Общие сведения

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

6.2.2    Цель

Цель Организационного Процесса Тестирования состоит в разработке, мониторинге соответствия и поддержке организационных спецификаций тестирования, таких как Организационная Политика Тестирования и Организационная Стратегия Тестирования.

6.2.3    Результаты

Результаты успешной реализации Организационного Процесса Тестирования;

a)    определены требования для организационных спецификаций тестирования;

b)    разработаны организационные спецификации тестирования;

c)    организационные спецификации тестирования согласованы сзаинтересованнойстороной(ами);

d)    обеспечена доступность организационных спецификаций тестирования;

e)    осуществляется мониторинг соответствия организационным спецификациям тестирования;

10

Ь) Должны быть приняты соответствующие меры для поощрения заинтересованных сторон за соответствие организационной спецификации тестирования.

6.2.4.3 Обновление Организационной Спецификации Тестирования (ОТЗ)

Эта деятельность состоит из следующих задач:

a)    Необходим анализ обратной связи по использованию организационной спецификации тестирования.

b)    Должна быть рассмотрена эффективность использования и менеджмент организационной спецификации тестирования, определены и утверждены необходимые для повышения эффективности обратная связь и изменения.

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

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

d)    Информация обо всех изменениях в организационной спецификации тестирования должна быть распространена по всей организации, включая и заинтересованные стороны.

6.2.5 Информационные элементы

В результате выполнения этого процесса должен быть создан следующий информационный элемент:

а) Организационная Спецификация Тестирования.

Пример — Организационная Политика Тестирования, Организационная Стратегия Тестирования.

7 Процессы Менеджмента Тестирования

7.1 Введение

Имеют место три процесса менеджмента тестирования:

a)    планирование тестирования;

b)    мониторинг и управление тестированием;

c)    завершение тестирования.

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

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

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

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

Рисунок 6 — Процесс Планирования Тестирования

Если будет необходимо изменить стратегию тестирования по причинам, отличным от рисков (например, необходимо использовать другую тестовую среду), то процесс должен повторно войти в действие «Разработать стратегию тестирования» (ТР5).

Если возникла необходимость изменения штатного персонала или графика тестирования по причинам, отличным от рисков (например, возможность получения элементов тестирования от разработчиков), то процесс должен повторно войти в действие «Определить персонал и график» (ТР6).

7.2.2    Цель

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

7.2.3    Результаты

В результате успешной реализации Процесса Планирования Тестирования:

a)    проанализирован и уяснен объем работ проекта тестирования;

b)    определены и информированы заинтересованные стороны, которые будут участвовать в планировании тестирования;

c)    идентифицированы, проанализированы и классифицированы риски, которые могут быть обработаны при тестировании, с согласованным уровнем воздействия рисков;

d)    определены стратегия тестирования, тестовая среда, инструменты тестирования и потребности в тестовых данных;

Пример — Инструменты, специальное оборудование, тестовая среда, офис.

14

ГОСТ Р 56921-2016

e)    определены потребности в персонале и обучении;

f)    спланировано каждое действие;

д) рассчитаны оценки и документированы обоснования оценок;

Пример — Оценки стоимости, персонала и времени.

h) план тестирования согласован со всеми заинтересованными сторонами и доведен до них.

7.2.4 Действия и задачи

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

7.2.4.1    Уяснить контекст (ТР1)

Эта деятельность состоит из следующих задач:

a)    Для поддержки подготовки Плана Тестирования необходимо достигнуть понимания контекста и требований к тестированию.

Примечания

1    В требования тестирования программного обеспечения входит идентификация элемента(ов) тестирования.

2    Может быть использована следующая документация:

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

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

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

4)    применимые нормативные стандарты для получения информации о правилах, которые могут повлиять на тестирование;

5)    документация продукта, такая как спецификации системных требований, цели в области качества, определенные показателями качества системы и спецификациями элемента тестирования, для получения информации, которая касается возможных требований тестирования для этой фазы или типа тестирования;

6)    показатели качества, определенные в ИСО/МЭК 25010 «Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программного обеспечения»;

7)    план разработки программного обеспечения для получения информации, которая может повлиять на сроки или циклы тестирования временных шкал или циклов, такой как ожидаемые результаты и сроки разработки;

8)    реестр рисков проекта для получения информации об идентифицированных рисках проекта и продукта;

9)    план верификации и валидации.

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

c)    Необходимо инициировать план обмена информацией и документировать способы связи.

Примечание — Деятельность «Уяснить контекст» будет продолжаться на протяжении жизни проекта. Задачи этого действия могут, в принципе, быть выполнены в любом порядке.

7.2.4.2    Организовать разработку Плана Тестирования (ТР2)

Эта деятельность состоит из следующих задач:

a)    Необходимо идентифицировать и запланировать на базе требований тестирования, идентифицированных в деятельности «Уяснить контекст» (ТР1), те действия, которые нужно выполнить для завершения планирования тестирования.

b)    Необходимо определить заинтересованные стороны, требуемые для участия в этих действиях.

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

Пример — Менеджер проектов и/или менеджер тестирования проекта.

Примечание — Это может потребовать повторения задач а) и Ь).

d)    Нужно организовать участие заинтересованной стороны.

15

ГОСТ P 56921—2016

Содержание

1    Область применения..................................................................1

2    Соответствие........................................................................1

2.1    Предполагаемое соответствие......................................................1

3    Нормативные ссылки..................................................................2

4    Термины и определения...............................................................2

5    Многоуровневая модель процесса тестирования...........................................8

6    Организационный Процесс Тестирования.................................................9

6.1    Введение........................................................................9

6.2    Организационный Процесс Тестирования............................................10

7    Процессы Менеджмента Тестирования..................................................12

7.1    Введение.......................................................................12

7.2    Процесс Планирования Тестирования...............................................13

7.3    Процесс Мониторинга и Управления Тестированием...................................18

7.4    Процесс Завершения Тестирования.................................................21

8    Процессы Динамического Тестирования.................................................23

8.1    Введение.......................................................................23

8.2    Процесс Разработки и Реализации Тестирования......................................25

8.3    Процесс Установки и Поддержки Тестовой Среды.....................................29

8.4    Процесс Выполнения Теста........................................................31

8.5    Процесс Отчетности об Инцидентах Тестирования.....................................32

Приложение А (справочное) Пример использования Процесса Проектирования Тестирования.....35

Приложение В (справочное) Соответствие процессов в ИСО/МЭК/ИИЭР 29119-2

и ИСО/МЭК 12207:2008 ...................................................37

Приложение С (справочное)    Соответствие ИСО/МЭК/ИИЭР 29119-2 и ИСО/МЭК 15288:2008 ......52

Приложение D (справочное)    Соответствие ИСО/МЭК/ИИЭР 29119-2 и ИСО/МЭК 17025:2005......53

Приложение Е(справочное) Соответствие ИСО/МЭК/ИИЭР 29119-2 и ИСО/МЭК 25051:2006.......54

Приложение F (справочное)    Соответствие ИСО/МЭК/ИИЭР 29119-2 и BS 7925-2:1998............55

Приложение G (справочное)    Соответствие ИСО/МЭК/ИИЭР 29119-2 и ИИЭР 1008-2008 ..........56

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

национальным стандартам Российской Федерации...........................58

Библиография........................................................................59

Пример — Запросить менеджера проекта запланировать встречу для анализа стратегии тестирования.

7.2.4.3    Определить и изучить риски (ТРЗ)

Эта деятельность состоит из следующих задач:

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

Пример — Риски, занесенные в реестр рисков проекта.

b)    Необходимо идентифицировать дополнительные риски, которые касаются и/или могут быть обработаны при тестировании программного обеспечения.

Примечания

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

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

c)    Нужно классифицировать риски, используя надлежащую систему классификации, которая, как минимум, обеспечивает различие между рисками продукта и рисками проекта.

d)    Каждому риску должен быть присвоен уровень воздействия (на основе анализа его влияния и вероятности).

e)    Результаты такой оценки степени риска должны быть утверждены заинтересованными сторонами.

f)    Результаты такой оценки степени риска должны быть документированы.

Пример — Реестр рисков проекта в плане тестирования.

7.2.4.4    Определить подходы к обработке рисков (ТР4)

Эта деятельность состоит из следующих задач:

a)    Необходимо на основе типа риска, классификации и уровня подверженности риску идентифицировать соответствующие средства обработки.

Примечание — В надлежащие средства могут входить фазы тестирования, типы тестирования, методы проектирования тестирования, критерии завершения тестирования и т. д. На практике можно рассматривать понятие критичности программного обеспечения, определенное в ИСО/МЭК 15026 или ИИЭР 1012:2012. В случаях если для тестирования известны ограничения (такие, как время и стоимость), обработка рисков с низкими уровнями воздействия, которые, как предполагается, не будут обработаны при таких ограничениях, будут идентифицироваться как выходящие за рамки применения по причине ограничений.

b)    Результаты обработки рисков должны быть документированы.

Пример — В плане тестирования, в реестре риска проекта.

7.2.4.5    Разработать Стратегию Тестирования (ТР5)

Эта деятельность состоит из следующих задач:

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

Примечание — Особое значение имеют оценки требуемых усилий и необходимого времени.

b)    Необходимо произвести первоначальную оценку ресурсов, требуемых для выполнения отдельных действий по обработке, идентифицированных в действии «Определить подходы к обработке рисков»(ТР4),начиная с тех, которые соответствуют рискам с самыми высокими уровнями воздействия, как это было определено в действии «Определить и изучить риски»(ТРЗ).

Примечание — Из особого значения оценки усилия и требуемое прошедшее время.

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

16

Введение

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

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

Международные стандарты разрабатываются в соответствии с правилами, приведенными в Директивах ИСО/МЭК, часть 2.

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

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

ИСО/МЭК/ИИЭР 29119-2 был подготовлен Подкомитетом 7 «Системная и программная инженерия» совместного технического комитета ИСО/МЭК СТК 1 ((Информационные технологии» в сотрудничестве с комитетом по стандартам системной и программной инженерии компьютерного сообщества ИИЭР в соответствии с организационным соглашением о партнерском сотрудничестве по разработке стандартов между ИСО и ИИЭР

Серия стандартов ИСО/МЭК/ИИЭР 29119 состоит из следующих стандартов под общим названием «Системная и программная инженерия. Тестирование программного обеспечения»:

-    Часть 1. Понятия и определения;

-    Часть 2. Процессы тестирования;

-    Часть 3. Документация тестирования;

-    Часть 4. Методики тестирования.

Цель создания серии стандартов ИСО/МЭК/ИИЭР 29119 «Тестирование программного обеспечения» состоит в том, чтобы определить общую модель тестирования программного обеспечения, которую может использовать любая организация при выполнении любых форм тестирования программного обеспечения. Она включает в себя описания процессов тестирования, которые определяют процессы

IV

ГОСТ Р 56921-2016

тестирования программного обеспечения на организационном уровне, уровне менеджмента тестирования и уровнях динамического тестирования. Кроме того, представлены вспомогательные информативные схемы, описывающие процессы. ИСО/МЭК/ИИЭР 29119 охватывает динамическое тестирование, функциональное и нефункциональное тестирование, ручное и автоматизированное тестирование, тестирование, заданное сценарием, и тестирование без сценария. Процессы, определенные в данной серии международных стандартов, могут использоваться в сочетании с любой моделью жизненного цикла разработки программного обеспечения. Каждый процесс представлен с использованием общего шаблона процесса, определенного в ИСО/МЭК ТО 24774:2010 «Руководство по описанию процессов». Для каждого процесса тестирования определены цели, результаты, действия, задачи и информационные элементы.¹)

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

Концепции и словарь, используемые в данной серии международных стандартов, определены в ИСО/МЭК/ИИЭР 29119-1 «Понятия и определения». Шаблоны и примеры документации тестирования, которая создается в ходе процесса тестирования, определены в ИСО/МЭК/ИИЭР 29119-3 «Документация тестирования». Методы тестирования программного обеспечения, которые могут использоваться в ходе тестирования, определены в ИСО/МЭК/ИИЭР 29119-4 «Методики тестирования».

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

¹¹ Следует обратить внимание на то, что заглавные буквы используются в настоящем стандарте в названиях процессов и документов, которые определены в ИСО/МЭК/ИИЭР 29119-1 и ИСО/МЭК/ИИЭР 29119-3 (например, Процесс Планирования Тестирования, План Тестирования), тогда как строчные буквы используются для документов, являющихся частями других документов (например, стратегия тестирования проекта — элемент Плана Тестирования Проекта).

V

ГОСТ Р 56921-2016/ ISO/IEC/IEEE 29119-2:2013

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ Тестирование программного обеспечения Часть 2 Процессы тестирования

Software and systems engineering. Software testing. Part 2.Test processes

Дата введения — 2017—06—01

1    Область применения

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

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

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

2    Соответствие

2.1    Предполагаемое соответствие

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

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

2.1.1    Полное соответствие

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

2.1.2    Адаптированное соответствие

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

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

Издание официальное

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

Пример — Если организация придерживается соответствия процессов менеджмента информационных элементов стандартам, таким как ИСО 15489 «Информация и документация. Менеджмент записей» или ИСО 9001 «Система менеджмента качества. Требования», или использует подобные внутренние организационные процессы, то организация может решить использовать те же процессы и для решения задач менеджмента информационных элементов вместо процессов, определенных в настоящем стандарте.

3    Нормативные ссылки

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

ИСО/МЭК/ИИЭР 29119-1 Системная и программная инженерия. Тестирование программного обеспечения. Часть 1. Понятия и определения (ISO/IEC/IEEE 29119-1, Software and systems engineering — Software testing — Part 1 :Concepts and definitions)

ИСО/МЭК/ИИЭР 29119-3 Системная и программная инженерия. Тестирование программного обеспечения. Часть 3. Документация тестирования (ISO/IEC/IEEE 29119-3, Software and systems engineering — Software testing — Part 3:Test documentation)

ИСО/МЭК/ИИЭР 29119-4 Системная и программная инженерия. Тестирование программного обеспечения. Часть 4. Методики тестирования¹) (ISO/IEC/IEEE 29119-4, Software and systems engineering — Software testing — Part 4: Test techniques)

ИСО/МЭК 12207:2008 Системная и программная инженерия. Процессы жизненного цикла программного обеспечения (ISO/IEC 12207:2008, Systems and software engineering — Software life cycle processes)

Другие стандарты, полезные для реализации и интерпретации этого документа, перечислены в элементе «Библиография».

4    Термины и определения

В настоящем стандарте применяют термины по ИСО/МЭК/ИИЭР 24765, а также следующие термины с соответствующими определениями.

Примечание — В настоящем стандарте приводятся термины, используемые для простоты цитирования. Для соответствия настоящему стандарту не требуется обязательное их применение. Нижеследующий список терминов и определений представлен для обеспечения правильного понимания и удобочитаемости настоящего стандарта. В него включены только критически важные для понимания настоящего стандарта термины. Полный список терминов тестирования не является целью данного раздела. Для терминов, не определенных в этом разделе, следует пользоваться словарем системной и программной инженерии ИСО/МЭК/ИИЭР 24765. Он доступен на веб-сайте: http://www.computer.org/sevocab. Все термины, определенные в данном разделе, также преднамеренно включены в ИСО/МЭК/ИИЭР 29119-1, поскольку в этот стандарт входят все термины, использованные в частях 1,2,3 и 4 серии стандартов ИСО/МЭК/ИИЭР 29119.

4.1    фактические результаты (actual results): Совокупность поведения или условий элемента тестирования, или совокупность условий, связанных данных или тестовой среды, полученные в результате выполнения теста.

Пример — Вывод на экран, вывод на аппаратные средства, изменения в данных, отчеты и отправленные информационные сообщения.

4.2    критерии завершения (completion criteria): Условия, при которых действия тестирования считают завершенными.

4.3    элемент покрытия (coverage item): См. термин «элемент тестового покрытия» согласно 4.33.

4.4    динамическое тестирование (dynamic testing): Тестирование, которое требует выполнения кода программы.

¹¹ Будет опубликован в ближайшем будущем.

ГОСТ Р 56921-2016

4.5    раздел эквивалентности (equivalence partition): Подмножество области значений переменной или совокупности переменных внутри элемента тестирования или на его интерфейсах, такое, что можно обоснованно ожидать, что все значения подмножества будут обработаны элементом тестирования подобным образом (т. е. они могут считаться «эквивалентными»),

4.6    покрытие раздела эквивалентности (equivalence partition coverage): Доля идентифицированных разделов эквивалентности элемента тестирования, которая покрывается набором тестов.

Примечание — В большинстве случаев идентификация разделов эквивалентности субъективна (особенно в разбиении «недопустимых» разделов); таким образом, окончательный подсчет числа разделов эквивалентности для элемента тестирования может быть невозможен.

4.7    разбиение эквивалентности (equivalence partitioning): Метод проектирования тестирования, при котором контрольные примеры разработаны таким образом, чтобы проверить разделы эквивалентности с помощью одного или более представительных элементов каждого раздела.

4.8    ожидаемый результат (expected result): Характерное предсказанное поведение элемента тестирования при указанных условиях на основе его спецификации или другого источника.

4.9    исследовательское тестирование (exploratory testing): Тестирование, основанное на опыте, при котором тестер спонтанно разрабатывает и выполняет тестирования на основе существующих соответствующих знаний тестера, предшествующих исследований элемента тестирования (включая и результаты предыдущих тестирований) и эвристических «эмпирических правил» для общего поведения программного обеспечения и типов отказа.

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

4.10    набор функций (feature set): Логическое подмножество элемента(ов) тестирования, которое может быть обработано независимо от других наборов функций в последующих действиях проекта тестирования.

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

4.11    Отчет об Инциденте (Incident Report): Документация по инциденту о его проявлении, природе и состоянии.

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

4.12    тестирование производительности (performance testing): Тип тестирования, проводимого для оценки степени, в которой элемент тестирования выполняет свои определенные функции при заданных ограничениях времени и других ресурсах.

4.13    Организационный Процесс Тестирования (Organizational Test Process): Процесс тестирования для разработки и управления организационными спецификациями тестирования.

4.14    Организационная Политика Тестирования (Organizational Test Policy): См. «Политика Тестирования» согласно 4.55.

4.15    Организационная Спецификация Тестирования (Organizational Test Specification): Документ, в котором представлена информация о тестировании для организации, т. е. информация, которая не специфична для проекта.

Пример — Наиболее общими примерами Организационной Спецификации Тестирования являются Организационная Политика Тестирования и Организационная Стратегия Тестирования.

4.16    Организационная Стратегия Тестирования (Organizational Test Strategy): Документ, в котором изложены универсальные требования к тестированиям, которые будут выполняться для всех проектов организации, а также подробности того, как следует проводить тестирование.

Примечания

1    Организационная Стратегия Тестирования согласована с Организационной Политикой тестирования.

2    Для покрытия существенно различных контекстов проектов у организации может быть более одной Организационной Стратегии Тестирования.

3

4.17    риск продукта (product risk): Риск того, что продукт может иметь дефект в некотором определенном аспекте его функций, качества или структуры.

4.18    риск проекта (project risk): Риск, относящийся к менеджменту проекта.

Пример — Отсутствие укомплектования персоналом, строгие крайние сроки, изменения требований.

4.19    регрессионное тестирование (regression testing): Тестирование после изменений элемента тестирования или его рабочей среды для определения того, происходят ли регрессионные отказы.

Примечание — Достаточное количество регрессионных тестов зависит от тестируемого элемента и изменений этого элемента или его рабочей среды.

4.20    повторное тестирование (retesting): Повторное выполнение контрольных примеров, для которых ранее был получен результат «сбоя», для оценки эффективности произведенных корректирующих действий.

Примечания

1    Повторное тестирование часто сочетается с регрессионным тестированием.

2    Используется также термин «тестирование подтверждения».

4.21    тестирование на базе рисков (risk-based testing): Тестирование, для которого менеджмент, выбор, расстановка приоритетов и использование действий и ресурсов тестирования преднамеренно основаны на базе проанализированных рисков соответствующих типов и уровней.

4.22    тестирование защищенности (security testing): Тип тестирования, проводимый для оценки степени защищенности элемента тестирования и связанных с ним данных и информации от доступа посторонних лиц или систем для использования, чтения или изменения их при том, что доверенным лицам или системам доступ к ним обеспечивается.

4.23    тестирование по сценарию (scripted testing): Тестирование, выполняемое на основе задокументированного сценария.

Примечание — Этот термин обычно применяется для тестирования, выполняемого вручную, а не для выполнения автоматизированного сценария.

4.24    статическое тестирование (static testing): Тестирование, при котором элемент тестирования анализируется с использованием совокупности критериев качества или других свойств без выполнения кода.

Пример — Ревизия, статический анализ.

4.25    стрессовое тестирование (stress testing): Тип тестирования уровня производительности, проводимого для оценки поведения элемента тестирования при условиях загрузки выше ожидаемой или указанной в требованиях к производительности, или при доступности ресурсов ниже минимальной, указанной в требованиях.

4.26    базис тестирования (test basis): Свод знаний, используемых в качестве базы проекта тестирования и контрольных примеров.

Примечания

1    Базис тестирования может иметь форму документов, таких как спецификация требований, спецификация проекта или спецификация модуля, но может также представлять собой недокументированное понимание требуемого поведения.

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

4.27    контрольный пример (test case): Совокупность предварительных условий контрольного примера, входы (включая действия, где это применимо) и ожидаемые результаты, разработанная для управления выполнением элемента тестирования для достижения целей тестирования, включая корректную реализацию, идентификацию ошибок, проверку качества и получение другой значимой информации.

Примечание — Контрольный пример — это самый низкий уровень входа тестирования (т. е. контрольные примеры не состоят из других контрольных примеров).

ГОСТ P 56921—2016

4.28    Спецификация Контрольного Примера (Test Case Specification): Документация одного или большего количества контрольных примеров.

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

4.30    Отчет о Завершении Тестирования (Test Completion Report): Отчет, в котором представлена сводка выполненного тестирования.

4.31    тестовое условие (test condition): Тестируемый аспект компонента или системы, такой как функция, транзакция, функция, атрибут качества или структурный элемент, идентифицированные как базис тестирования.

Примечание — Тестовые условия могут быть использованы для получения элементов покрытия или же могут сами по себе образовывать элементы покрытия.

4.32    тестовое покрытие (test coverage): Степень, выраженная в процентах, в которой специфицированные элементы тестового покрытия были проверены контрольным(и) примером(ами).

4.33    элемент тестового покрытия (test coverage item): Атрибут или комбинация атрибутов, которые являются производными одного или более тестовых условий, полученными посредством методики проектирования тестирования, которая позволяет оценить основательность выполнения теста.

4.34    тестовые данные (test data): Созданные или отобранные данные, удовлетворяющие входным требованиям для выполнения одного или более контрольных примеров, которые могут быть определены в плане тестирования, контрольном примере или процедуре тестирования.

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

4.35    Отчет о Готовности Тестовых Данных (Test Data Readiness Report): Документ, описывающий состояние каждого требования к тестовым данным.

4.36    Процесс Разработки и Реализации Тестирования (Test Design and Implementation Process): Процесс тестирования для получения и определения контрольных примеров и процедур тестирования.

4.37    Спецификация Проекта Тестирования (Test Design Specification): Документ, определяющий функции, которые будут проверены, и соответствующие тестовые условия.

4.38    методика проектирования тестирования (test design technique): Действия, понятия, процессы и шаблоны, необходимые для создания модели тестирования, которая используется для определения тестовых условий для элемента тестирования, для получения соответствующих элементов тестового покрытия, а далее для разработки или выбора контрольных примеров.

4.39    тестовая среда (test environment): Различные средства, аппаратное и программное обеспечение, встроенное микропрограммное обеспечение, процедуры и документация, предназначенные или используемые для выполнения тестирования программного обеспечения.

4.40    Отчет о Готовности Тестовой Среды (Test Environment Readiness Report): Документ, который описывает состояние каждого требования к среде.

4.41    Требования к Тестовой Среде (Test Environment Requirements): Описание необходимых свойств тестовой среды.

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

4.42    Процесс Установки Тестовой Среды (Test Environment Set-up Process): Процесс динамического тестирования для установки и поддержания требуемой тестовой среды.

4.43    выполнение теста (test execution): Процесс выполнения теста на элементе тестирования, приводящий к фактическим результатам.

4.44    Журнал Выполнения Теста (Test Execution Log): Документ, в который записываются детали выполнения одной или более процедур тестирования.

4.45    Процесс Выполнения Теста (Test Execution Process): Процесс динамического тестирования для выполнения процедур тестирования, созданных в процессе разработки и реализации тестирования в подготовленной тестовой среде, и записи результатов.

5