Phân tích nguyên nhân gốc (RCA) cho Tester: 5 Whys, xương cá & phòng ngừa qua sự cố tính cước viễn thông (có trắc nghiệm)

1. Tóm tắt nhanh & màn hình bạn sẽ phân tích

Chào bạn! Khi một sự cố nghiêm trọng xảy ra — như khách hàng bị tính cước sai — phản xạ đầu tiên thường là 'sửa cho nhanh': bù tiền lại cho khách, vá một dòng code, đóng ticket. Nhưng nếu chỉ dừng ở đó, rất có thể tháng sau một khách hàng khác lại gặp đúng lỗi tương tự. Phân tích nguyên nhân gốc (RCA) là kỹ năng nâng cao giúp bạn — với vai trò tester — không chỉ tìm ra 'lỗi nằm ở đâu' mà còn trả lời được 'vì sao lỗi này lọt qua được toàn bộ quy trình', từ đó ngăn nó xảy ra lần nữa ở bất kỳ đâu trong hệ thống.

2. Vì sao tester cần thạo RCA, không chỉ báo lỗi

Nhiều tester dừng lại ở việc mô tả TRIỆU CHỨNG thật chi tiết: bước tái hiện, kết quả mong đợi, kết quả thực tế, bằng chứng. Đó là nền tảng cần thiết, nhưng ở cấp độ nâng cao — đặc biệt với các hệ thống có ảnh hưởng tiền bạc như tính cước viễn thông — công việc của bạn không dừng ở việc phát hiện lỗi mà còn là giúp tổ chức hiểu VÌ SAO lỗi này có thể xảy ra và làm sao ngăn những lỗi cùng loại trong tương lai.

Một tester biết làm RCA mang lại giá trị khác hẳn: thay vì báo cáo rời rạc từng ticket, bạn cung cấp bức tranh về LOẠI nguyên nhân đang lặp lại (ví dụ: nhiều sự cố gần đây đều xuất phát từ thiếu ca kiểm thử biên ở các luồng 'giữa kỳ'). Thông tin này giúp quản lý ưu tiên đầu tư đúng chỗ — có thể là đào tạo thêm về thiết kế ca biên, siết lại quy trình review đặc tả, thay vì chỉ tuyển thêm người vá lỗi.

Nói ngắn gọn: viết bug report tốt cho biết 'điều gì đang sai'; làm RCA tốt cho biết 'vì sao nó sai và làm sao để nó không sai nữa'. Đây là kỹ năng phân biệt tester cấp cao với tester chỉ dừng ở việc phát hiện lỗi đơn lẻ.

3. Kỹ thuật 5 Whys — truy ngược từng lớp nguyên nhân

5 Whys là kỹ thuật đơn giản nhưng mạnh: bắt đầu từ triệu chứng, hỏi 'tại sao điều này xảy ra?', rồi lấy câu trả lời làm câu hỏi kế tiếp, lặp lại cho tới khi chạm tới một nguyên nhân mà bạn có thể HÀNH ĐỘNG được (sửa quy trình, bổ sung ca kiểm thử, cập nhật đặc tả) — không phải một câu trả lời chung chung như 'do con người bất cẩn'.

Nhìn vào bảng trên, bạn thấy mỗi 'Why' đào sâu thêm một lớp: từ hiện tượng bề mặt (khách bị tính dư tiền), tới hành vi hệ thống (cộng trùng ngày), tới lỗi kỹ thuật cụ thể (công thức làm tròn sai), tới nguyên nhân quy trình (đặc tả không rõ ràng), và cuối cùng tới nguyên nhân gốc thật sự (thiếu ca kiểm thử biên cho luồng đổi gói cuối kỳ ngay từ giai đoạn thiết kế yêu cầu). Nếu bạn dừng lại ở Why 2 hoặc Why 3, bạn sẽ chỉ sửa được TRIỆU CHỨNG chứ chưa chạm tới gốc rễ.

4. Biểu đồ xương cá (Ishikawa) — phân loại nguyên nhân theo 5 nhóm

5 Whys giỏi trong việc đào SÂU một chuỗi nguyên nhân, nhưng nếu chỉ đi theo một hướng, bạn có thể bỏ sót các nguyên nhân song song ở nhóm khác. Biểu đồ xương cá (fishbone/Ishikawa) bù đắp điểm này: nó liệt kê TẤT CẢ các nhóm nguyên nhân có thể liên quan quanh một 'sự cố' (effect), giúp bạn rà soát rộng trước khi đào sâu vào từng nhánh bằng 5 Whys.