Skip to content

Latest commit

 

History

History
49 lines (31 loc) · 7.65 KB

matrica-trassiruemosti-rtm-requirement-traceability-matrix.md

File metadata and controls

49 lines (31 loc) · 7.65 KB

Матрица трассируемости (RTM - Requirement Traceability Matrix)

Трассируемость (traceability): Способность идентифицировать связанные объекты в документации и программном обеспечении, например, требования со связанными с ними тестами. (ISTQB)

Матрица трассируемости (traceability matrix): Двумерная таблица, описывающая связь двух сущностей (например, требований и тестовых сценариев). Таблица позволяет производить прямую и обратную трассировку от одной сущности к другой, обеспечивая таким образом возможность определения покрытия и оценки влияния предполагаемых изменений. (ISTQB)

https://hsto.org/r/w1560/webt/5n/tw/4h/5ntw4hujujk0cmsxs6hchfajtoo.jpeg

В тестировании многое можно представить в виде удобной и наглядной матрицы (таблицы): Requirement Traceability Matrix, Test matrix, Compliance Matrix, Risk Matrix, RACI Matrix и т.д.

Матрица трассируемости (Requirement Traceability Matrix AKA Traceability Matrix or Cross Reference Matrix) используется для документирования связей между требованиями и тест-кейсами по этим требованиям и наглядного отображения трассируемости в виде простой таблицы.

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

Виды трассируемости:

  • Вертикальная трассируемость (vertical traceability): Отслеживание требований через уровни разработки к компонентам. (ISTQB)
  • Горизонтальная трассируемость (horizontal traceability): Трассировка требований к уровню тестирования по отношению к уровням документации (например, план тестирования, спецификация проектирования теста, спецификация тестовых сценариев и спецификация процедуры тестирования или автоматизированный сценарий тестирования). (ISTQB)

Другой источник:

  • Прямая трассируемость (Forward Traceability): гарантирует, что проект продвигается в желаемом направлении и что каждое требование тщательно проверяется;
  • Обратная трассируемость (Backward Traceability): гарантирует, что текущий разрабатываемый продукт находится на правильном пути. Это также помогает определить, что дополнительные неуказанные функции не добавляются и, таким образом, это не влияет на объем проекта;
  • Двунаправленная трассируемость (Bi-Directional Traceability = Forward + Backward): содержит ссылки от тестовых примеров к требованиям и наоборот. Это гарантирует, что все тестовые примеры можно отследить до требований, и каждое указанное требование содержит точные и действительные тестовые примеры для них.

RTM актуальна на всех этапах программного проекта. Давайте разберемся с этим через водопадную модель SDLC:

  • RTM начинается вместе с началом фазы сбора требований (Requirements Gathering phase);
  • продолжается через управление требованиями (Requirements Management);
  • проектирование (Design);
  • разработку (Development);
  • тестирование (Testing);
  • внедрение (Implementation);
  • и поддержку (Support).

При прохождении всех этих этапов трассируемость требований поддерживается с помощью этого документа. После того, как требования были внесены в таблицу, детали дизайна для этих требований будут сопоставлены с требованиями. На основе этих деталей проекта будет производиться разработка программного обеспечения / модуля. Детали репозитория кода из SVN, TFS, Bitbucket, Github будут сопоставлены. Теперь вы знаете, где находится дизайн и код каждого требования. Это трассируемость. Отслеживайте каждое требование от начала до его конечного результата по мере его использования пользователем приложения! На этапе поддержки RTM будет чрезвычайно полезен для понимания и решения проблем, пройдя через все соответствующие детали функции / требования. Улучшение функции стало бы возможным благодаря отслеживанию и пониманию логики, дизайна и кода. С точки зрения владения RTM, RTM принадлежит менеджерам проекта или бизнес-аналитикам. В организациях CMMi команда TQM также будет проверять это как стандартный результат в проектах программного обеспечения.

*Когда на основе требований к продукту составляются тест-сценарии и выполняется тестирование, это называется Requirement based testing.

Источники:

Доп. материал: