Что такое матрица прослеживаемости требований (RTM) в тестировании?

Автор: Томас Гамильтон Томас Гамильтон
Hours обновлено

⚡ Умное резюме

Матрица отслеживания требований (RTM) — это структурированный документ, связывающий требования проекта с соответствующими им тестовыми случаями, обеспечивая полное покрытие и валидацию. Она играет важнейшую роль в тестировании программного обеспечения, предотвращая пропуск функций, обеспечивая соответствие требованиям и обеспечивая прозрачность для всех заинтересованных сторон.

  • Запускайте RTM на ранних этапах жизненного цикла проекта, чтобы обеспечить полное соответствие требованиям.
  • Обновляйте матрицу при каждом изменении требований или тестовых случаев.
  • Используйте понятные, уникальные идентификаторы для эффективного сопоставления требований, сценариев и тестовых случаев.
  • Организуйте совместную работу тестировщиков, разработчиков, аналитиков и менеджеров для обеспечения общей ответственности.
  • Используйте инструменты автоматизации (например, Jira, Zephyr) для сокращения ручного труда и повышения масштабируемости.
Читать

Матрица прослеживаемости (RTM)

Что такое матрица прослеживаемости (TM)?

Матрица прослеживаемости — это документ, который сопоставляет любые два базовых документа, требующих отношения «многие ко многим» для проверки полноты отношения.

Он используется для отслеживания требований и проверки соответствия текущих требований проекта.

👉 Зарегистрируйтесь на бесплатный проект по живому тестированию программного обеспечения

Что такое матрица прослеживаемости требований?

Матрица отслеживания требований (RTM) Это документ, который отображает и отслеживает требования пользователя с помощью тестовых случаев. Он фиксирует все требования, предложенные клиентом, и отслеживает их выполнение в едином документе, предоставляемом по завершении тестирования. Жизненный цикл разработки программного обеспечения. Основная цель матрицы отслеживания требований — подтвердить, что все требования проверены с помощью тестовых случаев, чтобы ни одна функциональность не осталась непроверенной во время тестирования программного обеспечения.

Почему RTM важен?

Основная задача каждого тестировщика — понять требования заказчика и убедиться, что конечный продукт не содержит дефектов. Для достижения этой цели каждый тестировщик должен досконально понимать требования и создавать как положительные, так и отрицательные тестовые случаи.

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

Возникает вопрос: как обеспечить тестирование требования с учётом всех возможных сценариев/случайностей? Как гарантировать, что ни одно требование не будет исключено из цикла тестирования?

Простой способ — отследить требование с помощью соответствующих сценариев тестирования и контрольные примеры. Это называется «Матрица прослеживаемости требований».

Матрица прослеживаемости обычно представляет собой рабочий лист, содержащий требования со всеми возможными тестовые сценарии а также случаи и их текущее состояние, т.е. были ли они пройдены или нет. Это поможет команде тестирования оценить уровень тестирования, проведённого для конкретного продукта.

Кому нужен RTM?

A Матрица прослеживаемости требований (RTM) не только для тестировщиков — это ценно для всех, кто занимается разработкой высококачественного программного обеспечения или проектов.

  • Контроль качества и тестировщики → Обеспечьте 100% покрытие требований с помощью четко определенных тестовых случаев.
  • Бизнес-аналитики → Отслеживайте требования от SRS/User Stories до их исполнения.
  • Менеджеры проектов → Получите представление об объеме работ, ходе работ и невыполненных требованиях.
  • Застройщики → Понимание того, как функции соотносятся с бизнес-целями.
  • Регулируемые отрасли (Здравоохранение, автомобилестроение, аэрокосмическая промышленность, финансы) → Доказывайте соответствие и проходите аудиты с четкой прослеживаемостью.
  • Клиенты и заинтересованные стороны → Получите уверенность в том, что их требования реализованы и протестированы.

👉 Короче говоря, любой, кто отвечает за создание, проверка или утверждение требований к программному обеспечению выгоды от RTM.

Какие параметры следует включить в матрицу прослеживаемости требований?

  • Идентификатор требования
  • Тип требования и Descriptион
  • Тестовые случаи со статусом

Матрица отслеживания требований

Выше приведен пример матрицы отслеживания требований.

Но в типичном тестирование программного обеспечения проекта матрица прослеживаемости будет иметь больше этих параметров.

Матрица отслеживания требований

Как показано выше, матрица прослеживаемости требований может:

  • Покажите покрытие требований по количеству тестовых случаев
  • Статус проектирования, а также статус выполнения для конкретного тестового примера.
  • Если пользователям необходимо провести какие-либо приемочные испытания, то статус приемочных испытаний также можно зафиксировать в той же матрице.
  • Сопутствующие дефекты и текущее состояние также могут быть упомянуты в этой же матрице.

