Трассируемость

Updated Jul 2026

Что такое трассируемость?

Трассируемость — это способность связать каждое требование с тест-кейсами, которые его верифицируют, и каждый дефект — с тест-кейсом, который его обнаружил. Она отвечает на фундаментальный вопрос: «Что было протестировано для этого релиза и каковы известные пробелы?»

Без трассируемости вы полагаетесь на опыт команды и интуицию. С трассируемостью у вас есть системный ответ, подкреплённый данными.

Матрица трассируемости требований (RTM)

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

Что показывает RTM

• REQ-005 не имеет тестового покрытия: это ключевая ценность трассируемости — обнаружение пробелов до того, как они станут продакшен-багами. Без RTM вы можете не заметить, что это требование никогда не тестировалось.
• REQ-004 имеет упавший тест: связанный дефект (SHOP-812) открыт. Это требование не готово к релизу.
• REQ-006 заблокирован: что-то препятствует выполнению теста. Это нужно обсудить на стендапе.

Построение трассируемости на практике

Шаг 1: Связывание требований с историями

В Jira убедитесь, что каждая пользовательская история имеет ссылку на своё требование (или сама является требованием для небольших команд):

Epic: SHOP-100 (Checkout Redesign)
  └── Story: SHOP-456 (Credit card payment)
       └── Requirement: REQ-003
  └── Story: SHOP-457 (Coupon support)
       └── Requirement: REQ-004

Шаг 2: Связывание тест-кейсов с требованиями

В вашей платформе управления тестированием привяжите каждый тест-кейс к требованию, которое он верифицирует:

TC-401 (Pay with credit card)
  └── Verifies: REQ-003
  └── Part of: SHOP-456

TC-403 (Apply valid coupon)
  └── Verifies: REQ-004
  └── Part of: SHOP-457

Шаг 3: Связывание дефектов с тест-кейсами

Когда тест падает и вы заводите баг, привяжите баг к тест-кейсу:

SHOP-812 (Expired coupon causes 500 error)
  └── Found by: TC-404
  └── Blocks: REQ-004
  └── Fix PR: github.com/org/repo/pull/234

Шаг 4: Генерация RTM

Большинство платформ управления тестированием могут генерировать RTM автоматически из этих связей. Если нет, используйте JQL-запрос или экспорт для построения:

-- Find requirements without linked test cases
project = SHOP AND type = "Requirement"
AND NOT issueFunction in linkedIssuesOf("type = Test")

Анализ покрытия

Трассируемость позволяет проводить анализ покрытия: измерять, какой процент требований имеет тест-кейсы и какой процент этих тест-кейсов был выполнен.

Метрики покрытия

Анализ пробелов

Проводите анализ пробелов перед каждым релизом:

1. Генерация RTM: экспорт из платформы управления тестированием
2. Выявление непокрытых требований: требования без привязанных тест-кейсов
3. Выявление непротестированных функций: тест-кейсы, не выполненные в текущем цикле
4. Оценка рисков: для каждого пробела определите риск выпуска без покрытия
5. Решение: написать тесты, принять риск или отложить релиз

Интеграция CI/CD для трассируемости

Лучшие настройки управления тестированием автоматически обновляют результаты из запусков пайплайна, исключая ручное обновление статусов.

Типичный процесс

1. Пайплайн запускает автоматизированные тесты и создаёт JUnit XML или JSON-результаты
2. Пост-тестовый шаг вызывает API платформы управления тестированием для загрузки результатов
3. Тест-кейсы на платформе автоматически отмечаются как Passed/Failed
4. Тикеты дефектов автоматически создаются для новых сбоев (опционально)
5. Дашборды обновляются в реальном времени

Загрузка результатов в TestRail

# Using TestRail CLI
trcli -y \
  -h "https://yourcompany.testrail.io" \
  --project "Web App" \
  --title "Nightly Regression Run" \
  parse_junit \
  --file "./test-results/junit.xml"

Загрузка результатов в Xray

# Using Xray REST API
curl -H "Content-Type: application/json" \
  -H "Authorization: Bearer $XRAY_TOKEN" \
  -X POST \
  --data @test-results/junit.xml \
  "https://xray.cloud.getxray.app/api/v2/import/execution/junit"

Загрузка результатов в GitHub Actions

# Example: Upload to TestRail after tests complete
- name: Upload results to TestRail
  if: always()
  run: |
    pip install trcli
    trcli -y \
      -h "${{ secrets.TESTRAIL_URL }}" \
      -u "${{ secrets.TESTRAIL_USER }}" \
      -p "${{ secrets.TESTRAIL_API_KEY }}" \
      --project "Web App" \
      --title "PR #${{ github.event.number }} Test Run" \
      parse_junit \
      --file "./test-results/junit.xml"

Антипаттерны трассируемости

Трассируемость для комплаенса

В регулируемых отраслях (здравоохранение, финансы, автомобилестроение) трассируемость не опциональна — это регуляторное требование.

Что ищут аудиторы:

• Каждое требование имеет хотя бы один тест-кейс
• Каждый тест-кейс был выполнен для данного релиза
• Каждый сбой имеет задокументированное решение (исправлен, принят риск, отложен)
• Доказательства тестирования сохранены (скриншоты, логи, отчёты)
• Цепочка от требования к тесту, дефекту и исправлению не прерывается

Практическое упражнение

1. Выберите одну функциональную область вашего продукта. Создайте вручную RTM с требованиями, тест-кейсами и статусом выполнения.
2. Выявите пробелы: какие требования не имеют тестового покрытия?
3. Привяжите 10 существующих тест-кейсов к соответствующим требованиям в вашей платформе управления тестированием
4. Настройте интеграцию CI/CD для автоматической загрузки результатов тестов на платформу
5. Сгенерируйте отчёт о покрытии и представьте его команде
6. Для каждого непокрытого требования примите решение: написать тест, принять риск или отложить