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

Приложение E

(справочное)

ОРГАНИЗАЦИОННАЯ СТРАТЕГИЯ ТЕСТИРОВАНИЯ

E.1 Пример 1 - Корпорация Agile

Корпорация Agile - большая организация, осуществляющая публикацию журналов и книг. Более подробно она представлена в C.1 (приложение C).

Организационная Стратегия Тестирования корпорации Agile, V1.1 (03/23/2009).

Разработано: Урсула Мейерс, ответственный разработчик.

Утверждено: Стефан Блэксмит, глава отдела качества.

Оформляющая организация: За подготовку Организационной Стратегии Тестирования в корпорации Agile ответственен руководитель тестирования. Высшее руководство корпорации Agile ответственно за анализ, утверждение и распространение Организационной Стратегии Тестирования.

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

Ссылки: Манифест динамичной разработки (Agile Manifesto).

Общий менеджмент рисков: Менеджмент всех рисков должен соответствовать предписанному корпоративному Процессу Менеджмента Рисков, как это определено в Корпоративной Политике-RM56, где идентифицирован общий реестр рисков. Любые отклонения и исключения должны быть утверждены высшим руководством.

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

Организационная структура тестирования: Организация тестирования корпорации Agile имеет пул независимых профессионалов тестирования, из которого тестеры назначаются в динамичные команды, например, в команды Scrum, где они являются полноправными членами.

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

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

│ Руководитель тестирования │

│ (1 человек) │

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

│

\/ ┌────────────────────────┐

┌───────────────────────┐ │ Администраторы │

│ Тестеры ├────>│ тестовой среды │

│ (21 человек) │ │ (5 человек) │

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

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

E.2 Пример 2 - Traditional Ltd

Traditional Ltd - небольшая компания, которая производит передовое аналитическое оборудование для сельскохозяйственной промышленности. Более подробно она представлена в C.1 (приложение C).

У Traditional Ltd есть Организационная Стратегия Тестирования, разделенная на части для проекта в целом и для каждого подпроцесса тестирования. В этот пример включены часть для проекта в целом, части для тестирования компонентов и тестирования системы.

Организационная Стратегия Тестирования