Этот тип матрицы обеспечит Всё в одном месте для всех видов деятельности по тестированию.

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

Типы матрицы проверки прослеживаемости

В программной инженерии матрицу прослеживаемости можно разделить на три основных компонента, как указано ниже:

  • Прямая прослеживаемость: Эта матрица используется для проверки того, продвигается ли проект в желаемом направлении и для правильного продукта. Он гарантирует, что каждое требование применяется к продукту и что каждое требование тщательно протестировано. Он сопоставляет требования с тестовыми примерами.
  • Обратная или обратная прослеживаемость: Она используется для обеспечения соответствия текущего продукта заданному курсу. Цель этого типа прослеживаемости — убедиться, что мы не расширяем область проекта путём добавления кода, элементов дизайна, тестов или других работ, не указанных в требованиях. Она сопоставляет тестовые случаи с требованиями.
  • Двунаправленная отслеживаемость (вперед+назад): Эта матрица прослеживаемости гарантирует, что тестовые случаи охватывают все требования. Она анализирует влияние изменений в требованиях, затронутых дефект в рабочем продукте и наоборот.

СТАТЬИ ПО ТЕМЕ

Как создать матрицу прослеживаемости требований

Давайте разберемся с концепцией матрицы отслеживания требований на примере банковского проекта Guru99.

На основе Документ бизнес-требований (BRD) и Документ технических требований (TRD), тестировщики начинают писать тестовые примеры.

Предположим, что следующая таблица — это наш документ с бизнес-требованиями или BRD для Банковский проект Guru99.

В данном случае сценарий заключается в том, что клиент должен иметь возможность войти на банковский сайт Guru99, используя правильный пароль и идентификатор пользователя, в то время как менеджер должен иметь возможность войти на сайт через страницу входа клиента.

Как создать матрицу прослеживаемости требований (RTM)

Таблица ниже - это наша Документ технических требований (TRD).

Как создать матрицу прослеживаемости требований (RTM)

Примечание: Команды контроля качества не документируют BRD и TRD. Кроме того, некоторые компании используют Документы с функциональными требованиями (FRD), которые похожи на документы с техническими требованиями, но процесс создания матрицы прослеживаемости остается тем же.

Давайте продолжим и создадим RTM в тестировании

Шаг 1) Наша команда пример тестового примера is

«Подтвердите вход в систему: если введены правильный идентификатор и пароль, вход в систему должен быть успешным».

Как создать матрицу прослеживаемости требований (RTM)

Шаг 2) Определите техническое требование, которое проверяет этот тестовый пример. В нашем тестовом примере проверяется техническое требование T94.

Как создать матрицу прослеживаемости требований (RTM)

Шаг 3) Обратите внимание на это техническое требование (T94) в тестовом примере.

Как создать матрицу прослеживаемости требований (RTM)

Шаг 4) Определите бизнес-требование, для которого определено данное ТР (Техническое требование-Т94).

Как создать матрицу прослеживаемости требований (RTM)

Шаг 5) Обратите внимание на BR (бизнес-требование) в тестовом примере.

Как создать матрицу прослеживаемости требований (RTM)

Шаг 6) Повторите вышеуказанные действия для всех тестовых случаев. Later, извлеките первые 3 столбца из вашего тестового набора. RTM в тестировании готов!

Как создать матрицу прослеживаемости требований (RTM)

Преимущества матрицы прослеживаемости требований

  • Это подтверждает 100% покрытие тестами
  • Он подчеркивает любые отсутствующие требования или несоответствия в документах.
  • Он показывает общие дефекты или статус выполнения с акцентом на бизнес-требованиях.
  • Это помогает проанализировать или оценить влияние повторного просмотра или переработки тестовых случаев на работу команды QA.

Лучшие практики и советы по использованию RTM

Матрица отслеживания требований (RTM) наиболее эффективна, когда она быть простым, последовательным и регулярно обновлятьсяВот лучшие практики, которые позволят командам обеспечить полный охват, минимальная доработка и повышенная уверенность в реализации проекта:

  • Начать рано → Создайте свой RTM в самом начале проекта.
  • Держите его в курсе → Обновляйте матрицу при каждом изменении требований или тестовых случаев.
  • Использовать четкие идентификаторы → Присваивайте уникальные идентификаторы требованиям и тестовым случаям для легкой отслеживаемости.
  • Охватывайте положительные и отрицательные случаи → Убедитесь, что каждое требование проверено с нескольких точек зрения.
  • Сотрудничайте между командами → Привлекайте тестировщиков, разработчиков, бизнес-аналитиков и руководителей проектов к поддержанию RTM.
  • Инструменты кредитного плеча → Вместо электронных таблиц рассмотрите возможность использования инструментов управления тестированием (например, Jira, HP ALM или Zephyr) для масштабируемости.
  • Контроль версий → Сохраняйте исторические версии для отслеживания изменений и обеспечения соответствия.
  • Сосредоточьтесь на простоте → Избегайте перегрузки матрицы; выделите только самые необходимые параметры.
  • Регулярно проводите аудит → Периодически проверяйте RTM, чтобы выявить пробелы до наступления сроков тестирования.
  • Связь с ценностью бизнеса → Сопоставьте требования с бизнес-целями, чтобы показать рентабельность инвестиций.

