Это довольно трудоемко, но мы гарантированно будем понимать, как существует и работает наша информационная система с точки зрения требований. Основная задача матрицы — связать каждое требование с соответствующими тест—кейсами, что обеспечивает полное покрытие аспектов. Если требование состоит из нескольких частей, для каждой из них разрабатываются отдельные тесты. Данный тестовый артефакт является неотъемлемой частью тестирования. Связь двух реестров применима к любым задачам, когда нужно увидеть, как одно соотносится с другим.
Создание И Ведение Матрицы
В русскоязычном интернете можно найти много статей, где этот инструмент описан более узко, чаще всего его упрощают до матрицы, в которой отображают связь функциональных требований с тест-кейсами, которыми они проверяются. Это не совсем корректно – как и практически любой инструмент в управлении проектами, матрица трассировки требований может и должна быть адаптирована под задачи конкретного проекта. Ну и в целом само слово “трассировка” переводится с английского как “возможность отслеживания”, а отслеживать в проекте нужно все-таки не только покрытие тестами. Ошибка идет, похоже, от того, что на курсах тестировщиков матрицу трассировки слушателям “продают” как инструмент тестирования, поэтому если такое увидите – не верьте. Во-вторых, это визуализация и построение отчетов по связям, когда система управления требованиями и инструменты трассировки позволяют быстро и легко строить матрицу трассировок. Это принцип иерархии, когда наверху есть главные бизнес-цели проекта, ниже – бизнес-правила, пользовательские требования, варианты использования (use case), системные требования.
Таким образом, мы можем понять, что за задача, к какому проекту она относится и какие в проекте есть фичи. Если мы учитываем по проекту все наши фичи, в том числе планируемые, мы формируем оцифрованный бэклог. А если, наоборот, хочется чего-то “покрепче” – найти много чего про управления требованиями можно еще в стандарте CMMI (Capability Maturity Model Integration), там есть целая процессная область Requirements Management. Первый тип инструментов, самый простой, – это старые добрые матрицы трассировки. Их можно создавать вручную и использовать для этого Excel, Google Doc, Confluence, даже обычную доску с маркером.
Только неотвратимость трассировки делает ее хорошим инструментом. Трассировка требований должна обязательно быть включена в какой-либо нормоконтроль или согласование. Потому что как только это становится необязательным, оно перестает работать. Проект, вообще не покрытый трассировками, лучше проекта, покрытого трассировками наполовину.
Второй тип трассировки – горизонтальная, или кроссовая трассировка, когда мы делаем связи одного уровня. Это пример соцсети, когда через соцсети наши друзья все друг с другом так или иначе связаны. Например если в документации у нас много use case, то они могут пересекаться друг с другом, и быть связаны. Когда мы меняем один use case, благодаря кроссовой трассировке мы можем найти, какие другие use case поменяются у нас в проекте, таким образом отследить влияние на них и учесть в них изменения. Любое программное обеспечение, которое используют в качестве систем управления требованиями.
Типы Матриц
Нельзя сказать, что монолиты уйдут из нашей жизни навсегда, но фокус с них смещается на другие варианты архитектуры. В каждом компоненте есть какой-то набор функций, и мы можем эти функции маппировать на компоненты. Это тоже один из вариантов применения связи двух реестров артефактов.
Трассировка требований – это способность соотнести какой-либо элемент проекта с другим связанным с проектом элементом, особенно с тем, который имеет отношение к техническим требованиям проекта. Один https://deveducation.com/ из его ключевых разделов – управление жизненным циклом требований (Requirements Life Cycle Management), в нем как раз есть подраздел про трассировку. Кстати, когда-то давно в блоге даже был гостевой пост от читательницы, сдавшей экзамен по BABOK, почитать можно тут.
- В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии.
- Потому что как только это становится необязательным, оно перестает работать.
- У нас бывают проекты, где бизнес-заказчики дают довольно общие запросы на доработку.
- Сейчас у нас век микросервисов, сервисов, компонентно-ориентированных систем.
- Одним из инструментов управления проектами является матрица отслеживания требований (на английском – Requirements Traceability Matrix или просто RTM), вот о ней давайте сегодня и поговорим.
На старте разработки руководитель проекта совместно с Регрессионное тестирование бизнес-аналитиками определяет, что именно нужно отслеживать в проекте и готовит шаблон документа.
Одним из инструментов управления проектами является матрица отслеживания требований (на английском – Necessities Traceability Matrix или просто RTM), вот о ней давайте сегодня и поговорим. Матрица отслеживания требований (RTM-матрица) — это документ, который матрица трассируемости обычно создается в виде таблицы, позволяющий следить за полным жизненным циклом требований к проекту. Матрица фиксирует именно требования к продукту, с момента постановки цели проекта и его бизнес-требований и вплоть до тест-кейсов. RTM-матрица может использоваться в различных проектах, включая разработку программного обеспечения, системную интеграцию, проекты Agile и т.д. Посмотреть на все многообразие артефактов и понять, обо что больше всего людей спотыкается.
Это и Jira, потому что она позволяет линковать различные артефакты, и Redmine, и Confluence Atlassian через метки страниц, и Google таблицы. Можно много всего адаптировать в качестве системы управления требованиями, к тому же сделать это быстро и просто. Представим, что мы даем новичку задачу, нужно на такой-то форме добавить такой-то атрибут.
А команда разработки понимает из какого запроса родилось это требование. Рассмотрим ещё один пример, который больше относится к аналитике и непосредственно к требованиям. Основная его идея – связь двух реестров требований, когда есть артефакты первого реестра и артефакты второго реестра и нужно сделать между ними маппинг.
