🪓
QAммунизм
  • 💬Предисловия
  • 📜Теория тестирования
    • Для чего проводится тестирование ПО?
    • Принципы тестирования
    • QC — Quality Control
    • QA — Quality Assurance
    • Верификация и валидация
    • Этапы тестирования
    • Стадии разработки ПО
    • Требования
    • Дефект (bug) и Отчёт о дефекте (bug report)
    • Severity vs Priority
    • Базовые типы задач
    • Тестовые среды
    • Основные фазы тестирования
    • Основные виды тестирования ПО
    • Тест-дизайн
    • Методы тестирования
      • Тестирование белого ящика
      • Тестирование серого ящика
      • Тестирование чёрного ящика
    • Тестовая документация
      • Тест план (Test Plan)
      • Чек-лист (check list)
      • Тестовый сценарий (test case)
  • 🦠Матрица компетенций QA Engineer
    • Грэйды QA
      • Trainee Manual QA Engineer (стажер)
      • Junior Manual QA Engineer (младший)
      • Pre-Middle Manual QA Engineer (почти средний)
      • Middle Manual QA Engineer (средний)
      • Upper-Middle Manual QA Engineer (продвинутый)
      • Senior Manual QA Engineer (ведущий)
    • Грэйды AQA
      • Trainee Automation QA Engineer (стажер)
      • Junior Automation QA Engineer (младший)
      • Pre-Middle Automation QA Engineer (почти средний)
      • Middle Automation QA Engineer (средний)
      • Upper-Middle Automation QA Engineer (продвинутый)
      • Senior Automation QA Engineer (ведущий)
    • Краткое содержание
  • 📑Паттерн описания тест-кейсов
    • Названия
    • Описание
    • Количество шагов
    • Ожидаемые результаты
  • 🦾Автоматизация тестирования
    • 🐍Python
      • 🧪PyTest
        • pytest.ini
      • 📗SeleniumBase
        • Установка
        • Конфигурации подключения к Selenoid
        • Распространенные методы
      • 📊Allure Python
        • Установка
        • Слушатель
        • Декораторы
          • Шаги(step)
          • Вложения(attach)
          • Ссылки(issue)
          • Описания(description)
          • Заголовки(title)
          • Строгость(Severity)
          • Epic
          • Title
        • Окружающая среда(Environment)
        • Маркеры(mark)
      • 🗺️ООП в Python во всех подробностях
        • Приватность свойств. Name Mangling (_name и __name)
        • Переменные (свойства / атрибуты) класса
        • Анотация типов
        • @staticmethod
        • @classmethod
        • @property
        • Кеширование результата вычисляемых свойств
        • Наследование
        • Определение одного родителя
        • Перегрузка
        • Множественное наследование
        • Mixins
        • Полиморфизм
        • super().__init__() - Инициализация из родительского класса
        • Хешированные объекты
        • Абстрактные классы
        • Абстрактный класс наследуется от абстрактного класса
        • __slots__ в классе и при наследовании
        • Композиция
        • Наследование vs Композиция
        • Дескрипторы (__get__(), __set__(), __del__())
        • No Data Descriptor
        • Data Descriptor
        • Слабые ссылки (weakref)
        • Метод __set_name__
    • 🐸JavaScript (В разработке)
      • 🃏Playwright (В разработке)
    • 🛰️Git: Основные команды
    • 🧊Selenoid - Allure server
      • Установка
    • 🐳Docker
      • Установите Docker Desktop в Windows
    • 🧾Паттерны проектирования автоматизированного тестирования
      • Как написать идеальный автотест: 25 принципов.
        • Тесты не так важны, как действия по результатам этих тестов
        • Ценность
        • Лучше ничего не делать, чем сделать flaky-тест
        • Доверие
        • Поделись знанием
        • Устрой дестрой
        • Думай иначе
        • Тесты должны запускаться автоматически
        • Тайна пирамиды
        • Из множества важного выбирай то, что проще
        • Нельзя протестировать всё
        • Используй скрытую силу
        • Принцип ААА
        • Не повторяйся
        • Хрупкость
        • Принцип двух ящиков
        • Тестируй без последствий
        • Упрощения
        • Красота
        • Параллельность
        • Скорость
        • Автотест — это фича
        • Автотест — это тест
        • Атомарность
        • Независимость
      • Паттерны
        • Page Object Model (POM)
    • 🧑‍🔧Принципы разработки ПО
      • SOLID в автоматизации тестирования
        • S — Single Responsibility Principle(Принцип единой ответственности)
        • O — Open/Closed Principle(Принцип открытости/закрытости)
        • L — Liskov Substitution Principle(Принцип замены Лискова)
        • I — Interface Segregation Principle(Принцип разделения интерфейса)
        • D — Dependency Inversion Principle(Принцип инверсии зависимостей)
      • KISS (Keep It Simple, Stupid)
      • DRY (Don’t Repeat Yourself)
      • YAGNI (You Aren’t Gonna Need It)
      • Бритва Оккама
      • Avoid Premature Optimization
  • 🎭Вопросы для собеседования
    • Junior
      • Теория тестирования
      • AQA
        • Программирование
        • Selenium
        • TestNG/JUnit(PYTHON)
        • Git
        • CI
      • Интернет
      • Компьютерные сети
      • Практические задания
    • Middle
      • Теория
      • AQA
        • Selenium
        • Тестовая инфраструктура
      • Интернет
      • Мобильный
      • Практические задания
    • Senior
      • Теория
      • Практические задания
    • Практические задания
  • 📊Оценка покрытие Тест-кейсами/UI-автотестами(Coverage)
    • Матрица трассировки требований(RTM)
    • Обратная связь от тестировщиков
    • Включение новых сценариев
    • Использование метрик покрытия
    • Анализ отчетов о выполнении тестов
    • Измерение покрытия кода
    • Определение целевых экранов
    • Рассмотрение покрытия по сценариям использования
    • Автоматизированные средства анализа кода
