Одним из инструментов управления проектами является матрица отслеживания требований (на английском – Requirements Traceability Matrix или просто RTM), вот о ней давайте сегодня и поговорим. Трассировкаобеспечивает полноту тестирования иподготавливает основу для планированиятестов. Матрица трассировки может бытьсамостоятельным документом или можетбыть включена как часть документациипо требованиям или часть планатестирования. Матрицасоответствия требований- это двумерная таблица, содержащаясоответсвие функциональных требований(functional requirements) продукта и подготовленныхтестовых сценариев (test cases).

Использование И Построение Матрицы Трассировки Тестирования С Помощью Инструментов Сфера

Кстати, когда-то давно в блоге даже был гостевой пост от читательницы, сдавшей экзамен по BABOK, почитать можно тут. # Функциональные требования — идентификационный номер функционального требования (в соответствии с документацией по требованиям), которое исполняет указанное бизнес-требование. Верхняяправая часть матрицы (над диагональювключительно) не используется. Оставшиесяячейки указывают https://deveducation.com/ на то, перекрываютсяли два любых требования, противоречатдруг другу или независимы друг от друга(пустые ячейки).

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

Формализациявключаетв себя определение компонентов системыи их состояний; правил взаимодействиякомпонентов и определения условий вформальном виде, которые должнывыполняться при изменении состоянийкомпонентов. Посмотреть на все многообразие артефактов и понять, обо что больше всего людей спотыкается. Нельзя сказать, что надо обязательно начинать с consumer story или с use case. У вас вообще может не быть user story или use case или вы не документируете API.

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

Это могут быть use case, замаппленные на тест-кейсы, или бизнес-объекты, замаппленные на use case, или use case на use case. В одном из проектов мы использовали трассировку через матрицу, где бизнес-объекты в мастер-системах были замапплены на бизнес-объекты в слэйв-системах. Таким образом мы видели, какая система мастер по такому-то объекту, а какие системы – слейв по этому объекту.

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

• Она создается за счет связывания бизнес-требований с вариантами использования и сценариями тестирования, которые будут использоваться для их проверки.
• Год назад на конференции “Игра в анализ” я подробно рассказывал о значимости и особенностях трассировки требований в проекте.
• В каждом компоненте есть какой-то набор функций, и мы можем эти функции маппировать на компоненты.
• Далее по каждой фиче мы можем посмотреть связанные с ней задачи.
• Матрица трассировки воспринимается как очень сложный в обращении артефакт.

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

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

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

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

Если «звездолет» уже есть, но непонятно, как он работает, то надо начинать по кусочкам приводить его в порядок. Сейчас у нас век микросервисов, сервисов, компонентно-ориентированных систем. Нельзя сказать, что монолиты уйдут из нашей жизни навсегда, но фокус с них смещается на другие варианты архитектуры. В каждом компоненте есть какой-то набор функций, и мы можем эти функции маппировать на компоненты. Это тоже один из вариантов применения связи двух реестров артефактов. Далее по каждой фиче мы можем посмотреть связанные с ней задачи.

(отангл.Traceability, Trace- хвост,ability– способность).Прослеживаемзависимости (хвосты) между требованиямии тестами. К ним относятся Sparx Enterprise Architect, Confluence Atlassian + плагин Requirement Yogi, Jama, IBM Telelogic DOORS, IBM Rational RequisitePro, Техэксперт, и другие. По Requirement Yogi я ранее делал доклад, можно посмотреть его тут. Во-вторых, это, по факту, самый простой способ поверх Confluence наладить трассировку требований.