Що таке матриця відстеження вимог (RTM) у тестуванні?
Томас Гамільтон
⚡ Розумний підсумок
Матриця відстеження вимог (RTM) – це структурований документ, який пов’язує вимоги проекту з відповідними тестовими випадками, забезпечуючи повне охоплення та валідацію. Вона відіграє вирішальну роль у тестуванні програмного забезпечення, запобігаючи пропущеним функціональним можливостям, підтримуючи відповідність вимогам та забезпечуючи прозорість для всіх зацікавлених сторін.
Що таке матриця відстеження (TM)?
Матриця відстеження – це документ, який співвідносить будь-які два базові документи, що вимагають зв'язку "багато до багатьох", щоб перевірити повноту цього зв'язку.
Він використовується для відстеження вимог та перевірки того, чи виконуються поточні вимоги проекту.
👉 Зареєструйтесь на безкоштовний проект тестування програмного забезпечення в реальному часі
Що таке матриця відстеження вимог?
Матриця відстеження вимог (RTM) – це документ, який відображає та відстежує вимоги користувачів за допомогою тестових випадків. Він фіксує всі вимоги, запропоновані клієнтом, та можливості відстеження вимог в одному документі, що надається після завершення Життєвий цикл розробки ПЗГоловною метою Матриці відстеження вимог є підтвердження того, що всі вимоги перевірені за допомогою тестових випадків, таким чином, щоб жодна функціональність не була перевірена під час тестування програмного забезпечення.
Чому важливий RTM?
Головним завданням кожного тестувальника має бути розуміння вимог клієнта та забезпечення бездефектності кінцевого продукту. Для досягнення цієї мети кожен спеціаліст з контролю якості повинен ретельно розуміти вимоги та створювати як позитивні, так і негативні тестові випадки.
Це означатиме, що вимоги до програмного забезпечення, надані клієнтом, мають бути додатково розділені на різні сценарії та далі на тестові випадки. Кожен із цих випадків має бути виконаний окремо.
Тут виникає питання, як переконатися, що вимога перевірена, враховуючи всі можливі сценарії/випадки? Як гарантувати, що жодна вимога не буде виключена з циклу тестування?
Простий спосіб — відстежити вимогу за допомогою відповідних сценаріїв тестування та тестові справиЦе називається «Матрицею відстеження вимог».
Матриця відстежуваності зазвичай являє собою робочий аркуш, який містить вимоги з усіма можливими тестові сценарії і випадки та їх поточний стан, тобто чи були вони схвалені чи не схвалені. Це допоможе команді тестування зрозуміти рівень тестової діяльності, виконаної для конкретного продукту.
Кому потрібна RTM?
A Матриця простежуваності вимог (RTM) не лише для тестувальників — він цінний для всіх, хто займається розробкою високоякісного програмного забезпечення або проектів.
- Контроль якості та тестувальники → Забезпечте 100% покриття вимог за допомогою добре продуманих тестових випадків.
- Бізнес-аналітики → Відстежуйте вимоги з SRS/Історій користувачів до моменту їх виконання.
- Керівники проектів → Отримайте уявлення про обсяг, прогрес та невиконані вимоги.
- Розробники → Зрозумійте, як функції пов’язані з бізнес-цілями.
- Регульовані галузі (Охорона здоров'я, автомобільна промисловість, аерокосмічна галузь, фінанси) → Довести відповідність вимогам та пройти аудит із чіткою простежуваністю.
- Клієнти та зацікавлені сторони → Отримати впевненість у тому, що їхні вимоги впроваджено та перевірено.
👉 Коротше кажучи, кожен, хто відповідає за створення, перевірка або затвердження вимог до програмного забезпечення переваги RTM.
Які параметри включити до матриці відстеження вимог?
- Ідентифікатор вимоги
- Тип вимоги і Descriptіон
- Тестові випадки зі статусом
Вище наведено зразок матриці відстеження вимог.
Але в типовому тестування програмного забезпечення проекту, матриця відстеження матиме більше, ніж ці параметри.
Як показано вище, матриця відстеження вимог може:
- Показати покриття вимог у кількості тестів
- Статус проектування, а також статус виконання для конкретного тесту
- Якщо користувачі повинні провести будь-які тести прийняття користувачами, то статус UAT також може бути зафіксований у тій самій матриці.
- Відповідні дефекти та поточний стан також можуть бути згадані в тій самій матриці.
Такий тип матриці забезпечить Універсальний магазин для всіх тестових дій.
Окрім окремого ведення Excel, команда тестування також може обрати трасування вимог, доступне в Інструментах управління тестуванням.
Типи тестової матриці простежуваності
У програмній інженерії матрицю відстеження можна розділити на три основні компоненти, як зазначено нижче:
- Простежуваність вперед: Ця матриця використовується, щоб перевірити, чи просувається проект у бажаному напрямку та для правильного продукту. Він гарантує, що кожна вимога застосована до продукту та що кожна вимога ретельно перевірена. Він відображає вимоги до тестових випадків.
- Зворотна або реверсна відстежуваність: Він використовується для того, щоб переконатися, що поточний продукт залишається на правильному шляху. Мета цього типу відстеження полягає в тому, щоб перевірити, чи не розширюємо ми обсяг проекту, додаючи код, елементи дизайну, тести чи іншу роботу, яка не зазначена у вимогах. Він зіставляє тестові випадки з вимогами.
- Двонаправлена відстежуваність (вперед+назад): Ця матриця відстеження гарантує, що тестові випадки охоплюють усі вимоги. Вона аналізує вплив зміни вимог, на яку впливає Дефект в робочому продукті і навпаки.
Як створити матрицю відстеження вимог
Давайте розберемося з концепцією матриці відстеження вимог через банківський проект Guru99.
На основі документ бізнес-вимог (BRD) та Документ технічних вимог (TRD), тестери починають писати тести.
Припустимо, що наступна таблиця є нашим документом бізнес-вимог або BRD для Банківський проект Guru99.
У цьому випадку клієнт повинен мати можливість увійти на веб-сайт банку Guru99, використовуючи правильний пароль та ідентифікатор користувача, тоді як менеджер повинен мати можливість увійти на веб-сайт через сторінку входу клієнта.
Таблиця нижче – наша Документ технічних вимог (TRD).
Примітка: Команди контролю якості не документують BRD і TRD. Крім того, деякі компанії використовують Документи функціональних вимог (FRD), які схожі на документи з технічними вимогами, але процес створення матриці відстеження залишається тим самим.
Давайте створимо RTM у тестуванні
Крок 1) Команда зразок тестового випадку is
«Підтвердити вхід: Після введення правильного ідентифікатора та пароля система має успішно увійти в систему».
Крок 2) Визначте технічну вимогу, яку перевіряє цей тестовий випадок. У нашому тестовому випадку перевіряється технічна вимога T94.
Крок 3) Зверніть увагу на цю технічну вимогу (T94) у тестовому випадку.
Крок 4) Визначте бізнес-вимоги, для яких визначено цей TR (Технічна вимога-T94).
Крок 5) Зверніть увагу на BR (бізнес-вимогу) у тестовому випадку
Крок 6) Виконайте вищезазначене для всіх тестових випадків. Later, Витягніть перші 3 стовпці з вашого набору тестів. RTM у тестуванні готовий!
Переваги матриці відстеження вимог
- Це підтверджує 100% покриття тесту
- Він підкреслює будь-які відсутні вимоги або невідповідності документів
- Він показує загальні дефекти або стан виконання з акцентом на бізнес-вимоги
- Це допомагає в аналізі або оцінці впливу на роботу команди контролю якості щодо повторного перегляду або переробки тестових випадків.
Найкращі практики та поради щодо використання RTM
Матриця відстеження вимог (RTM) є найефективнішою, коли вона залишатися простим, послідовним та регулярно оновлюватисяОсь найкращі практики, які дозволять командам забезпечити повне покриття, мінімальна переробка та підвищена впевненість у виконанні проекту:
- Почніть рано → Створіть свою RTM на самому початку проекту.
- Тримайте його оновленим → Оновлюйте матрицю щоразу, коли змінюються вимоги або тестові випадки.
- Використовуйте прозорі ідентифікатори → Призначте унікальні ідентифікатори вимогам і тестовим випадкам для легкого відстеження.
- Покривайте позитивні та негативні випадки → Переконайтеся, що кожну вимогу перевірено з кількох точок зору тестування.
- Співпрацюйте між командами → Залучайте тестувальників, розробників, бізнес-аналітиків та керівників проектів до підтримки RTM.
- Інструменти використання → Замість електронних таблиць розгляньте інструменти управління тестуванням (такі як Jira, HP ALM або Zephyr) для масштабованості.
- Контроль версій → Зберігайте історичні версії для відстеження змін та забезпечення відповідності.
- Зосередьтеся на простоті → Уникайте перевантаження матриці; виділіть лише важливі параметри.
- Аудит регулярно → Періодично переглядайте RTM, щоб виявити прогалини перед дедлайнами тестування.
- Посилання на бізнес-цінність → Зіставте вимоги з бізнес-цілями, щоб показати рентабельність інвестицій.
Поширені проблеми та рішення RTM
- Завдання: оновлення RTM
Вимоги та тестові випадки часто змінюються, що робить RTM швидко застарілим.
Рішення: Використовуйте автоматизовані інструменти керування тестуванням, які синхронізують вимоги, тестові випадки та дефекти в режимі реального часу. - Проблема: Надмірна складність
Додавання занадто великої кількості параметрів ускладнює підтримку та інтерпретацію RTM.
Рішення: Зберігайте ефективність RTM, зосереджуючись лише на важливих полях, таких як ідентифікатори, описи та статус. - Проблема: Погана співпраця в команді
Різні команди можуть не узгоджувати свої дії щодо відповідальності або оновлень.
Рішення: Визначте чіткі ролі, залучайте тестувальників, розробників та аналітиків, а також плануйте регулярні огляди RTM. - Проблема: Неповне покриття вимог
У деяких вимогах може не вистачати тестових випадків, що призводить до втраченої функціональності.
Рішення: Регулярно перевіряйте покриття, використовуйте двонаправлену відстежуваність та проводите аудити перед основними релізами. - Завдання: Ручна робота у великих проектах
Керування RTM в електронних таблицях стає трудомістким для складних систем.
Рішення: Використовуйте інструменти RTM, такі як Jira, HP ALM або Zephyr, для автоматизації картографування та звітності.
Давайте вивчимо RTM на прикладі у відео
Натисніть тут якщо відео недоступне
Шаблон матриці відстеження вимог (RTM).
Натисніть нижче, щоб завантажити файл Excel шаблону RTM
Завантажити шаблон RTM Excel (.xlsx)