Powered by GitBook
On this page
  • Пример матрицы отслеживания требований
  • Роль матрицы в тестировании
  • Типы матрицы
  • Компоненты RTM-матрицы
  • Инструменты
  • Требования и тест-кейсы в матрице

Was this helpful?

  1. Оценка покрытие Тест-кейсами/UI-автотестами(Coverage)

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

Last updated 1 year ago

Was this helpful?

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

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

Данный QA-термин — абсолютный рекордсмен по количеству русскоязычных названий. Их не меньше десяти:

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

  • Матрица прослеживаемости требований

  • Матрица сверки требований

  • Матрица слежения за требованиями

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

  • и просто матрица требований

Также встречаются названия:

  • Матрица трассировки требований

  • Матрица трассируемости (и именно это название одобрено ISTQB)

  • и матрица трассабилити.

  • Также называют просто RTM-матрицей.

Отслеживание требований может быть как прямое («от требований к коду»), так и обратное («от кода к требованиям»).

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

RTM-матрица наполняется тестировщиками, отвечающими за функцию/модуль/часть приложения, и передается менеджеру или лиду. Лид проверяет репозитории, и если соответствующие тест-кейсы существуют, утверждает матрицу. В общем виде это простая стандартная worksheet-таблица, создаваемая по шаблону.

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

Нюансы

  • Матрица создается до утверждения требований и перед выполнением тест-кейсов

  • Матрицу пишут с учетом, что какой-то тест-кейс может быть отменен

  • Задача матрицы отслеживания — чтобы каждое требование имело хотя бы один тест-кейс, не обязательно чтобы на одно требование было много тест-кейсов

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

Роль матрицы в тестировании

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

Вопрос: как гарантировать, что каждое требование протестировано по всем потенциальным сценариям и кейсам, что ни одно требование не пропущено? Проще всего и быстрее — сопоставлением в таблице-матрице. Указывается также текущий статус тест-кейсов, то есть прошел / не прошел. Это помогает команде оценивать продвижение с требованиями.

Дополнительная польза RTM

  • Качественный контроль выполнения требований

Типы матрицы

Существует три типа матрицы сверки требований:

  • Прямая

  • Обратная

  • Двунаправленная