Распространенные проблемы RTM и их решения

  1. Задача: поддерживать RTM в актуальном состоянии
    Требования и тестовые случаи часто меняются, из-за чего RTM быстро устаревает.
    Решение: Используйте автоматизированные инструменты управления тестированием, которые синхронизируют требования, тестовые случаи и дефекты в режиме реального времени.
  2. Проблема: чрезмерная сложность
    Добавление слишком большого количества параметров затрудняет поддержку и интерпретацию RTM.
    Решение: Сохраняйте RTM компактным, сосредоточившись только на самых важных полях, таких как идентификаторы, описания и статус.
  3. Проблема: плохое взаимодействие в команде
    Различные команды могут не совпадать по вопросам владения или обновлений.
    Решение: Определите четкие роли, привлеките тестировщиков, разработчиков и аналитиков и запланируйте регулярные обзоры RTM.
  4. Задача: неполное покрытие требований
    В некоторых требованиях могут отсутствовать тестовые случаи, что приводит к пропуску функциональности.
    Решение: Регулярно проверяйте охват, используйте двунаправленную прослеживаемость и проводите аудит перед крупными выпусками.
  5. Задача: ручная работа в крупных проектах
    Управление RTM в электронных таблицах становится трудоемким для сложных систем.
    Решение: Используйте инструменты RTM, такие как Jira, HP ALM или Zephyr, для автоматизации картографирования и составления отчетов.

Давайте изучим RTM на примере в Видео.

Нажмите здесь если видео недоступно

Шаблон матрицы прослеживаемости требований (RTM)

Нажмите ниже, чтобы загрузить файл Excel-шаблона RTM.

Загрузите шаблон RTM Excel (.xlsx)

Часто задаваемые вопросы:

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

Существует три основных типа RTM: Прямая прослеживаемость (сопоставляет требования с тестовыми случаями), Обратная прослеживаемость (сопоставляет тестовые случаи с требованиями) и Двунаправленная прослеживаемость (объединяет оба направления). В совокупности эти подходы обеспечивают полный охват, предотвращают ненужное расширение области действия и подтверждают тщательность тестирования всех требований.

Матрица отслеживания требований обычно составляется на ранних этапах проекта, после того как требования задокументированы в SRS, BRD или бэклоге. Она развивается на протяжении всего жизненного цикла, обновляясь при изменении требований или тестовых случаев. Ранняя подготовка RTM обеспечивает согласованность, минимизирует количество упущенных функций и способствует эффективному планированию тестирования и анализу покрытия.

Основная ответственность за поддержание RTM обычно лежит на команда контроля качества or Тестеры. Тем не менее, бизнес-аналитики определить требования, застройщиков связать код с этими требованиями и менеджеры проектов контролировать точность. На практике RTM — это общая ответственность всех команд, обеспечивающая отслеживание и проверку требований на каждом этапе.

Чтобы использовать RTM, перечислите требования проекта вместе с соответствующими им тестовыми случаями. Отслеживайте статус выполнения, дефекты и покрытие. Команды используют его для проверки тестирования требований, выявления пробелов и оценки влияния изменений. Он становится живым документом, обеспечивающим прозрачность и контроль на протяжении всего тестирования и жизненного цикла проекта.

Да, RTM широко используется в Agile-проектах. Вместо формальных документов SRS требования часто берутся из истории пользователей or невыполненные работы по продуктуКоманды, работающие по Agile, сопоставляют эти истории с тест-кейсами в RTM, обеспечивая валидацию каждой истории. Этот подход хорошо адаптируется к итеративной природе Agile, сохраняя при этом полный охват.

Да, RTM можно автоматизировать с помощью инструментов управления тестированием, таких как Jira, HP ALM или ZephyrАвтоматизация сокращает ручную работу, обеспечивает обновления в режиме реального времени и улучшает отслеживаемость требований, тестовых случаев и дефектов. Автоматизированные RTM особенно полезны в крупных или регулируемых проектах, где соответствие требованиям и готовность к аудиту имеют решающее значение.

RTM и RACI служат разным целям. RTM отслеживает требования и тестовые случаи для обеспечения охвата и проверки. RACI Матрица распределения обязанностей, показывающая, кто отвечает, подотчётен, консультируется и информируется в проекте. RTM фокусируется на требованиях и тестировании, а RACI уточняет роли и обязанности команды.

Подведем итог этой публикации следующим образом: