Ma trận truy vết yêu cầu (RTM) nâng cao cho Tester: xây RTM 2 chiều trên CRM doanh nghiệp (có trắc nghiệm)

1. Tóm tắt nhanh & bức tranh toàn cảnh RTM

Với tester đã quen thiết kế ca kiểm thử đơn lẻ, RTM là bước nâng lên tầm quản lý CHẤT LƯỢNG THEO PHẠM VI: thay vì hỏi 'ca này test cái gì', RTM giúp bạn trả lời câu hỏi lớn hơn — 'toàn bộ yêu cầu của release này đã được kiểm thử đầy đủ chưa, ở đâu còn lỗ hổng, cái gì đang lãng phí công sức'. Đây là công cụ bắt buộc trong các dự án doanh nghiệp có audit, có hợp đồng SLA, hoặc chuẩn CMMI/ISO nơi 'chứng minh được đã test cái gì' quan trọng ngang 'đã test đúng chưa'.

2. RTM 2 chiều: forward vs backward traceability

RTM cơ bản chỉ có 1 chiều: liệt kê mỗi yêu cầu kèm test case tương ứng. RTM nâng cao BẮT BUỘC có 2 chiều hoạt động song song. Forward traceability trả lời 'yêu cầu X được kiểm thử bởi những ca nào' — chiều này dùng để tính % độ phủ yêu cầu và tìm ra 'yêu cầu chưa test'. Backward traceability trả lời 'test case Y đang bảo vệ yêu cầu nào' — chiều này dùng để tìm 'test case mồ côi': ca kiểm thử vẫn chạy trong bộ hồi quy nhưng không còn gắn với yêu cầu hợp lệ nào, thường do yêu cầu đã bị xoá/gộp/thay thế mà không dọn dẹp test tương ứng.

Trong ví dụ BizConnect CRM ở chương 1: REQ-114 (chuyển cấp ticket quá SLA) là lỗ hổng phát hiện bằng chiều forward — yêu cầu tồn tại nhưng không có test case nào trỏ tới. TC-2270 (kiểm tra xuất PDF song ngữ) là lỗ hổng phát hiện bằng chiều backward — test case tồn tại, chạy đều đặn, nhưng không truy ngược được về yêu cầu nào còn hiệu lực. Hai loại lỗ hổng này có bản chất khác nhau: loại 1 là RỦI RO CHƯA BIẾT (unknown risk vì chưa test), loại 2 là LÃNG PHÍ (waste vì tốn công bảo trì cho thứ không còn giá trị) — cả hai đều cần được RTM phơi bày định kỳ.

3. Vì sao tester nâng cao cần thạo RTM trên hệ thống lớn

Ở quy mô một tính năng nhỏ, tester có thể nhớ trong đầu 'tính năng này đã test những gì'. Nhưng BizConnect CRM có hàng chục module (liên hệ, cơ hội bán hàng, ticket hỗ trợ, hợp đồng, báo cáo, phân quyền theo chi nhánh) với hàng trăm yêu cầu qua nhiều release — trí nhớ cá nhân không còn đủ tin cậy. RTM biến 'niềm tin đã test đủ' thành BẰNG CHỨNG có thể kiểm chứng: bất kỳ ai, kể cả người mới vào dự án, tra RTM là biết ngay yêu cầu nào an toàn, yêu cầu nào còn rủi ro.

RTM còn là công cụ giao tiếp giữa Test, BA (Business Analyst) và khách hàng doanh nghiệp: khi khách hỏi 'các bạn đã kiểm thử tính năng chuyển cấp SLA chưa, kiểm thử những trường hợp nào', đội dự án có thể trích trực tiếp từ RTM thay vì phải tổng hợp thủ công — điều này đặc biệt quan trọng với CRM doanh nghiệp nơi khách hàng thường yêu cầu bằng chứng kiểm thử (test evidence) như một phần nghiệm thu hợp đồng.

Cuối cùng, RTM là nền tảng cho đánh giá tác động thay đổi (change impact analysis) — kỹ năng phân biệt tester nâng cao với tester mới: khi một yêu cầu bị sửa, tester nâng cao không chạy lại TOÀN BỘ bộ test (tốn thời gian, không hiệu quả) cũng không chỉ chạy lại đúng ca liên quan trực tiếp (bỏ sót ảnh hưởng gián tiếp), mà dùng RTM để xác định CHÍNH XÁC phạm vi các test case và yêu cầu liên đới cần rà soát lại.

4. Chuẩn bị: cấu trúc RTM & quy tắc đặt ID

Trước khi xây RTM cho BizConnect CRM, cần thống nhất cấu trúc cột và quy tắc đặt ID để mọi thành viên (Test, BA, Dev) tra cứu nhất quán, tránh tình trạng mỗi người một kiểu đặt tên khiến RTM không thể tự động hoá về sau.

▶ Bước 1: Thống nhất quy tắc ID: REQ-xxx cho yêu cầu, TC-xxxx cho test case, và mã defect theo hệ thống theo dõi lỗi hiện có (ví dụ CRM-xxxx trên Jira).

▶ Bước 2: Định nghĩa các cột bắt buộc của RTM: Req ID, Mô tả yêu cầu, Mức ưu tiên, TC ID liên kết, Trạng thái TC (Pass/Fail/Chưa chạy), Defect liên kết, Trạng thái phủ.