Що таке матриця відстеження вимог (RTM) у тестуванні?
Томас Гамільтон
Що таке матриця відстеження (TM)?
Матриця відстеження — це документ, який співвідносить будь-які двобазові документи, які потребують зв’язку «багато-до-багатьох» для перевірки повноти зв’язку.
Він використовується для відстеження вимог і перевірки виконання вимог поточного проекту.
Що таке матриця відстеження вимог?
Матриця простежуваності вимог (RTM) це документ, який відображає та відстежує вимоги користувача за допомогою тестових випадків. Він фіксує всі вимоги, запропоновані клієнтом, і можливість відстеження вимог в єдиному документі, який надається на завершення Життєвий цикл розробки ПЗ. Основна мета матриці відстеження вимог — підтвердити, що всі вимоги перевіряються за допомогою тестових випадків, щоб жодна функціональність не була неперевірена під час тестування програмного забезпечення.
Чому RTM важливий?
Основним завданням кожного тестувальника має бути розуміння вимог клієнта та переконання, що вихідний продукт має бути бездефектним. Щоб досягти цієї мети, кожен QA повинен добре розуміти вимоги та створювати позитивні та негативні тести.
Це означало б, що вимоги до програмного забезпечення, надані клієнтом, повинні бути додатково розділені на різні сценарії та далі для тестування. Кожен з цих випадків повинен розглядатися індивідуально.
Тут виникає питання, як переконатися, що вимога перевірена з урахуванням усіх можливих сценаріїв/випадків? Як переконатися, що жодна вимога не залишиться поза циклом тестування?
Простий спосіб — відстежити вимогу за допомогою відповідних сценаріїв тестування та тестові справи. Це просто називається «Матрицею відстеження вимог».
Матриця відстеження зазвичай є робочим аркушем, який містить усі можливі вимоги тестові сценарії і справи та їх поточний стан, тобто чи були вони пройдені чи не пройдені. Це допоможе групі тестувальників зрозуміти рівень тестування конкретного продукту.
Які параметри включити в матрицю відстеження вимог?
- Ідентифікатор вимоги
- Тип вимоги і Descriptіон
- Тестові випадки зі статусом
Вище наведено зразок матриці відстеження вимог.
Але в типовому тестування програмного забезпечення проекту, матриця відстеження матиме більше, ніж ці параметри.
Як показано вище, матриця відстеження вимог може:
- Показати покриття вимог у кількості тестів
- Статус проектування, а також статус виконання для конкретного тесту
- Якщо користувачі повинні виконати будь-який тест прийнятності користувача, то статус UAT також можна зафіксувати в тій самій матриці.
- Відповідні дефекти та поточний стан також можуть бути згадані в тій самій матриці.
Такого роду матриця забезпечить One Stop Shop для всіх тестових дій.
Окрім окремого ведення 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% покриття тесту
- Він підкреслює будь-які відсутні вимоги або невідповідності документів
- Він показує загальні дефекти або стан виконання з акцентом на бізнес-вимоги
- Це допомагає в аналізі або оцінці впливу на роботу команди QA щодо повторного перегляду або повторної роботи над тестовими прикладами
Давайте вивчимо RTM на прикладі у відео
Натисніть тут якщо відео недоступне
Шаблон матриці відстеження вимог (RTM).
Натисніть нижче, щоб завантажити файл Excel шаблону RTM
