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

5.2. Тестирование программного обеспечения в организационном контексте и контексте проекта

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

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

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

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

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

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

 

 

Рисунок 1 - Иерархическая схема тестирования

 

План Тестирования Проекта описывает общую стратегию тестирования и процессы тестирования, которые будут использоваться. Он устанавливает контекст тестирования проекта, определяя цели, методы, ресурсы и расписание. Кроме того, он идентифицирует применимые подпроцессы тестирования (например, тестирование системы, тестирование производительности). Идентифицированные подпроцессы далее расписываются в плане тестирования подпроцесса (например, План Тестирования Системы, План Теста Производительности). План тестирования также определяет надлежащий метод проектирования тестирования (статическое или динамическое), необходимый для выполнения подпроцесса тестирования, требуемого конкретным планом. Более подробно методы проектирования тестирования описаны в 5.5.6 и ИСО/МЭК/ИИЭР 29119-4.

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

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

Взаимосвязи между общим процессом тестирования, общими подпроцессами тестирования, уровнями/фазами тестирования и типами тестирования более подробно показаны на рисунке 2. Рисунок показывает реализацию общих подпроцессов тестирования на определенных уровнях тестирования и в соответствии с типом тестирования. Общий подпроцесс тестирования может быть реализован:

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

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

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

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

 

 

Рисунок 2 - Взаимосвязи между общим подпроцессом

тестирования, уровнями тестирования и типами тестирования

 

На рисунке 2 в деталях показаны связи между типами тестирования и показателями качества (как определено в ИСО/МЭК 25010 "Модели качества систем и программного обеспечения"). Каждый тип тестирования ориентирован на один определенный показатель качества. Более подробно связи между типами тестирования и показателями качества рассматриваются в 5.5.3.

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

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

 

 

Рисунок 3 - Многоуровневая связь процессов тестирования

 

Трехуровневая модель процесса показана на рисунке 3.

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

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

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

Процессы Менеджмента Тестирования показаны на рисунке 4.

 

 

Рисунок 4 - Процессы Менеджмента Тестирования

 

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

В подпроцессы тестирования может входить как статическое тестирование, так и динамическое тестирование. Процессы динамического тестирования показаны в общих чертах на рисунке 5 и полностью описаны в ИСО/МЭК/ИИЭР 29119-2. Процессы статического тестирования описаны в других опубликованных стандартах, например ИИЭР 1028.

 

 

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

 

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