Requirement Traceability Matrix (RTM) là gì và tạo RTM để đảm bảo test coverage như thế nào?

Bạn có đảm bảo việc test đã cover được hết các case. Sau tất cả, khách hàng không muốn bỏ qua giai đoạn testing và đối mặt với những lỗi user sẽ gặp phải khi sử dụng ứng dụng. Vây cái gì là cơ bản trong test coverage? Và đó là requirements: functional, non-functional - và mọi yêu cầu mà cần được test. Tuy nhiên trong quá trình kiểm thử, có thể team kiểm thử mắc một nhầm lẫn nào đó hay miss một requirement và không viết TCs cho nó. Do đó làm thế nào để Manager có thể quản lý được? Câu trả lời ở đây là Requirement Traceability Matrix.

Requirement Traceability Matrix là gì?

Một ma trận truy xuất nguồn gốc các requirement(RTM) là một tài liệu đồng liên quan bất kỳ hai tài liệu cơ bản đòi hỏi một mối quan hệ nhiều-nhiều để kiểm tra tính đầy đủ của các mối quan hệ. Nghĩa là để đảm bảo rằng tất cả mọi thứ trong phạm vi của các tài liệu có liên quan, nó được sử dụng để theo dõi các yêu cầu và kiểm tra các yêu cầu này đã được đáp ứng đủ hay chưa.

Đơn giản hơn, RTM là một tài liệu cập nhật các yêu cầu và được đối chiếu với việc kiểm định hệ thống (test cases). Nó đảm bảo rằng tất cả các yêu cầu của khách hàng đều được team kiểm thử viết TCs thực hiện đầy đủ trong quá trình kiểm thử.

Mục đích: Xác định bất cứ điều gì mà không được liên kết trong hai văn bản, từ đó yêu cầu sẽ được phân tích thêm.

Các loại Requirement Traceability Matrix

• Truy xuất xuôi: Forward traceability (Building the right product)

Thứ tự: Requirement IDs >> Test Scenario IDs >> Test cases IDs >> Defect IDs.

• Truy xuất ngược: Backward or reverse traceability (Building the Product right):

Thứ tự chỉ cần đảo ngược thành: Defect IDs >> Test cases IDs (all) >> Test Scenario IDs (all) >> Requirement IDs.

Mục đích là đảm bảo rằng mọi thứ đã phát triển sẽ có một yêu cầu tương ứng và không có gì thêm.

Có thể như bạn đã đoán, Requirement Traceability Matrix là một phân tích hai chiều những lỗ hổng (không được liên kết) ở mỗi bước (requirement, test scenarios, test cases and defects)

Mục đích của Requirement Traceability Matrix

• Sự tin tưởng của khách hàng: Đầu tiên và quan trọng nhất là xây dựng lòng tin của khách hàng rằng sản phẩm đang được phát triển và kiểm thử theo yêu cầu.
• Đảm bảo độ bao phủ tuyệt đối: Tất cả requirement cần phải được bao phủ trong Test Design và trong quá trình thực hiện test. Mục đích là đảm bảo cover được 100% trường hợp kiểm thử.
• Theo dõi thay đổi yêu cầu: Duy trì trong suốt vòng đời của việc phát hành, thay đổi các yêu cầu này cũng được ghi lại và theo dõi trong RTM.
• Quản lý rủi ro: đảm bảo rằng mỗi requirement có thể được test và cuối cùng phải được test.
• Phát hiện và đề xuất chức năng bị miss.
• Tasks: Trợ giúp trong việc tạo ra các tài liệu về yêu cầu, spec, các tài liệu bàn giao, và plan dự án.

• Khả năng bảo trì: Bất kỳ sự thay đổi yêu cầu nào đều có thể theo dõi được để cập nhật trong Test Design.
• Bám theo scope: Sử dụng việc đảo ngược việc truy xuất để đảm bảo rằng không có kiểm thử thêm nào được thực hiện mà không có một yêu cầu tương ứng
• Đánh dấu bất kỳ yêu cầu không rõ ràng (thiếu)
• Chất lượng sản phẩm: Phạm vi kiểm thử và tình trạng lỗi tương ứng tìm ra tạo thêm niềm tin cho khách hàng về chất lượng của sản phẩm.
• Ước tính yêu cầu thay đổi: Sử dụng RTM, Test Manager có thể dễ dàng đánh giá tác động và số lượng công việc cần thiết nếu có bất kỳ yêu cầu thay đổi nào.
• Chất lượng của thành phần: Cần đánh giá được các component nào có nguy cơ xảy ra nhiều lỗi nhất, một cách khác để đánh dấu các khu vực có nguy cơ cao cần được kiểm tra kỹ hơn.

