По сути, это обычная таблица, который помогает нам, как QA, понять простую вещь: какие требования чем покрыты, где есть пробелы или непокрытые требования, и что нужно перепроверять после изменений.
В целом, главная идея матрицы трассировки в том, чтобы у команды была понятная картина покрытия требований тестами, чек-листами. Если объяснять совсем по-простому, то test case у нас отвечает на вопрос, как проверить и что проверить. А RTM отвечает на вопрос, что чем покрыто.
Например, у нас есть требование: пользователь должен иметь возможность восстановить пароль через email. В RTM мы можем увидеть, какие проверки относятся к этому требованию, были ли они выполнены, какой у них результат, есть ли по ним какие-то баги, нужно ли что-то retest-ить. Но это в такой расширенной версии(базовая версия на фото выше) — просто какие проверки относятся к этому требованию.
По сути, матрица трассировки помогает ответить на три базовых вопроса.
Первый — что мы уже протестировали. То есть, если требование связано с test case или чек-листом, мы видим, что оно хотя бы формально покрыто проверками.
Второй — что мы не протестировали. Если у требования нет проверок или покрытие частичное, это тоже сразу видно. Такие места, в целом, могут быть опасны перед релизами, потому что команда может думать, что мы уже все проверили, хотя часть требований вообще не трогали.
Третий — почему мы тестируем именно это. То есть у каждого теста появляется какое-то обоснование. То есть не просто рандомный набор действий, а видно, почему мы тестируем это: потому что у нас есть такое требование.
Поэтому RTM, полезно не только для QA, но и для всей команды, но в то же время для QA, наверное, суперполезно, потому что благодаря этому можно делать некий отчет о том, что мы проверили и какие требования покрыли.
В целом, если у нас нет требований прямо отдельно, у нас просто описана сама задача, то здесь мы можем сделать чек-лист по всем условным критериям приемки и просто знать, что мы протестировали.
Я вообще рекомендую чек-листы всегда писать, если задача не , где в этом нет необходимости, для того чтобы просто спустя неделю, не дай бог, обнаружится какая-то ошибка, вас спросят: «А что вы там проверяли?», и вы не помните, всегда можно опереться на этот чек-лист. Базовая минимальная структура RTM состоит из строки столбцов, где в строках мы указываем устойчивые ID требований, а в колонках указываем устойчивые ID тест-кейсов. И на их пересечении ставятся либо галочки, что вот это требование покрывается вот этими кейсами, вот это требование покрывается вот этими кейсами.
Да, есть куда более расширенные, но для базового понимания нужно именно это.
Вообще RTM полезна там, где очень много требований и много участников, частые изменения или нужно отчитываться перед бизнесом. Например, в waterfall и таких более формальных проектах требования фиксируются заранее, тесты пишутся под них, и связь между этими артефактами нужна с самого начала.
В больших командах, в целом, помогает не держать все в голове. Когда над продуктом работает большая команда, тут просто матрица помогает сохранить связь между требованиями, проверками, и, если мы ведем более расширенную версию, то какими-то статусами.
Плюс полезно при частых изменениях требований. Допустим, поменялась какая-то логика восстановления пароля, и без этой матрицы мы должны вспомнить, какие тесты нужно обновить, что нужно заново прогнать в регрессе. А с такой матрицей мы, по сути, просто видим быстрые связанные проверки, понимаем, куда нам идти, что исправлять, что актуализировать.
Но в целом плохая практика заосвывать RTM везде. Если у нас небольшая фича на 5 требований, стартап какой-то или задача на пару дней, то вообще, в целом, может быть лишней. В таких случаях достаточно, опять-таки, обычного чек-листа, каких-то критериев приемки.
Маленькой фиче не нужна матрица, но для какого-то критичного банковского или медицинского контура просто держать в голове, что я все проверил, во-первых, это трудно, во-вторых, просто недостаточно.