матрица трассируемости что это

Матрица трассабилити

Когда требования на проекте меняются “на лету” и у вас нет под рукой средства контроля за реализацией каждого отдельного требования по фиче или модулю, перед вами встает вопрос: как проводить анализ покрытия? Одним из таких инструментов, который использует наша команда QA на подобных проектах — матрица трассируемости (traceability matrix).

На данный момент мы используем матрицы более 2,5 лет. За это время мы смогли оценить преимущества этого инструмента, а также адаптировать его под наш проект.

Что же такое матрица трассируемости?

По определению матрица трассируемости — двумерная таблица, содержащая соответствие функциональных требований продукта (functional requirements) и подготовленных тестовых сценариев (test cases).

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

Таким образом, таблица дает визуальное отображение двух параметров:

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

Поэтому матрица имеет вид таблицы, каждая строка которой содержит:

Так как мы используем таск трекер Jira, Zephyr by Jira для тестовой документации и систему управления требованиями Сonfluence, все сущности синхронизируются и такая трассируемость позволяет нам:

Варианты связей в матрице трассируемости

Привязка требования и тест-кейса может быть:

Специфика оценки покрытия с помощью матриц трассируемости

Если для оценки покрытия мы используем метрику “отношение количества требований к количеству тестовых артефактов”, то связи в матрице должны быть “1 к 1”, а требования максимально декомпозированы.

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

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

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

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

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

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

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

Создание и ведение матрицы

Создание матрицы включено в наш воркфлоу работы над задачами по аналитике.

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

И здесь можно выделить следующие этапы составления Traceability Matrix:

Сложности в работе с матрицей трассируемости

Если все QA-специалисты заняты тестированием приоритетных задач, мы переносим создание матрицы по конкретной фиче. Максимально он переносится на момент тестирования первой задачи по этой фиче и в таком случае матрица заполняется тест-кейсами по мере тестирования задач, в которых реализована фича.

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

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

Источник

Пример матрицы трассировки требований

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

Примеры картинок с трассировочными матрицами
Пример 1

Пример 2

Пример 3

Пример 4

Инструкции:
В соответствии с лучшими практиками, бизнес-требования следует декомпозировать до мельчайших пакетов и нумеровать в соответствии со следующими правилами нумерации: BR001, BR002 и т.д. Для каждого бизнес-требования будет одно или несколько функциональных требований, которые должны соответствовать соглашению по нумерации для соответствующего бизнес-требования: FR001.01, FR001.02, FR001.03, FR002 и т.д. Функциональные требования должны быть декомпозированы до мельчайших пакетов.

Для каждого функционального требования будет существовать одна или несколько связанных технических спецификаций, которые должны соответствовать соглашению по нумерации для связанных функциональных требований: TS001.01.01, TS001.01.02, TS001.01.03 и т.д. Технические спецификации должны быть декомпозированы до мельчайших пакетов.

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

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

# Бизнес-требования — номер бизнес-требования (в соответствии с документацией по требованиям), который идентифицирует критерии успеха, на основе которых будут выполняться тесты.

# Функциональные требования — идентификационный номер функционального требования (в соответствии с документацией по требованиям), которое исполняет указанное бизнес-требование.

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

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

Вы можете создать таблицу со следующими столбцами и строками:

Источник

Трассируемость требований

Содержание

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

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

Назначение

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

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

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

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

Разновидности

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

В более сложном случае, связь может принадлежать к одному из предопределенных фасетов (например «тестируется с помощью», «вытекает из», «является частью»). Таким образом увеличивается гибкость возможных выборок по связям между артефактами, однако, это происходит за счёт существенного усложнения модели. Очевидно, что использование второго подхода может быть оправдано только для крупных проектов со сложной структурой требований.

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

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

Инструментальная поддержка

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

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

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

К специализированным средствам управления требованиями, поддерживающим трассируемость, относятся, в частности, средства Borland Caliber, IBM Rational RequisitePro, (IBM) Telelogic DOORS, Sparx Enterprise Architect, 3SL Cradle,

В рамках проекта Eclipse инициировано создание Open Source Requirements Framework, предназначенного для создания модели управления требованиями, а также инструментов на её базе.

Источник

Матрица трассируемости требований

Наиболее типичный способ представления связей между требованиями и другими элементами системами — матрица трассируемости требований, которую также называют матрицей отслеживания требований или таблицей трассируемости(requirements traceability matrix) (Sommerville и Sawyer, 1997). В табл. 20-показана часть такой матрицы для Chemical Tracking System. Когда я раньше создавал такие матрицы, я делал копию базовой версии спецификации требований и удалял все, кроме идентификаторов функциональных требований. Затем я создавал таблицу, отформатированную так же, как табл. 20-1, и заполнял только столбец Функциональное требование. Далее мы постепенно заполняли пустые ячейки в матрице по мере разработки проекта.

Таблица 20-1. Один из типов матрицы трассируемости требований

Заполняйте информацию по мере выполнения работы, а не по мере планирования. То есть вводите «catalog.sort()» в столбец Модуль кода первой строки в табл. 20-1 только когда код в этой функции написан, прошел тестирование элементов и уже интегрирован с базовой версией исходного кода продукта. Таким образом, читающий матрицу будет знать, что заполненный ячейки матрицы для отслеживания требований указывают на работу, которая уже выполнена. Обратите внимание, что перечисление вариантов тестирования для каждого требования не указываетна то, что ПО протестировано. Это просто означает, что определенные тесты были написаны для проверки требований в соответствующее время. Трассирование состояния тестов— это отдельная проблема.

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