&Организационная Стратегия Тестирования&
Проблема	Стратегия
Общий менеджмент рисков	Менеджмент рисков в проекте должен опираться на общий реестр рисков для проекта конкретного типа и процесс общего менеджмента рисков. Реестры рисков размещены в XX. Когда проект закрывается, соответствующий общий реестр(ы) рисков должен быть обновлен надлежащим образом
Выбор тестирования и приоритетов	Для контрольных примеров и процедур тестирования должны быть выбраны приоритеты, соответствующие риску, связанному с требованиями, покрывающими примеры. Если в процедуру тестирования входят контрольные примеры с различными уровнями рисков, контрольный пример с высшим уровнем определяет уровень риска для всей процедуры. Выполнение процедур тестирования всегда должно планироваться соответственно риску таким образом, чтобы чем выше был риск, тем раньше выполнялась процедура. Необходимо, чтобы каждый набор функций покрывался каким-либо тестированием, то есть тестирование, не проверяющее какой-либо набор функций, должно быть исключено из графика
Документация тестирования и создание отчетов	Тестовые проекты должны быть документированы таким образом, чтобы аудит мог установить, что было запланировано и что было выполнено. Важна трассировка между артефактами. На уровне проекта тестирования должны быть разработаны План Тестирования проекта и Отчет о Завершении Тестирования проекта, как это определено в ИСО/МЭК/ИИЭР 29119-3
Автоматизация и инструменты тестирования	Во всех проектах и для всех подпроцессов тестирования должен использоваться инструмент управления тестированием BCG. В случаях, когда планируется больше четырех регрессионных тестов, в проекте можно рассмотреть возможность использования инструмента тестирования сбора/воспроизведения
Менеджмент конфигурации рабочих продуктов тестирования	Процесс менеджмента конфигурации Traditional Ltd должен поддерживаться для всех рабочих продуктов тестирования
Управление инцидентами	Необходима поддержка процесса управления инцидентами Traditional Ltd
Подпроцессы тестирования	Каждый проект тестирования должен включать следующие подпроцессы тестирования: - тест производительности, если применимо в соответствии с требованиями; - тестирование управляемости; - покомпонентное тестирование; - тестирование интеграции компонентов, предпочтительно снизу доверху; - тестирование системы
Критерии входа и выхода	Перед началом тестирования системы должны быть утверждены Отчет о завершении интеграционного теста и спецификация тестирования системы. Все практические результаты тестирования системы должны быть утверждены перед завершением тестирования системы
Критерии завершения тестирования	Тестирование системы должно достичь 100% покрытия требований, и все процедуры тестирования должны быть выполнены без инцидентов
Документация тестирования	План Тестирования системы, Отчет о Завершении Тестирования системы и все документы, определенные для динамического тестирования, должны быть созданы в соответствии с настоящим стандартом
Степень независимости	Тестирование системы должно быть определено персоналом подразделения тестирования и выполнено студентами
Методы проектирования тестирования	Для разработки контрольных примеров необходимо использовать надлежащие методы черного ящика. Если имеется информация о дефектах предыдущих версий, то можно использовать предположение об ошибках
Тестовая среда	Среда тестирования системы должна быть идентична рабочей среде с точки зрения аппаратного и программного обеспечения. В случае встроенных систем тестирование системы может быть выполнено на средстве моделирования. Данные могут быть сделаны анонимными, но во всем остальном они должны на 100% представлять реальные данные
Требуемые метрики	В отчете о завершении тестирования системы должно быть указано: - общее количество конкретных процедур тестирования; - общее количество выполненных процедур тестирования; - общее количество часов, потраченных на тестирование по спецификации; - общее количество часов, затраченных на выявление и регистрацию инцидентов; - общее количество часов, затраченных на тестирование; - общее количество обнаруженных отказов
Повторное тестирование и регрессионное тестирование	Все процедуры тестирования, приводящие к инциденту, должны быть повторно выполнены после коррекции дефектов. Регрессионное тестирование в ходе подпроцесса тестирования системы производится по усмотрению менеджера по тестированию. В заключительном тестировании системы должны быть выполнены все процедуры тестирования
Критерии входа и выхода	Перед выполнением покомпонентного тестирования элемент тестирования (компонент) должен быть скомпилирован и связан, а спецификация тестирования компонентов должна быть утверждена. Все практические результаты покомпонентного тестирования должны быть утверждены до завершения тестирования компонентов
Критерии завершения тестирования	Тестирование каждого компонента должно обеспечить, по крайней мере, 90% покрытия операторов и не менее 80% покрытия результатов, и все контрольные примеры для компонента должны быть выполнены без инцидентов. О причине несоответствий необходимо доложить менеджеру проекта, который должен это отметить
Документация тестирования	Должны быть созданы план покомпонентного тестирования и Отчет о завершении покомпонентного тестирования в соответствии с настоящим стандартом. Для каждого компонента с целью обеспечения покрытия должны быть произведены контрольные примеры
Степень независимости	Покомпонентное тестирование должно быть определено и выполнено как равноправное тестирование, то есть это должно быть выполнено разработчиком, который не является автором кодирования тестируемого компонента
Методы проектирования тестирования	Должны использоваться надлежащие методы черного ящика для проектирования тестирования, дополненные методом белого ящика: тестирование операторов и тестирование, по необходимости, результата решения для обеспечения требуемого покрытия
Тестовая среда	Покомпонентное тестирование может быть выполнено в среде разработки разработчика тестирования, но не в среде разработчика, который кодировал тестируемый компонент
Требуемые метрики	В отчете о завершении покомпонентного тестирования должно быть указано: - среднее полученное покрытие операторов; - среднее полученное покрытие решений; - общее количество инцидентов, найденных и исправленных
Повторное тестирование и регрессионное тестирование	Каждый компонент должен тестироваться повторно до тех пор, пока не были достигнуты критерии завершения