Привет, Хабр! Меня зовут Максим, я тестировщик в РГС. Сейчас мы с командой разрабатываем новое приложение для клиентов, и нам очень хотелось, чтобы у нас была прозрачная картина актуальности и полноты тестового покрытия, для повышения качества выпускаемого продукта и эффективности процессов.

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

Отсутствие единой, структурированной картины требований создает ряд проблем для разработки и тестирования и ведет к следующим негативным последствиям:

• Недостаточная полнота проверки: команде сложно убедиться в том, что все критичные элементы требований (функционал, исключения, ограничения, критерии приемки) учтены и проверены;

• Дублирование требований и противоречия: без систематизации нередко возникают повторяющиеся или взаимоисключающие требования, что ухудшает качество тестовых сценариев и усложняет процесс их поддержки;

• Отсутствие прослеживаемости: сложно отследить покрытие требований тестами и их приоритет.

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

Плюсы и минусы «традиционных» подходов

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

• Недостаточная гибкость и масштабируемость: с ростом количества требований, тест-кейсов и участников команды управление ими становится сложным, возможны ошибки и пропуски;

• Отсутствие автоматизации: такие подходы зачастую требуют ручного анализа и обновления, что увеличивает трудозатраты и вероятность ошибок, связанных с человеческим фактором;

• Трудности в отслеживании изменений: при изменении требований сложно проследить, какие тесты требуют обновления и актуализации;

• Ограниченность в аналитике: такие методы плохо подходят для оценки полноты покрытия требований, анализа приоритета и выявления пробелов.

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

Как внедрить матрицу трассировки требований, учитывая частые ошибки

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

Результаты опроса:

58% участников считают матрицу важным инструментом для QA, отмечая, что при правильной реализации она значительно упрощает управление тестовым покрытием и прослеживаемость требований;

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

15% признали опыт отказа от использования матрицы, отметив, что при высокой трудоемкости и слабой части ее поддержки она становится тяжёлым и малоэффективным инструментом.

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

Еще коллеги отметили, что на практике используют альтернативные системы, например, инструменты автоматизации или связывание требований через системы управления задачами — Azure DevOps или Jira, которые позволяют трекать покрытие без классической матрицы.

На основе всех этих данных я сделал следующие выводы:

• Реальную ценность матрица трассировки приобретает при условии систематической работы с требованиями с момента их появления;

• В случае дефицита ресурсов и/или отсутствия четкой документации поддерживать матрицу в актуальном состоянии становится трудозатратно и неэффективно;

• Использование современных инструментов (например, связки юзер-стори с тест-кейсами в системах типа Azure DevOps) иногда заменяет классическую матрицу, экономя время и ресурсы.

Какие матрицы нам предлагал Google?

Следующим шагом я пошел в гугл и начал анализировать все, что поисковик выдавал по запросу «матрица трассировки требований».

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

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

Недостатки таких решений

Отсутствие поддержки изменений: при каждом обновлении требований или тест-кейсов приходится вручную корректировать таблицы.

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

Отсутствие логики, автоматизации процессов и аналитики, необходимых для масштабных проектов.

Что мы хотели вылечит на нашем проекте с помощью Матрицы?

1. Отсутствие прозрачной трассировки между требованиями и тестами

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

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

2. Ограниченность аналитики и отчётности

Проблема: отсутствие систематизированных данных о связях между требованиями и тестами затрудняет проведение аналитики и подготовку отчётов для заинтересованных сторон.

Решение: разработка матрицы с функциями фильтрации, группировки и автоматической генерации отчётов, обеспечивающих доступ к актуальной аналитике.

3. Неэффективное использование ресурсов

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

Решение: автоматизация части процессов с помощью матрицы позволяет высвободить ресурсы и повысить эффективность работы команды.

Как же выглядит идеальная для нас Матрица

В классическом понимании матрица трассировки (RTM) — это двумерная таблица, которая связывает требования с тестовыми сценариями, что позволяет отслеживать полноту покрытия, управлять изменениями и повышать качество продукта.

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

Столбцы:

1. Технические задачи или бизнес-требования:

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

2. Требования:

ID - уникальный идентификатор вида требования (например, 1.2.3, где 1 — тип требования, 2 — категория, 3 — порядковый номер).

Требования — краткое и ясное описание требования.

Статус — текущий уровень актуальности:

• Полные/актуальные;

• Полные/подлежат актуализации;

• Неполные/актуальные;

• Неполная/неактуальная.

Документация к требованиям — ссылки на сопутствующую документацию (макеты, технические спецификации).

ID связанных требований - номера требований, на которые есть влияние и/или связи.

Severity — уровень критичности требований для бизнеса:

• Красный — критический (hight);

• Синий — важный (medium);

• Зеленый — низкий (low).

3. QA:

Тест кейсы — ссылки на связанные тестовые сценарии

Результаты — результаты прохождения тестов или комментарии по ним

4. AQA:

Аналогично разделу QA, но предназначен для дополнительных тестов или автоматизированных цепочек тестирования.

Тест кейсы — ссылки на связанные тестовые сценарии.

Результаты — описание итогов тестирования

5. Регресс

Номера регрессионных тест-кейсов, автоматических или ручных, которые включены в регрессионный тест

Строки:

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

1. Функциональные требования;

2. UI (пользовательский интерфейс);

3. API;

4. Иные виды тестирования (например, безопасность, нагрузка, совместимость).

А как это все работает?

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

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

Какие промежуточные выводы на первом этапе внедрения Матрицы мы для себя отметили

С учетом практики работы с разработанной матрицей трассировки требований, мы выработали основные условия ее актуальности для проекта:

1. Достаточность и устойчивость требований

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

2. Период деятельности проекта и планирование

Матрица имеет смысл для долгосрочных проектов, которые предполагают устойчивое планирование развития и тестирования. В таких проектах матрица становится инструментом управления качеством, отслеживания прогресса и результатов регрессионных тестов на протяжении всей жизненного цикла продукта. Для проектов в режиме MVP (минимально жизнеспособный продукт) или POC (proof of concept), где фокус на быстром запуске и экспериментировании, создание и поддержка матрицы зачастую не оправданы, так как объем требований и тестовых сценариев может быть минимальный или временный.

3. Соотношение затрат и ценности

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