# Матрица требований

### Что такое матрица прослеживаемости требований? <a href="#what-is-requirement-traceability-matrix" id="what-is-requirement-traceability-matrix"></a>

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

### В чем важность RTM? <a href="#why-rtm-is-important" id="why-rtm-is-important"></a>

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

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

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

Самый простой способ — отследить требование с помощью соответствующих ему тестовых сценариев и тестовых примеров. Он называется “матрицей прослеживаемости требований”.

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

### Параметры матрицы прослеживаемости требований <a href="#which-parameters-to-include-in-requirement-traceability-matrix" id="which-parameters-to-include-in-requirement-traceability-matrix"></a>

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

### Типы матриц <a href="#types" id="types"></a>

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

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

### Преимущество матрицы прослеживаемости требований <a href="#advantage" id="advantage"></a>

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://qabook.gitbook.io/start/teoriya-testirovaniya/testovaya-dokumentaciya/matrica-trebovanii.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