Рис. 20-3. Пример цепи трассируемости для требований, касающихся безопасности приложения

Связи трассируемости могут определить отношения «один к одному», «один ко многим» или «многие ко многим» между элементами системы. Формат в табл. 20-1 предусматривает это, позволяя вводить несколько позиций в каждой ячейке таблицы. Ниже приведены примеры возможных связей.

· «Один к одному»:один элемент проектирования реализуется в одном модуле кода.

· «Один ко многим»:одно функциональное требование проверяется множеством вариантов тестирования.

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

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

· один тип требования с другим требованием этого же типа;

· один тип требования с требованием другого типа;

· один тип требования с вариантами тестирования.

Вы можете использовать эти матрицы для определения различных взаимоотношений, возможными между парами требований, например «указывает/указан», «зависит от», «является родительским для» и «ограничивает/ограничен» (Sommerville и Sawyer, 1997).

В табл. 20-2 показана двусторонняя матрица трассируемости. Большинство ячеек матрицы не заполнены. Каждая ячейка на пересечении двух связанных компонентов помечена для указания соединения. Вы можете использовать различные символы в ячейках, чтобы явно определить «трассируется до» и «трассируется от» или другие взаимоотношения. В табл. 20-2 стрелка указывает, что данное функциональное; требование отслеживается от определенного варианта использования. Эти матрицы более поддаются автоматизации средствами поддержки, чем те, что показаны в табл. 20-1.

Таблица 20-2. Матрица для трассирования требований, показывающая связи между вариантами использования и функциональными требованиями

Вариант использования (ВИ)
Функциональное требование (ФТ)	ВИ-1	ВИ-2	ВИ-3	ВИ-4
ФТ-1
ФТ-2
ФТ-3
ФТ-4
ФТ-5.
ФТ-6

Связи трассируемости должны быть определены любым лицом, имеющим доступ к соответствующей информации. В табл. 20-3 определены некоторые стандартные источники информации о связях между различными типами исходных и целевых объектов. Определите роли и лиц, которые будут поддерживать каждый тип информации трассируемости для вашего проекта. Будьте готовы к тому, что занятые люди, которых аналитик или менеджер проекта попросит предоставить эти данные, будут отнекиваться. Этим специалистам стоит объяснить, что такое трассирование требований, чем оно ценно и почему именно этих специалистов просят внести вклад в процесс. Подчеркните, что увеличение затрат на фиксирование информации трассируемости во время выполнения невелики; в основном это вопрос привычки и дисциплины.

Таблица 20-3. Вероятные источники информации о связи трассируемости

Источник

Матрица трассируемости что это

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

Тестовое покрытие = покрытие тестами требований к продукту/системе, выраженное в численном либо процентном соотношении. Тестовое покрытие является одной из основных метрик качества продукта.
Иногда под тестовым покрытием имеют в виду покрытие критериев приёмки, покрытие кода, покрытие именно автотестами.
Тестовое покрытие говорит о добротности тестирования, о степени доверия к продукту, который мы делаем, о том где у нас есть «белые пятна» и выше риск проявления ошибки.

Процесс определения покрытия кратко картинкой:

Итак, вы прошли этап определения причастных сторон, ознакомились с документацией по Проекту, получили описание архитектуры Продукта/Системы, требования к ней, критерии приёмки.
Теперь надо определиться с объёмом тестирования и видами тестирования.

Матрица трассируемости требований (Requirement Traceability Matrix) = двумерная таблица, содержащая соответствие требований (user/business requirements, software requirements) и подготовленных тест-кейсов (test cases).
Основное её предназначение в отображении степени покрытия требований тест-кейсами.

В соответствии с лучшими практиками, Бизнес-Требования следует максимально декомпозировать и нумеровать в соответствии со следующим правилом: BR001, BR002 и т.д.
Для каждого Бизнес-Требования будет одно или несколько Функциональных Требований, которые должны соответствовать соглашению по нумерации для соответствующего бизнес-требования: FR001.01, FR001.02, FR001.03, FR002 и т.д. Функциональные требования также должны быть максимально декомпозированы.

Пример рабочего процесса, в котором присутствует создание Матрицы Трассировки:

Формат тест-кейса

Определение классов эквивалентности (Equivalence Partitioning)
и Анализ Граничных Значений (Boundary Value Analysis)

Попарное тестирование (Pairwise Testing)

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

Причина / Следствие (Cause/Effect)

Тестирование смены состояний (State Transition Testing)

Таблица решений (Decision Table Testing)

Способ компактного представления модели со сложной логикой. Устанавливает связь между условиями (входными параметрами) и результатом (действиями Системы). Определить/записать все условия. Просчитать возможное количество комбинаций условий. Заполнить комбинации. Записать действия. Убрать лишние комбинации.
Например:

Тестирование путей (Path Testing)

Однако, его же можно использовать для покрытия тестами логики тестируемой системы, если у нас имеются BPMN-диаграммы и UML activity-диаграммы, описывающие процессы, проходящие в ней.
Количество сценариев будет зависеть от количества логических узлов ветвлений. Если условия ветвлений зависят от значений каких-то данных, то скорее всего, для каждого тест-сценария необходимо, опираясь на диаграмму, определить набор входных данных.
Очень упрощённо:

Предугадывание ошибки (Error Guessing)

Это когда тест-аналитик/тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку. Например, спецификация говорит: «пользователь должен ввести код». Тест-аналитик, будет думать: «Что, если я не введу код?», «Что, если я введу неправильный код? «, и так далее. Это и есть предугадывание ошибки.

Исчерпывающее тестирование (Exhaustive Testing)

Источник