Готовим ли мы матрицу прослеживаемости требований до/после создания плана тестирования?

RTM всегда является важным документом любого проекта. В любом проекте шаблон RTM определяется планом тестирования и тем, как тестер будет работать с шаблоном сегодня, когда проект стартует.

После того, как требования будут окончательно определены, идентификаторы каждого требования необходимо включить в шаблон RTM.

После того, как тестовые наборы созданы и тщательно проверены, все тестовые наборы необходимо сопоставить с соответствующими идентификаторами требований.

Даже иногда, если в проекте есть какой-либо процесс, соответствующий правилу МОСКВА, это также поможет тестировщикам определить порядок выполнения.

В конце концов, RTM гарантирует, что для каждого идентификатора требования есть тестовые примеры. Это гарантирует максимальное покрытие, но не 100%

Готовится ли RTM до создания плана тестирования или после создания плана тестирования?

Это документ, который предоставляется после завершения разработки/тестирования, поэтому он должен быть живым документом. По сути, он сопоставляет ваши требования с вашими тестовыми примерами, чтобы вы могли отслеживать свое покрытие при тестировании всего, что находится в разработке.

как оба взаимосвязаны?

Связанных на 100% нет. Ваш план тестирования будет охватывать ваш подход к тому, как он будет тестироваться. RTM сопоставляет, что вы тестируете, чтобы обеспечить достаточный охват в процессе тестирования.

В случае интеграции, системы, генерального плана тестирования, как связан RTM?

В случае системного/интеграционного тестирования ваша RTM в идеале должна охватывать оба типа тестов. Лично я считаю, что генеральный план тестирования — пустая трата времени и сил. Ваш план(ы) тестирования должен охватывать то, что вам нужно.

Изменить: об этом есть действительно хорошая статья здесь.

Надеюсь, это поможет!

1. Чтобы ответить на ваш первый вопрос, RTM — это то, что готовится по мере готовности требований. Если вы планируете внедрить практику создания RTM в своем проекте, вы можете указать этот пункт в своем плане тестирования независимо от того, создан он или нет.
2. Test Plan and RTM are not related. RTM is prepared keeping the following objectives in mind:
   • Requirements coverage - To verify whether all requirements have been covered against test case.
   • Это чрезвычайно полезно для выявления связанных тестовых случаев и, следовательно, упрощает регрессионное тестирование.
3. Практика, которой мы следуем, заключается в том, что RTM создается для каждого требования. Как только требование заморожено, команда контроля качества создает для него тестовые наборы, помечает все связанные тестовые наборы для требования и делится ими с командой разработчиков. Таким образом, пока идет разработка, разработчики обращаются к матрице, чтобы убедиться, что все тестовые примеры, связанные с этим требованием, пройдены, прежде чем передать требование команде контроля качества. Таким образом, в идеале RTM следует подготовить, как только станут известны требования. Конечно, это означает, что любые изменения в требованиях также потребуют модификации RTM. Это может быть добавление нового TC, удаление TC или определение набора регрессионных тестов здесь.
   Подробнее о том, как создать RTM, можно прочитать здесь, поскольку очень важно, чтобы он был заполнен правильно, иначе это может привести к неудовлетворенным клиентам. RTM хороша настолько, насколько хороши люди, создающие ее.
   Надеюсь, это поможет!

Матрица прослеживаемости подготавливается после того, как требования собраны, и после утверждения выпуска после QA мы генерируем RTM (матрицу прослеживаемости требований) из HP ALM QC (инструмент управления тестированием), поскольку я использую HP ALM, это делается таким образом.

После того, как требования собраны, мы готовим документ «Стратегия плана тестирования», который охватывает все сценарии тестирования (обзор, выход за рамки, охваченные элементы регрессии), на основе которого мы создаем требования в HP ALM QC и связываем тестовые случаи, связанные с каждым сценарием.

После подписания мы генерируем RTM, чтобы убедиться, что все требования выполнены в этом выпуске и ничего не упущено.

STLC имеет 5 этапов. Критерий выхода из анализа требований — RTM, затем следующий этап — планирование тестирования
, а затем — разработка тестового примера. так как RTM написан до разработки тестового примера