Steps

1. Nhận các tài liệu yêu cầu đặc tả kỹ thuật
2. Liệt kê tất cả các requirements trong một file excel (Req. ID & Description)
3. Thêm một column cho biết yêu cầu có thể kiểm thử hay không - đánh dấu để team kinh doanh biết nếu có điều gì không thể kiểm thử.
4. Phát triển Test Scenarios và Test cases
5. Cập nhật Requirement Traceability Matrix, i.e. Requirement IDs (all) >> Test scenario IDs (all) >> Test cases IDs (all)
6. Hoàn thiện Requirement Traceability Matrix
7. Xác minh RTM để xác định bất kỳ lỗ hổng nào - bất kỳ yêu cầu, kịch bản kiểm thử hoặc test case không liên quan đến một phần nào cả.
8. Tiến hành test theo Test cases và raise lên các lỗi (nếu có)
9. Cập nhật RTM, i.e. Requirement IDs >> Test scenarios IDs >> Test cases IDs >> Defect IDs
10. Re-test lại toàn bộ các lỗi khi đã được fix (once fixed)
11. Cập nhật RTM, i.e. Requirement IDs >> Test scenarios IDs >> Test cases IDs >> Defect IDs (bao gồm độ ưu tiên, tầm quan trọng & trạng thái)
12. Hoàn thiện và chia sẻ RTM bao gồm bất kỳ những hiểu biết (lưu giữ trong tâm trí các mục đích như đã đề cập ở trên) Finalize & share the RTM including any insights (keeping in mind the purpose as mentioned above)
13. Tiếp tục duy trì RTM khi có bất kỳ thay đổi và đánh giá tiếp theo.

Format của RTM

RTM có thể được tạo ra và duy trì bằng một công cụ tự động (ví dụ HP QC), bằng một bảng tính Excel, hoặc một table trong MS Word. RTM sẽ bao gồm các thông số sau:

• Requirement ID
• Requirement description
• Testable (Y / N)
• Module / Sub-Module
• Scenario IDs
• Test Cases ID
• Defect IDs
• Status
• Remarks

Tạo Requirement Traceability Matrix cho dự án ngân hàng Guru99

Để hiểu rõ khái niệm của RTM hãy cùng thực hành thông qua một dự án ngân hàng Guru99. Trên cơ sở các tài liệu yêu cầu nghiệp vụ (Business Requirement Document - BRD) và tài liệu yêu cầu kỹ thuật (Technical Requirement Document - TRD), các tester bắt đầu tạo TCs.

Giả sử bảng dưới đây là tài liệu BRD cho dự án ngân hàng Guru99. Yêu cầu là khách hàng được đăng nhập vào trang web của ngân hàng Guru99 với mật khẩu và user#id. Manager có thể đăng nhập vào các trang web thông qua trang đăng nhập của khách hàng.

Business Requirement Document (BRD)

Technical Requirement Document (TRD)

Note: Trường hợp team QA không có tài liệu BRD và TRD thì ở một số công ty có thể sử dụng tài liệu Yêu cầu Chức năng (Funtion Requirement Documents - FRD) tương tự như tài liệu Yêu cầu kỹ thuật (Technical Requirement Document - TRD) để tạo ra ma trận truy xuất nguồn gốc mà RTM vẫn không có sự thay đổi. Hãy tiếp tục và bắt tay vào tạo RTM

Step 1: Test Case được xác định là: "Xác nhận đăng nhập, khi nhập đúng user ID và mật khẩu thì sẽ đăng nhập thành công"

Step 2: Xác định Yêu cầu kỹ thuật cho TC ở trên. Ở đây chúng ta xác định được yêu cầu kỹ thuật là T94.

Step 3: Ghi chú Technical Requirement (T94) vào trong file Test Case.

Step 4: Xác định yêu cầu kinh doanh (Business Requirement) cho yêu cầu kỹ thuật đã được định nghĩa (Technical Requirement-T94)

Step 5: Ghi chú BR (Business Requirement) vào trong file Test Case

Step 6: Thực hiện tương tự như trên cho tất cả các Test case. Sau đó tách ra 3 Column đầu tiên trong Test Suite. RTM đã hoàn thành!

Nguồn tham khảo:

http://www.guru99.com/traceability-matrix.html http://www.softwaretestingstudio.com/requirement-traceability-matrix-rtm-qa