Прямое отслеживание

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

Требования сопоставляются с тест кейсами в таком виде:

Обратное отслеживание

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

Требования сопоставляются с тест-кейсами в таком виде:

Двусторонняя Матрица

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

Компоненты RTM-матрицы

  • ID требования

  • Тип и описание требования

  • Статус тест-кейса

Например, RTM-матрица приложения заказа билетов:

ID или Номер требования
Описание требования
ID тест-кейса
Статус

172

Логин в приложение

TC01,TC02,TC03

TC01-PassTC02-Pass

456

Создание билета

TC04,TC05,TC06,TC07,TC08,TC09,TC010

TC04-PassTC05-PassTC06-PassTC06-FailTC07-No Run

676

Поиск билета

TC011,TC012,TC013,TC014

TC011-PassTC012-FailTC013-PassTC014-No Run

RTM-матрица — общепринятая вещь в QA. Кроме тест-кейсов и требований, могут быть и другие, дополняющие, параметры:

  • Количество тест-кейсов, нужных для покрытия всех требований

  • По специфическим тест-кейсам — статус их создания + статус выполнения

  • Если проводится приемочное тестирование, регистрируется приемочный статус

  • Фиксируются ошибки и примечания

В простейшем случае матрица представляет собой просто excel-файл, а чаще ссылку в Google Sheets, а иногда команда пользуется инструментами, автоматически формирующими RTM-матрицу. Это проще, однако такие инструменты чаще всего платные.

Инструменты

Если Excel (Google Sheet) не нравится, есть альтернативы:

Visure Requirements

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

Modern Requirements4DevOps

Интегрирован с Microsoft Azure DevOps, TFS, и VSTS, удобен для менеджеров

ReQtest

Полное отслеживание требований. Облачный инструмент. Гибко настраивается.

Требования и тест-кейсы в матрице

Уточнение требований

Например, требование: имплементировать функцию Написать письмо в email-приложении.

Имплементация: уточнение, где кнопка Написать письмо будет расположена на главной странице?

Обязательно ли это требование?

Например,

Требование: только указанные пользователи могут видеть функцию Написать письмо в этом приложении.

Имплементация: если папка Входящие временно поставлена пользователем в статус «Закрыта на запись», кнопка Написать письмо не обязательна в данный момент.

Требования могут быть многоступенчатыми

Например,

Требование: добавить кнопку Написать письмо с особыми шрифтами и прикреплениями в email-приложении.

Имплементация: какие функции будут доступны после нажатия кнопки Написать письмо?

  • Нужен доступ к телу письма, возможность создавать и редактировать текст, а также изменять шрифты и стили в том числе жирный, курсив, и подчеркивание.

  • Прикрепления многих типов: рисунки, документы, другие письма, архивы.

  • Оценка объема прикрепления (не больше максимального объема)

Как видим, требования могут делиться на дополнительные/вложенные требования.

Имплементация требований возможна разными путями

Например,

Требование: все папки в почтовом ящике, типа Входящие, Отправить, Черновики, Спам, Корзина, должны быть видимы и доступны.

Имплементация: все эти элементы должны быть иметь формат Дерева (Tree) или Вкладок (Tabs)

Требования могут зависеть от других требований

Например,

Требование: в email-приложении должна быть Корзина.

Имплементация: если опция Корзина в приложении доступна, сначала должно быть имплементировано (и значит протестировано) требование Удалить письмо. Если требование (функция) работает нормально, удаленные письма будут отправляться в Корзину, и требование наличия и доступности Корзины можно имплементировать.

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

Помогает отслеживать тестовую документацию (артефакты), созданную в .

Помогает лучше отслеживать причины багов и их

Матрица трассабилити — прямая
Матрица трассабилити — обратная

Матрица трассируемости в ReQtest
📊
SDLC-цикле
кластеризацию
Сайт
Сайт
Сайт
Матрица трассируемости требований
Матрица трассабилити - обратная
Матрица отслеживания требований
Матрица трассабилити - прямая
Матрица трассируемости в ReQtest