ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013 Системная и программная инженерия. Тестирование программного обеспечения. Часть 1. Понятия и определения
5.2 Тестирование программного обеспечения в организационном контексте и контексте проекта
Компании, вовлеченные в разработку или приобретение программных продуктов, заинтересованы в разработке и использовании эффективных, действенных и повторимых процессов. Для осуществления этого компании разрабатывают полноценный набор процессов жизненного цикла программного обеспечения, используемых в проектах выполняемых ими разработок. Настоящий стандарт предназначен как для использования в организации в целом, так и для применения в отдельных проектах. Организация может принять настоящий стандарт и дополнить его по мере необходимости дополнительными процедурами, методами, инструментами и политиками. Конкретный проект разработки программного обеспечения или системы, выполняемый организацией, как правило, соответствует процессам организации, а не соответствует напрямую настоящему стандарту. В отдельных случаях проект может выполняться организацией, которая не располагает надлежащей совокупностью процессов организации. Такой проект может непосредственно применить положения настоящего стандарта.
Для любой производящей программное обеспечение организации, будь ею многонациональная организация с тысячью тестеров или компания из одного человека, обязательства по тестированию программного обеспечения должен нести высший уровень организационного менеджмента, будь то генеральный директор, открытый руководящий комитет или начальник отдела. Желательно, чтобы эти обязательства были заложены в Организационную Политику Тестирования и в одну или более Организационные Стратегии Тестирования, служащие основой для всех выполняемых в организации видов тестирования программного обеспечения. Политики Тестирования и Организационные Стратегии Тестирования обычно присутствуют в наиболее развитых организациях. В организациях менее зрелых тестирование может выполняться и выполняется без формальных политик тестирования и организационных стратегий тестирования, но такая практика не обеспечивает обоснованности тестирования в организации и, как правило, показывает меньшую эффективность и результативность тестирования, выполняемого в проектах.
Тестирование программного обеспечения выполняется как управляемый контекстом процесс. Это означает, что процесс нужно планировать, контролировать и им нужно управлять. Контекстом тестирования может быть как проект разработки (в пределах от многочисленного, многолетнего формального проекта разработки до неофициальной разработки, требующей нескольких часов работы одного человека), так и текущее сопровождение функционирующей системы. Необходимо отметить некоторые положения контекста тестирования: полный бюджет; требования расписания; риск; организационная культура; ожидания потребителя/пользователя; готовность сред инфраструктуры для тестирования; область применения проекта; критичность проекта и т.д. Накопленный опыт отрасли показывает, что ни одна стратегия тестирования, ни один план, метод или процесс не будут работать во всех ситуациях. Следовательно, организации и проекты должны адаптироваться и совершенствоваться в деталях тестирования, опираясь на стандарты, такие как настоящий стандарт.
Полный план проекта должен включать в себя анализ тестирующих действий, которые будут выполняться как часть проекта. В Плане Тестирования Проекта должны быть отражены как Организационная Политика Тестирования и Организационная Стратегия Тестирования, так и отклонения от этих организационных руководств. Кроме того, в плане должны быть учтены ограничения, заданные в полном плане проекта. План Тестирования Проекта включает в себя стратегию тестирования проекта и специфичные, используемые для выработки стратегии решения проекта (включая предположения). Основной элемент планирования тестирования - это оценка различных нужд тестирования и балансировка ресурсов между различными тестированиями. План тестирования фиксирует результат этого анализа. В соответствии с настоящим стандартом в основу метода определения потребностей тестирования закладывается риск (см. 5.4), однако в стратегию также могут быть включены и другие методики тестирования, описанные в 5.6.
Для всего проекта тестирование осуществляется часто через некоторое множество подпроцессов тестирования, каждый из которых может иметь соответствующий План Тестирования (План Подпроцесса Тестирования, например План Тестирования Системы или План Теста Производительности), включающий в себя как стратегию подпроцесса тестирования, согласованную со стратегией тестирования проекта, так и специфические детали подпроцесса тестирования.
На рисунке 1 показано, как тестирование вписывается в иерархический контекст. Тестирование базируется на статусе регулирования, присущем организации (если регулирование имеет место). Упомянутый контекст состоит из законов, инструкций и промышленных стандартов. В соответствии с нормативной ситуацией организация разрабатывает необходимые политики и процедуры, требуемые для успешной работы. Организационная Политика Тестирования работает на этом уровне. Каждый проект организации реализуется для соответствия некоторому требованию или возможности, которые идентифицированы организацией. Контекст проекта помогает определить, какую модель жизненного цикла выбрать. На этом уровне на основе контекста проекта и модели жизненного цикла определяется стратегия тестирования. План проекта и стратегия тестирования формируют базу для Плана Тестирования Проекта.
План Тестирования Проекта описывает общую стратегию тестирования и процессы тестирования, которые будут использоваться. Он устанавливает контекст тестирования проекта, определяя цели, методы, ресурсы и расписание. Кроме того, он идентифицирует применимые подпроцессы тестирования (например, тестирование системы, тестирование производительности). Идентифицированные подпроцессы далее расписываются в плане тестирования подпроцесса (например, План Тестирования Системы, План Теста Производительности). План тестирования также определяет надлежащий метод проектирования тестирования (статическое или динамическое), необходимый для выполнения подпроцесса тестирования, требуемого конкретным планом. Более подробно методы проектирования тестирования описаны в 5.5.6 и ИСО/МЭК/ИИЭР 29119-4.
Рисунок 1 - Иерархическая схема тестирования
Каждый план тестирования подпроцесса может относиться более чем к одному уровню тестирования (например, план тестирования защищенности может относиться к нескольким уровням тестирования), а кроме того, может относиться к более чем одному типу тестирования (например, План Тестирования Системы, который относится к тестированию функциональности и тестированию производительности на уровне тестирования системы). План тестирования подпроцесса также определяет стратегию выполнения теста (например, по сценарию, без сценария или смесь того и другого).
План тестирования включает в себя стратегию тестирования (см. раздел 6). Стратегии тестирования настраиваются на конкретный контекст проекта тестирования. Стратегии тестирования должны соотноситься конкретными элементами, показанными на рисунке 1 и определенными в других частях серии стандартов ИСО/МЭК/ИИЭР 29119. Каждый план тестирования (и стратегия) будет уникален, отличаясь от других: подпроцессами тестирования, уровнями автоматизации, совокупностью методик проектирования тестирования, критериями завершения теста, их планированием и выделением ресурсов. Планирование и выбор этих аспектов начинаются на ранней стадии проекта и будут продолжаться в течение жизненного цикла тестирования, влияя как фактор на изменение риска. Следует ожидать, что многие части плана и стратегии тестирования изменятся, хотя изменения будут, очевидно, в пределах ограничений проекта, организации или регулирующих норм.
Взаимосвязи между общим процессом тестирования, общими подпроцессами тестирования, уровнями/фазами тестирования и типами тестирования более подробно показаны на рисунке 2. Рисунок показывает реализацию общих подпроцессов тестирования на определенных уровнях тестирования и в соответствии с типом тестирования. Общий подпроцесс тестирования может быть реализован:
- на уровне или фазе тестирования. То есть каждый уровень тестирования представляет собой определенное приложение общего подпроцесса тестирования (например, фаза покомпонентного тестирования, уровень приемочного испытания);
Рисунок 2 - Взаимосвязи между общим подпроцессом тестирования, уровнями тестирования и типами тестирования
- как тестирование определенного типа. То есть каждый тип тестирования представляет собой определенное приложение общего подпроцесса тестирования (например, тестирование производительности, тестирование удобства использования);
- подпроцесс тестирования, соответствующий уровню тестирования, может включать в себя больше одного подпроцесса разного типа тестирования (например, функциональный и тестирование производительности являются частями тестирования системы);
- процесс тестирования проекта может состоять из последовательности подпроцессов тестирования (например, тестирование компонента, интеграционное тестирование, тестирование системы и подпроцессы тестирования приемочных испытаний).
На рисунке 2 в деталях показаны связи между типами тестирования и показателями качества (как определено в ИСО/МЭК 25010 "Модели качества систем и программного обеспечения"). Каждый тип тестирования ориентирован на один определенный показатель качества. Более подробно связи между типами тестирования и показателями качества рассматриваются в 5.5.3.
5.2.1 Процесс тестирования
В настоящем стандарте используется трехуровневая модель процесса, подробно описанная в ИСО/МЭК/ИИЭР 29119-2 и показанная в общем виде на рисунке 3. Модель процесса начинается с организационного управления спецификациями тестирования высокого уровня (организационными спецификациями), такими как Организационная Политика Тестирования и Организационная Стратегия Тестирования. Средний уровень показывает менеджмент тестирования (менеджмент тестирования проекта, менеджмент фазы тестирования, менеджмент типа тестирования), в то время как нижний уровень определяет множество процессов тестирования, используемых в динамическом тестировании.