Матриця відповідності вимог (Requirement Traceability Matrix) – це документ, який відображає та відстежує вимоги користувача за допомогою тестових випадків (тест-кейсів). Він фіксує всі вимоги, запропоновані клієнтом, та дає можливість відстеження вимог в одному документі, який надається наприкінці життєвого циклу розробки програмного забезпечення. Основна мета матриці відповідності вимог – підтвердити, що всі вимоги перевіряються за допомогою тестових випадків, щоб кожна функціональність була перевірена під час тестування програмного забезпечення.
Побудова матриці відповідності вимог
Побудова матриці відповідності вимог
Для чого будуються матриці відповідності вимог
Кожен тестувальник повинен розуміти вимоги клієнта та бути переконаним, що вихідний продукт має бути бездефектним. Для цього потрібно вміти добре створювати позитивні та негативні тести.
Це означало б, що вимоги до програмного забезпечення, надані клієнтом, повинні бути додатково розділені на різні сценарії та далі перетворені в тест-кейси. Кожен з цих випадків повинен розглядатися індивідуально. Тут виникає питання, як переконатися, що вимога перевірена з урахуванням усіх можливих сценаріїв/випадків? Як переконатися, що жодна вимога не залишиться поза циклом тестування?
Простий спосіб полягає в тому, щоб відстежити вимогу з її відповідними тестовими сценаріями та тестовими випадками. Такий спосіб називається «Матрицею відповідності вимог».
Матриця відповідності містить вимоги з усіма можливими тестовими сценаріями та випадками, а також їхнім поточним станом. Це допомагає команді тестувальників зрозуміти рівень тестування конкретного продукту.
Які параметри включити в матрицю відповідності вимог?
- Ідентифікатор вимоги.
- Тип і опис вимоги.
- Тестові випадки зі статусом.
Вище наведено спрощений зразок матриці відповідності вимог.
Але в типовому проєкті тестування програмного забезпечення матриця матиме більшу кількість параметрів.
Як показано вище, матриця відповідності вимог може:
- показати покриття вимог у кількості тестів;
- показати статус проєктування, а також статус виконання для конкретного тесту;
- якщо користувачі повинні виконати будь-який тест прийомки (acceptance test), то статус UAT також можна зафіксувати в тій самій матриці;
- відповідні дефекти та поточний стан також можуть бути згадані.
Така матриця забезпечить «єдине вікно» для всіх видів тестування.
Окрім ведення таблиці Excel, команда тестувальників також може вибрати доступні інструменти керування тестуванням для відстеження вимог.
Типи матриць вимог
У розробці програмного забезпечення матриці можна розділити на три основні компоненти:
- Попередня відповідність (Forward traceability): ця матриця використовується для перевірки того, чи просувається проєкт у бажаному напрямку. Гарантує, що кожна вимога застосована до продукту та ретельно перевірена. Матриця відображає вимоги до тестових випадків.
- Зворотня відповідність (Backward or reverse traceability): використовується для того, щоб переконатися, що поточний продукт залишається на правильному шляху. Мета такого типу відстеження – переконатися, що ми не розширюємо обсяг проєкту шляхом додавання коду, елементів дизайну, тестування чи іншої роботи, яка не вказана у вимогах. Ця матриця зіставляє тестові випадки з вимогами.
- Двонаправлена відповідність (вперед+назад) (Bi-directional traceability (Forward+Backward): ця матриця гарантує, що всі вимоги охоплені тестовими випадками, а також аналізує вплив зміни вимог, на які впливає дефект у робочому продукті, і навпаки.
Як створити матрицю відповідності вимог
Давайте розглянемо простий приклад створення матриці відповідності вимог.
На основі Business Requirement Document (BRD) та Technical Requirement Document (TRD) тестувальники створюють тест-кейси.
Наприклад, бізнес вимога:
B1 – Клієнт повинен мати можливість увійти на веб-сайт за допомогою правильного пароля та ідентифікатора користувача, тоді як менеджер повинен мати можливість увійти на веб-сайт через сторінку входу клієнта.
В документі технічних вимог (TRD) вказано наступне:
T22 – Поле “UserID” не повинно бути порожнім.
T23 – Поле “Password” не повинно бути порожнім.
T24 – Користувач успішно залогінений, якщо в поля “UserID” та “Password” введено валідні дані.
Крок 1. Створюємо тест-кейс.
Крок 2. Визначте технічну вимогу (TR), яку перевіряє цей тест. Для нашого тестового випадку перевіряється технічна вимога T24.
Крок 3. Визначте бізнес-вимоги (BR) для даної технічної вимоги. В нашому випадку це B1.
Крок 4. Додаємо інформацію про технічні та бізнес-вимоги до нашого тест-кейсу.
Крок 5. Виконати такі дії для всіх тест-кейсів. Таким чином дані з перших трьох колонок і будуть матрицею відповідності вимог.
Наведений вище документ встановлює трасування між BR, TR та сценаріями тестування. Створивши подібний документ, ми переконаємось, що всі аспекти початкових вимог були взяті до уваги командою тестування для створення своїх наборів тестів.
Як правило, будь-які порожні місця в матриці є потенційними областями для дослідження.
Переваги матриці відповідності вимог
- підтверджує 100% покриття тесту;
- підкреслює будь-які відсутні вимоги або невідповідності документів;
- показує загальні дефекти або стан виконання з акцентом на бізнес-вимоги;
- допомагає проаналізувати або оцінити вплив на роботу команди QA щодо повторного перегляду або повторної роботи над тестовими випадками.
Важливо зауважити, що спосіб підтримки та оновлення матриці відповідності визначає ефективність її використання. Якщо інструмент не оновлюється часто або оновлюється неправильно, тоді він стає тягарем, а не допоміжним засобом.
