Маппинг через трассировку сильно облегчит нам поиск и понимание связей в дальнейшей работе. Трассировка требований – это способность соотнести какой-либо элемент проекта с другим связанным с проектом элементом, особенно с тем, который имеет отношение к техническим требованиям проекта. Один из его ключевых разделов – управление жизненным циклом требований (Requirements Life Cycle Management), в нем как матрица трассируемости раз есть подраздел про трассировку.
Одним из инструментов управления проектами является матрица отслеживания требований (на английском – Necessities Traceability Matrix или просто RTM), вот о ней давайте сегодня и поговорим. Трассировкаобеспечивает полноту тестирования иподготавливает основу для планированиятестов. Матрица трассировки может бытьсамостоятельным документом или можетбыть включена как часть документациипо требованиям или часть планатестирования. Матрицасоответствия требований- это двумерная таблица, содержащаясоответсвие функциональных требований(functional requirements) продукта и подготовленныхтестовых сценариев (test cases).
Среди полезных инструментов бизнес-аналитика – https://deveducation.com/ шаблон матрицы трассировки требований. С его помощью можно визуализировать связи между элементами системы в формате таблицы. Чем наполнить матрицу трассировки, вы решаете сами с проектной командой.
В реальности сложность обращения с матрицей вполне поддаётся управлению, в частности, ничто не мешает детализировать ее в процессе работы по проекту. Был опыт внедрения всеобщей трассировки, когда мы qa automation собеседование трассировали все на все. Это было довольно трудозатратно, но позволило быстро развить систему до крупного масштаба. То есть, когда у вас с нуля что-то создается, тогда всеобщую трассировку легко можно внедрить. Когда вы понимаете, что через какое-то время у вас будет огромный «звездолет», то лучше заложить подобную трассировку в самом начале.
Разработка Стратегий Формирование Системы Стратегических Целей Организации
- Лид проверяет репозитории, и если соответствующие тест-кейсы существуют, утверждает матрицу.
- Если требование состоит из нескольких частей, для каждой из них разрабатываются отдельные тесты.
- Документ представляет собой таблицу, колонки которой соответствуют артефактам (код, материалы), а в строках расположены идентификаторы элементов этих артефактов.
- Ошибка идет, похоже, от того, что на курсах тестировщиков матрицу трассировки слушателям “продают” как инструмент тестирования, поэтому если такое увидите – не верьте.
Их можно создавать вручную и использовать для этого Excel, Google Doc, Confluence, даже обычную доску с маркером. Рассмотрим ещё один пример, который больше относится к аналитике и непосредственно к требованиям. Основная его идея – связь двух реестров требований, когда есть артефакты первого реестра и артефакты второго реестра и нужно сделать между ними маппинг.
С точки зрениядисциплины это означает увеличениересурсов и длительности проекта. Этот пример знакомвсем со времени обучения в школе,техникуме, университете. Аинтересующая нас матрица трассировки— табель посещаемости занятий. Конкретныйнабор матриц трассировки определяетсясоставом проектных данных – типамииспользуемых артефактов, которые в своюочередь определяются принятой ворганизации методологией сборатребований и проектирования.
Уточнение Требований
Документ представляет собой таблицу, колонки которой соответствуют артефактам (код, материалы), а в строках расположены идентификаторы элементов этих артефактов. Например, разделу концепции К1 соответствуют (находятся в соседних клеточках) требования Т1..Т12, разделы тест-плана П1-П22, код реализован в классах x, y, z и документация написана в пунктах 2-13 руководства оператора. Первый тип инструментов, самый простой, – это старые добрые матрицы трассировки.
Полагая,что все требования четко идентифицированыи пронумерованы, можно сконструироватьматрицу зависимостейтребований(requirements dependency matrix) (или матрицувзаимодействия(interaction matrix требований)). В столбце истроке заголовка перечислены упорядоченныеидентификаторы требований, как показанона рис. Матрица трассировки воспринимается как очень сложный в обращении артефакт.
RTM-матрица наполняется тестировщиками, отвечающими за функцию/модуль/часть приложения, и передается менеджеру или лиду. Лид проверяет репозитории, и если соответствующие тест-кейсы существуют, утверждает матрицу. В общем виде это простая стандартная worksheet-таблица, создаваемая по шаблону. В матрице сопоставляем все требования с соответствующими тест-кейсами, убеждаясь, что для каждого требования есть хотя бы один тест-кейс.
Может показаться, что это больше похоже на декомпозицию задач, чем на трассировку требований, но ведь одно не отменяет другого. Декомпозиция сама по себе подразумевает трассировку от общего к частному. # Бизнес-требования — номер бизнес-требования (в соответствии с документацией по требованиям), который идентифицирует критерии успеха, на основе которых будут выполняться тесты. ID Матрицы — уникальная последовательность для идентификации комбинации требований и связанных с ними вариантов использования. Документ табличного вида, предназначенный для контроля выполнения требований к продукту.
Дополнительная Польза Rtm
Если «звездолет» уже есть, но непонятно, как он работает, то надо начинать по кусочкам приводить его в порядок. Сейчас у нас век микросервисов, сервисов, компонентно-ориентированных систем. Нельзя сказать, что монолиты уйдут из нашей жизни навсегда, но фокус с них смещается на другие варианты архитектуры. В каждом компоненте есть какой-то набор функций, и мы можем эти функции маппировать на компоненты. Это тоже один из вариантов применения связи двух реестров артефактов. Далее по каждой фиче мы можем посмотреть связанные с ней задачи.
В RTM-матрице требования «прикреплены» к соответствующим тест-кейсам. Столбцами даннойматрицы являются элементы системы —занятия, строками — элементы системы— студенты. Фиксациятребований (Requirement Capturing), с одной стороны,определяется желаниями заказчика вреализации того или иного свойства. Сдругой стороны в процессе сбора требованийможет обнаружиться ошибка, котораяприведет к определенным последствиям,устранение которых заберет непредвиденныересурсы –дополнительное кодирование,перепланирование.
Всё это кажется очевидным, но когда у вас огромный проект федерального масштаба, команда 300+ человек и сотни спецификаций, то в них довольно легко запутаться. Второй тип трассировки – горизонтальная, или кроссовая трассировка, когда мы делаем связи одного уровня. Это пример соцсети, когда через соцсети наши друзья все друг с другом так или иначе связаны. Например если в документации у нас много use case, то они могут пересекаться друг с другом, и быть связаны. Когда мы меняем один use case, благодаря кроссовой трассировке мы можем найти, какие другие use case поменяются у нас в проекте, таким образом отследить влияние на них и учесть в них изменения.
По трассировке, просто проверив каждый из артефактов, он уже сможет разобраться в бизнес-процессе, и качество его работы на выходе будет гораздо выше. Трассировка будет облегчать работу не только новичкам, но и тем, кто уже давно в проекте, просто потому у вас уже есть четкая структурированная картина. # Сценарий тестирования— идентификационный номер тестового скрипта, который будет использоваться для проверки связанных бизнес или функциональных требований. Табличное сопоставление требований и тест-кейсов позволяет быстро проверить, что по каждому требованию есть тест-кейс, и что каждое бизнес-требование будет исполнено.