Матриця трасування (RTM - Requirement Traceability Matrix)
Трасування (traceability): Здатність ідентифікувати пов'язані об'єкти в документації та програмному забезпеченні, наприклад, вимоги з пов'язаними з ними тестами. (ISTQB)
Матриця трасування (traceability matrix): Двовимірна таблиця, що описує зв'язок двох сутностей (наприклад, вимог і тестових сценаріїв). Таблиця дозволяє проводити пряме і зворотне трасування від однієї сутності до іншої, забезпечуючи таким чином можливість визначення покриття та оцінки впливу передбачуваних змін. (ISTQB)
У тестуванні багато можна представити у вигляді зручної та наочної матриці (таблиці): Requirement Traceability Matrix, Test matrix, Compliance Matrix, Risk Matrix, RACI Matrix і т.д.
Матриця трасованості (Requirement Traceability Matrix AKA Traceability Matrix or Cross Reference Matrix) використовується для документування зв'язків між вимогами та тест-кейсами за цими вимогами та наочного відображення трасування у вигляді простої таблиці.
Матриця трасування може служити одночасно як матриця покриття. Наявність такої матриці дає змогу об'єктивно оцінити, яка частина продукту покрита тестами, а яка ні.
Види трасування :
Вертикальна трасування (vertical traceability): Відстеження вимог через рівні розробки до компонентів. (ISTQB)
Горизонтальна трасування (horizontal traceability): Трасування вимог до рівня тестування стосовно рівнів документації (наприклад, план тестування, специфікація проектування тесту, специфікація тестових сценаріїв та специфікація процедури тестування або автоматизований сценарій тестування). (ISTQB)
Інше джерело:
Пряма трасируемость (Forward Traceability): гарантує, що проект просувається у бажаному напрямі та що кожна вимога ретельно перевіряється;
Зворотна трасування (Backward Traceability): гарантує, що поточний продукт знаходиться на правильному шляху. Це також допомагає визначити, що додаткові невказані функції не додаються і, отже, не впливає на обсяг проекту;
Двонаправлена трасування (Bi-Directional Traceability = Forward + Backward): містить посилання від тестових прикладів до вимог і навпаки. Це гарантує, що всі тестові приклади можна відстежити до вимог, і кожна зазначена вимога містить точні та дійсні приклади для них.
RTM є актуальною на всіх етапах програмного проекту. Давайте розберемося з цим через водоспадну модель SDLC:
RTM починається разом із початком фази збору вимог (Requirements Gathering phase);
продовжується через управління вимогами (Requirements Management);
проектування (Design);
розробку (Development);
тестування (Testing);
використання (Implementation);
та підтримку (Support).
При проходженні цих етапів трасируемость вимог підтримується з допомогою цього документа. Після того, як вимоги були внесені до таблиці, деталі дизайну цих вимог будуть зіставлені з вимогами. На основі цих деталей проекту проводитиметься розробка програмного забезпечення/модуля. Деталі репозиторію коду із SVN, TFS, Bitbucket, Github будуть зіставлені. Тепер ви знаєте, де знаходиться дизайн та код кожної вимоги. Це трасування. Відстежуйте кожну вимогу від початку до кінцевого результату в міру його використання користувачем програми! На етапі підтримки RTM буде надзвичайно корисний для розуміння та вирішення проблем, пройшовши через усі відповідні деталі функції/вимоги. Поліпшення функції стало б можливим завдяки відстеженню та розумінню логіки, дизайну та коду. З точки зору володіння RTM, RTM належить менеджерам проекту чи бізнес-аналітикам. В організаціях CMMi команда TQM також перевірятиме це як стандартний результат у проектах програмного забезпечення.
*Коли на основі вимог до продукту складаються тест-сценарії та виконується тестування, це називається Requirement based testing.
Джерела:
Дод. матеріал:
Last updated