Наличие такой матрицы позволяет объективно оценить, какая часть продукта покрыта тестами, а какая нет. А если, наоборот, хочется чего-то “покрепче” – найти много чего про управления требованиями можно еще в стандарте CMMI (Capability Maturity Mannequin Integration), там есть целая процессная область Requirements Administration. Документ табличного вида, предназначенный для контроля выполнения требований к продукту. В RTM-матрице требования «прикреплены» к соответствующим тест-кейсам. Один из его ключевых разделов – управление жизненным циклом требований (Requirements Life Cycle Management), в нем как раз есть подраздел про трассировку.
Улучшение функции стало бы возможным благодаря отслеживанию и пониманию логики, дизайна и кода. С точки зрения владения RTM, RTM принадлежит менеджерам проекта или бизнес-аналитикам. В организациях CMMi команда TQM также будет проверять это как стандартный результат в проектах программного обеспечения.
Прямое Отслеживание
Матрица отслеживания требований (RTM-матрица) — это документ, который обычно создается в виде таблицы, позволяющий следить за полным жизненным циклом требований к проекту. Матрица фиксирует именно требования к продукту, с момента постановки цели проекта и его бизнес-требований и вплоть до тест-кейсов. RTM-матрица может использоваться в различных проектах, включая разработку программного обеспечения, системную интеграцию, проекты Agile и т.д. Одним из инструментов управления проектами является матрица отслеживания требований (на английском – Requirements Traceability Matrix или просто RTM), вот о ней давайте сегодня и поговорим. # Вариант использования — идентификационный номер варианта использования, который будет использоваться для проверки соответствия бизнес-требований с функциональными требованиями.
Кстати, когда-то давно в блоге даже был гостевой пост от читательницы, сдавшей экзамен по BABOK, почитать можно тут. Для больших и комплексных систем, где обойтись просто табличкой нельзя, используется специализированное программное обеспечение, например, RequisitePro, Mantis, JIRA и так далее. Работа в них требует определенных усилий по налаживаю процесса в команде, но обычно оно того стоит, если проект большой. Иначе в какой-то момент таблицы в экселе с тысячей строк просто станут неуправляемыми. Помогает проверить, что каждое бизнес-требование корректно имплементировано и качественно протестировано, что разработка продукта идет правильно.
Что Же Такое Матрица Трассируемости?
На основе этих деталей проекта будет производиться разработка программного обеспечения / модуля. Детали репозитория кода из SVN, TFS, Bitbucket, Github будут сопоставлены. Отслеживайте каждое требование от начала до его конечного результата по мере его использования пользователем приложения! На этапе поддержки RTM будет чрезвычайно полезен для понимания и решения проблем, пройдя через все соответствующие детали функции / требования.
- Также может (и должна!) трассироваться история изменений требований, если таковая будет.
- На этапе поддержки RTM будет чрезвычайно полезен для понимания и решения проблем, пройдя через все соответствующие детали функции / требования.
- Матрица трассируемости может служить одновременно в качестве матрицы покрытия.
Обратное отслеживание применяется, когда есть вероятность, что время и средства уходят на улучшение необязательных элементов дизайна, бесконечное совершенствование кода, или тестирование вещей, которых нет в бизнес-требованиях. Чтобы не приносить в жертву время сотрудников и актуальность данных по тестированию проекта, расскажу, как с помощью инструментов Сфера мы справились с этими вопросами и задачами и используем матрицу трассировки. Матрица трассируемости (Requirement Traceability Matrix AKA Traceability Matrix or Cross Reference Matrix) используется для документирования связей между требованиями и тест-кейсами по этим требованиям и наглядного отображения трассируемости в виде простой таблицы. Основная задача матрицы — связать каждое требование с соответствующими тест—кейсами, что обеспечивает полное покрытие аспектов. Если требование состоит из нескольких частей, для каждой из них разрабатываются отдельные тесты. # Бизнес-требования — номер бизнес-требования (в соответствии с документацией по требованиям), который идентифицирует критерии успеха, на основе которых будут выполняться тесты.
Доклад о матрице трассировки — одном из инструментов, который повышает прозрачность процесса тестирования и дает понимание о покрытии фич и историй из бэклога разработки тестовыми сценариями. # Сценарий тестирования— идентификационный номер тестового скрипта, который будет использоваться для проверки связанных бизнес или функциональных требований. Табличное сопоставление требований и тест-кейсов позволяет быстро проверить, что по каждому требованию есть тест-кейс, и что каждое бизнес-требование будет исполнено. Таблица также помогает выполнять матрица трассируемости тесты упорядоченным образом, с приоритетами соответствующими требованиям. # Функциональные требования — идентификационный номер функционального требования (в соответствии с документацией по требованиям), которое исполняет указанное бизнес-требование.
Также может (и должна!) трассироваться история изменений требований, если таковая будет. При прохождении всех этих этапов трассируемость требований поддерживается с помощью этого документа. После того, как требования были внесены в таблицу, детали дизайна для этих требований будут сопоставлены с требованиями.
В простейшем случае матрица представляет собой просто excel-файл, а чаще ссылку в Google Sheets, а иногда команда пользуется инструментами, автоматически формирующими RTM-матрицу. RTM-матрица наполняется тестировщиками, отвечающими за функцию/модуль/часть приложения, и передается менеджеру или лиду. Лид проверяет репозитории, и если соответствующие тест-кейсы существуют, утверждает матрицу. В общем виде это простая стандартная worksheet-таблица, создаваемая по шаблону. В матрице сопоставляем все требования с соответствующими тест-кейсами, убеждаясь, что для каждого требования есть хотя бы один тест-кейс. Матрица трассируемости может служить одновременно в качестве матрицы покрытия.
Отслеживание требований может быть как прямое («от https://deveducation.com/ требований к коду»), так и обратное («от кода к требованиям»). На старте разработки руководитель проекта совместно с бизнес-аналитиками определяет, что именно нужно отслеживать в проекте и готовит шаблон документа. ID Матрицы — уникальная последовательность для идентификации комбинации требований и связанных с ними вариантов использования. Тестировщик должен хорошо понять требования клиента и позаботиться, чтобы в финальном продукте не было багов. Он создает позитивные и негативные тест-кейсы по отдельным требованиям. Помогает оценить изменения в требованиях, возникающие в результате дефектов.
В русскоязычном интернете можно найти много статей, где этот инструмент описан более узко, чаще всего его упрощают до матрицы, в которой отображают связь функциональных требований с тест-кейсами, которыми они проверяются. Это не совсем корректно – как и практически любой инструмент в управлении проектами, матрица трассировки требований может и должна быть адаптирована под задачи конкретного проекта. Ну и в целом само слово “трассировка” переводится с английского как “возможность отслеживания”, а отслеживать в проекте нужно все-таки не только покрытие тестами. Ошибка идет, похоже, Юзабилити-тестирование от того, что на курсах тестировщиков матрицу трассировки слушателям “продают” как инструмент тестирования, поэтому если такое увидите – не верьте.