Ma trận truy xuất nguồn gốc yêu cầu (RTM - Requirements Traceability Matrix) là gì?

A traceability matrix is a document that details the technical requirements for a given test scenario and its current state. It helps the testing team understand the level of testing that is done for a given product. The traceability process itself is used to review the test cases that were defined for any requirement.

Định nghĩa

Requirement Traceability Matrix (RTM) trong kiểm thử phần mềm  được sử dụng để chứng minh rằng sản phẩm đã được kiểm thử và "Đạt". RTM ghi lại các Test Case, Test Run và Test Result.

RTM cũng cung cấp số liệu lịch sử thống kê những Test Case nào đã run và tỉ lệ pass/fail, tần xuất run... , từ đó xác định các "điểm nóng" cần phải đưa vào danh sách theo dõi và khoanh vùng, cô lập.

Requirement Traceability Matrix (RTM)​​​​​​​ trong kiểm thử phần mềm 

Mục tiêu của Traceability Matrix

  • Nó giúp truy tìm các tài liệu được phát triển trong các giai đoạn khác nhau của SDLC.
  • Nó đảm bảo rằng phần mềm hoàn toàn đáp ứng các requirement của khách hàng.
  • Nó giúp phát hiện nguyên nhân gốc rễ của bất kỳ lỗi nào.

Có thể nói, RTM là một tài liệu quan trọng của dự án để lập bản đồ và theo dõi các requirement của người dùng với các Test Case để đảm bảo rằng cho mọi requirement ở tất cả mức độ kiểm thử đều đạt được.

Quá trình xem xét tất cả các Test Case được xác định cho bất kỳ requirement nào được gọi là truy xuất nguồn gốc. Truy xuất nguồn gốc cho phép xác định các requirement nào sinh ra nhiều lỗi nhất trong quá trình kiểm thử.

Trọng tâm của bất kỳ cam kết kiểm thử nào cũng nên đạt độ bao phủ tối đa. Nghĩa là tất cả mọi thứ đều phải được kiểm thử. Mục đích của bất kỳ dự án kiểm thử nào cũng phải là phạm vi kiểm tra 100%.

RTM thiết lập một cách để đảm bảo bao phủ tất cả requirement. Nó giúp tạo ra một ảnh chụp nhanh để xác định khoảng trống bao phủ. Nó cũng có thể được gọi là một metrics xác định số lượng Test Case đã chạy qua, Pass or Fail .. cho mọi requirement.

Tại sao cần phải truy xuất nguồn gốc?

Ma trận truy xuất (RTM) giúp liên kết các yêu cầu (requirement), kịch bản kiểm thử (Test Case) và lỗi xảy ra một cách chính xác. Toàn bộ ứng dụng được kiểm tra bằng cách truy xuất nguồn gốc yêu cầu.

Truy xuất nguồn gốc đảm bảo ‘chất lượng’ được đáp ứng đầy đủ của ứng dụng vì tất cả các tính năng đều được kiểm tra, không bỏ sót một tính năng nào. Kiểm soát chất lượng có thể đạt được khi phần mềm được kiểm tra cho các tình huống không lường trước được với các lỗi nhỏ nhất và tất cả các yêu cầu chức năng và phi chức năng được thỏa mãn.

Thí dụ bảng mapping lỗi với Test Case và Requirement

Business Requirement Test Scenario Test Case Defects
BR1 TS1 TS1.TC1, TS1.TC2 D01
BR2 TS2 TS2.TC1, TS2.TC2, TS2.TC3 D02 , D03
BR3 TS3 TS1.TC1, TS2.TC1, TS3.TC1,TS3.TC2 NIL

Ma trận truy xuất yêu cầu giúp cho sản phẩm phần mềm được kiểm thử đầy đủ và kịp thời trong khoảng thời gian quy định, phạm vi của dự án (được xác định rõ) và phù hợp với nhu cầu đáp ứng tính năng của khách hàng cũng như nhu cầu kiểm soát tốt chi phí của dự án.

Các loại Ma trận truy xuất (Traceability Matrix)

Traceability Matrix có thể được phân loại thành 3 loại khác nhau:

  1. Forward traceability (Truy xuất nguồn gốc thuận)
  2. Backward or reverse traceability (Truy xuất nguồn gốc ngược)
  3. Bi-directional traceability (Truy xuất nguồn gốc hai chiều)
software testing traceability matrix
Ảnh minh họa: testbytes.net

