Get in touch
or send us a question?
CONTACT

Risk-based Testing – Kiểm thử dựa trên rủi ro cho Tester hiện đại

rong các dự án phần mềm lớn, việc “test tất cả mọi thứ” gần như là điều không thể. Thời gian release ngắn, phạm vi chức năng rộng và tài nguyên tester có hạn buộc chúng ta phải đưa ra quyết định:

👉 Test cái gì trước? Test cái gì sâu? Test cái gì có thể giảm?

Đó chính là lúc Risk-based Testing trở thành một kỹ năng quan trọng của Tester, đặc biệt ở cấp độ Middle trở lên.


1. Risk-based Testing là gì?

Risk-based Testing là phương pháp kiểm thử trong đó:

Phạm vi, độ sâu và thứ tự kiểm thử được quyết định dựa trên mức độ rủi ro của từng chức năng.

Nói đơn giản:

  • Chức năng rủi ro cao → test kỹ, test nhiều

  • Chức năng rủi ro thấp → test vừa đủ

Mục tiêu không phải là test nhiều nhất, mà là giảm rủi ro cho sản phẩm nhiều nhất.


2. Rủi ro trong phần mềm là gì?

Trong kiểm thử, rủi ro thường được hiểu là:

Khả năng xảy ra lỗi × Mức độ ảnh hưởng nếu lỗi xảy ra

Một chức năng có thể rủi ro cao vì:

  • Nó dễ phát sinh lỗi

  • Hoặc nếu lỗi xảy ra thì hậu quả rất lớn

Hoặc cả hai.


3. Các yếu tố giúp xác định rủi ro

3.1 Mức độ ảnh hưởng đến người dùng

Ví dụ:

  • Thanh toán lỗi → rủi ro cực cao

  • Trang giới thiệu công ty lỗi → rủi ro thấp

3.2 Tần suất sử dụng

  • Màn hình login dùng mỗi ngày → rủi ro cao

  • Màn hình settings hiếm khi mở → rủi ro thấp

3.3 Độ phức tạp kỹ thuật

  • Logic tính tiền, giảm giá → rủi ro cao

  • Trang hiển thị text tĩnh → rủi ro thấp

3.4 Khu vực thay đổi nhiều

  • Module vừa refactor → rủi ro cao

  • Module ổn định lâu → rủi ro thấp

3.5 Lịch sử bug

  • Nơi từng phát sinh nhiều bug → có khả năng bug lặp lại


4. Cách áp dụng Risk-based Testing trong thực tế

Bước 1: Liệt kê các chức năng chính

Ví dụ:

  • Login

  • Thanh toán

  • Giỏ hàng

  • Profile

  • Notification


Bước 2: Đánh giá rủi ro cho từng chức năng

Có thể chấm điểm theo 2 tiêu chí:

  • Impact (mức ảnh hưởng)

  • Probability (khả năng xảy ra lỗi)

Ví dụ:

Chức năng Impact Probability Risk
Payment 5 4 Rất cao
Login 4 4 Cao
Profile 3 2 Trung bình
About page 1 1 Thấp

Bước 3: Phân bổ effort test

  • Risk cao → test sâu, nhiều test case, nhiều dữ liệu

  • Risk trung → test đủ coverage

  • Risk thấp → smoke test là đủ

👉 Đây là cách giúp tester tối ưu effort nhưng vẫn đảm bảo chất lượng.


5. Lợi ích của Risk-based Testing

✔ Giảm thời gian test nhưng vẫn kiểm soát chất lượng

Tester không lãng phí thời gian vào khu vực ít quan trọng.

✔ Giúp team tập trung vào giá trị kinh doanh

Không phải lỗi nào cũng quan trọng như nhau.

✔ Hỗ trợ quyết định release

Khi deadline gần, risk analysis giúp trả lời:

  • Có thể release được không?

  • Rủi ro chấp nhận được là gì?


6. Sai lầm phổ biến khi áp dụng Risk-based Testing

❌ Chỉ Tester tự đánh giá rủi ro

Risk phải được đánh giá cùng:

  • Product Owner

  • Developer

  • Business


❌ Chỉ nhìn rủi ro kỹ thuật

Nhiều tester chỉ nhìn:

  • Logic phức tạp

  • Code mới

Nhưng quên rằng:
👉 Rủi ro kinh doanh mới là quan trọng nhất.


❌ Không cập nhật rủi ro theo Sprint

Risk thay đổi theo:

  • Feature mới

  • Code thay đổi

  • Production issue

Risk list cần được cập nhật liên tục.


7. Risk-based Testing là dấu hiệu của Tester trưởng thành

Tester mới thường hỏi:

“Mình phải test hết chứ?”

Tester có kinh nghiệm sẽ hỏi:

“Nếu chỉ test được 30%, mình nên test cái gì trước?”

Đây chính là sự khác biệt giữa:

  • Người làm theo checklist

  • Và người đảm bảo chất lượng sản phẩm


8. Kết luận

Risk-based Testing không phải là test ít đi, mà là test thông minh hơn.

Trong môi trường Agile và release nhanh, Tester cần:

  • Biết đánh giá rủi ro

  • Biết ưu tiên test

  • Biết chấp nhận rủi ro hợp lý

👉 Một Tester giỏi không phải người test nhiều nhất, mà là người giảm rủi ro cho sản phẩm nhiều nhất.