Що таке матриця простежуваності вимог (RTM)? Приклад шаблону

Що таке матриця простежуваності? (TM)

Матриця простежуваності - це документ, який співвідносить будь-які двоосновні документи, які вимагають взаємозв'язку "багато-до-багатьох", щоб перевірити повноту відносин.

Він використовується для відстеження вимог та перевірки виконання поточних вимог проекту.

Що таке матриця простежуваності вимог?

Матриця простежуваності вимог (RTM) - це документ, який відображає та відстежує потреби користувачів із тестовими кейсами. Він фіксує всі вимоги, запропоновані клієнтом, і простежуваність вимог в одному документі, що подається на завершення життєвого циклу розробки програмного забезпечення. Основною метою Матриці простежуваності вимог є перевірка того, що всі вимоги перевіряються за допомогою тестових кейсів, так що жодна функціональність не перевіряється під час тестування ПЗ.

У цьому підручнику ви дізнаєтесь більше про

Чому RTM важливий?
Які параметри включити до матриці простежуваності вимог?
Типи матриці випробувань на відстежуваність
Як створити матрицю простежуваності вимог
Перевага матриці простежуваності вимог
Шаблон матриці простежуваності вимог (RTM)

Чому RTM важливий?

Основним порядком роботи кожного тестера має бути розуміння вимог клієнта та переконатися, що продукція, що випускається, повинна мати дефекти. Для досягнення цієї мети кожна перевірка якості повинна чітко розуміти вимогу та створювати позитивні та негативні тести.

Це означало б, що вимоги до програмного забезпечення, що надаються клієнтом, повинні бути додатково розбиті на різні сценарії та надалі для тестування випадків. Кожна з цих справ повинна виконуватися індивідуально.

Тут виникає питання про те, як переконатися, що вимога перевірена з урахуванням усіх можливих сценаріїв / випадків? Як переконатись, що будь-яка вимога не залишається поза циклом тестування?

Простий спосіб - відстежити вимогу з відповідними сценаріями тестування та тестовими кейсами. Це просто називають "матрицею відстеження вимог".

Матриця простежуваності, як правило, є робочим аркушем, який містить вимоги з усіма можливими сценаріями та випадками тестування та їх поточним станом, тобто якщо вони були передані або невдалі. Це допомогло б тестувальній групі зрозуміти рівень випробувальної діяльності, проведеної для конкретного продукту.

Які параметри включити до матриці простежуваності вимог?

Ідентифікатор вимоги
Тип вимоги та опис
Тестові випадки зі статусом

Вище наведена матриця простежуваності вимог до зразків.

Але в типовому проекті тестування програмного забезпечення матриця простежуваності мала б більше цих параметрів.

Як проілюстровано вище, матриця простежуваності вимог може:

Покажіть охоплення вимог у кількості тестових кейсів
Статус проекту, а також статус виконання для конкретного тесту
Якщо користувач повинен провести тест на прийняття користувача, статус UAT також може бути зафіксовано в тій же матриці.
Пов’язані дефекти та поточний стан також можуть бути згадані в одній і тій же матриці.

Цей тип матриці буде забезпечувати єдиний магазин для всіх тестових заходів.

Окрім підтримки окремо Excel. Команда тестування може також вибрати вимоги щодо відстеження доступних інструментів управління тестами.

Типи матриці випробувань на відстежуваність

У програмній інженерії матрицю простежуваності можна розділити на три основні компоненти, як зазначено нижче:

Прослідковування вперед : Ця матриця використовується для перевірки, чи прогресує проект у бажаному напрямку та для правильного продукту. Це гарантує, що кожна вимога застосовується до продукту і що кожна вимога ретельно перевіряється. Він відображає вимоги до тестових кейсів.
Зворотна чи зворотна простежуваність: Використовується для того, щоб переконатися, що поточний продукт залишається правильним. Мета цього типу відстежуваності - перевірити, що ми не розширюємо сферу проекту, додаючи код, елементи дизайну, тестування чи іншу роботу, яка не зазначена у вимогах. Він відображає тестові приклади до вимог.
Двонаправлена простежуваність (вперед + назад): Ця матриця простежуваності гарантує, що всі вимоги покриваються тестовими кейсами. Він аналізує вплив зміни вимог, на які впливає Дефект у робочому продукті, і навпаки.

Як створити матрицю простежуваності вимог

Давайте розберемося в концепції матриці простежуваності вимог через банківський проект Guru99.

На основі Документа про ділові вимоги (BRD) та Документа про технічні вимоги (TRD) тестувальники починають писати тестові кейси.

Припустимо, наступна таблиця - це наш Документ про бізнес-вимоги або BRD для банківського проекту Guru99 .

Тут сценарій полягає в тому, що клієнт повинен мати можливість увійти на веб-сайт банківської служби Guru99 з правильним паролем та ідентифікатором користувача #, тоді як менеджер повинен мати можливість входу на веб-сайт через сторінку входу клієнта.

Хоча наведена нижче таблиця - це наш документ з технічними вимогами (TRD) .

Примітка: Команди з контролю якості не документують BRD та TRD. Крім того, деякі компанії використовують Документи вимог до функцій (FRD) , подібні до Документа технічних вимог, але процес створення Матриці простежуваності залишається незмінним.

Давайте йти вперед і створити RTM в тестуванні

Крок 1: Наш зразок тестового кейсу є

"Підтвердьте вхід, коли введено правильний ідентифікатор та пароль, він повинен успішно увійти"

Крок 2 : Визначте Технічну вимогу, яку перевіряє цей тестовий випадок. Для нашого тестового випадку технічна вимога T94 перевіряється.

Крок 3: Зверніть увагу на ці технічні вимоги (T94) у тестовому випадку.

Крок 4: Визначте вимоги до бізнесу, для яких визначено цю ТР (Технічна вимога-T94)

Крок 5: Зверніть увагу на BR (бізнес вимоги) у тестовому випадку

Крок 6: Виконайте вище для всіх тестових випадків. Пізніше витягніть перші 3 стовпці з набору тестів. RTM у тестуванні готовий!

Перевага матриці простежуваності вимог

Це підтверджує 100% охоплення тестом
У ньому висвітлено відсутність вимог або невідповідність документів
Він показує загальні дефекти або стан виконання з акцентом на вимоги бізнесу
Це допомагає аналізувати або оцінювати вплив на роботу групи з контролю якості щодо перегляду або повторної роботи над тестовими кейсами