Truy xuất thuận (Forward Traceability)

Forward Traceability đảm bảo rằng dự án tiến triển theo hướng mong muốn và mọi requirement đều được kiểm tra kỹ lưỡng.

Truy xuất ngược (Backward Traceability)

Các trường hợp kiểm tra được ánh xạ (mapping) với các requirement trong 'Truy xuất ngược lại'. Mục đích chính là đảm bảo rằng sản phẩm hiện tại đang được phát triển đang đi đúng hướng. Nó cũng giúp xác định rằng không có thêm "chức năng không xác định" được thêm vào và do đó phạm vi của dự án bị ảnh hưởng.

Truy xuất hai chiều kết hợp (Bi-Directional Traceability: Forward + Backward)

Một ma trận truy xuất tốt có tham chiếu từ các Test Case đến Requirement và ngược lại (các requirementđối với các Test Case). Điều này được gọi là truy xuất nguồn gốc hai chiều. Nó đảm bảo rằng tất cả các trường hợp kiểm thử có thể được truy xuất theo yêu cầu gốc và mỗi requirement được chỉ định có các Test Case chính xác và hợp lệ cho chúng.

Template ma trận truy xuất nguồn gốc

Dưới đây là mẫu của RTM:

RTM Template

Requirements Traceability Matrix

Test Coverage and Requirement Traceability (Độ bao phủ kiểm thử và truy xuất nguồn gốc yêu cầu)

Test Coverage là gì?

Độ bao phủ kiểm thử (Test Coverage) hay phạm vi kiểm thử được xác định khi bắt đầu giai đoạn kiểm thử. Nó xác định xem các Test Case được viết và thực thi có đảm bảo kiểm tra hoàn toàn ứng dụng phần mềm hay không.

Làm thế nào để đạt được Test Coverage?

Test Coverage có thể đạt được bằng cách sử dụng ‘Requirement Traceability’ (Truy xuất nguồn gốc yêu cầu)

  • Ánh xạ tất cả lỗi nội bộ với Test Case.
  • Ánh xạ lỗi mà khách hàng report với Test Case để tạo bộ kiểm thử hồi quy (regression testing) trong tương lai.

Benefits

Sau đây là những lợi ích của RTM:

  • Được sử dụng để xác định và truy xuất nhanh các requirement còn thiếu trong tài liệu.
  • Đảm bảo phạm vi kiểm tra đạt độ phủ 100%.
  • Là công cụ để đánh giá mức độ trung thực của đội ngũ kiểm thử
  • RTM giống như sổ kế toán, mọi con số do đội kiểm thử đưa vào (cố ý hay vô ý) đều chứa đứng mâu thuẫn trong nó. Đơn vị giám sát dễ dàng phát hiện hành vi làm việc gian dối, không chuyên nghiệp của đơn vị phát triển phần mềm.

Limitations

Những thách thức đặt ra với RTM

  • Các requirement phải được làm rõ chi tiết, đầy đủ, chính xác và không được mập mờ (unambitious).

  • Requirement có thể bị thiếu, tiềm ẩn hoặc không được ghi lại trong quá trình làm việc với khách hàng.

  • Requirement không được đơn vị tư vấn "đầu bài" xây dựng đầy đủ, dẫn đến thiếu nhiều luồng nghiệp vụ (luồng con, luồng ẩn), dẫn đến các tính năng không thực sự đầy đủ, khép kín.

  • ‘BA (Bussiness Analysis)’ hoặc ‘Product Owner’ phải có kinh nghiệm và chuyên môn vững về phát triển phần mềm chuyên nghiệp để có thể giải thích quy trình với các bên liên quan.

  • Quan điểm của người dùng cuối không được xem xét vì nhiều lý do và các bên liên quan nghĩ rằng họ “hoàn toàn” hiểu những gì cần thiết cho một sản phẩm.

Kết Luận

RTM giống như sổ kế toán của dự án, sẽ rất khó để "chế" các con số chỉ để báo cáo hình thức cho các bên liên quan. Đội ngũ kiểm thử cần phải làm việc nghiêm túc để cung cấp con số đánh giá chất lượng cho các bên liên quan. Mọi con số do đội kiểm thử đưa vào (cố ý hay vô ý) đều chứa đứng mâu thuẫn trong nó. Đơn vị giám sát dễ dàng phát hiện hành vi làm việc gian dối, không chuyên nghiệp của đơn vị phát triển phần mềm.