Bộ kiểm thử của bạn sẽ trở nên vô dụng nếu không ai tin tưởng vào các lỗi mà nó báo về. Các nhóm thường thêm nhiều bài kiểm thử hơn, dashboard phong phú hơn, hoặc thực hiện chạy song song, nhưng các lập trình viên vẫn cứ chạy lại pipeline với hy vọng ô màu đỏ sẽ biến mất. Thói quen đó biến một tín hiệu tiềm năng có giá trị thành những tiếng ồn gây tốn kém.

Vấn đề thực sự nằm ở sự tin tưởng, không phải ở độ bao phủ

Hầu hết các nhóm kỹ thuật thường đổ lỗi cho việc thiếu bài kiểm thử hoặc độ bao phủ trình duyệt không đủ. Thực tế, các lỗi thường bị coi là nhiễu. Một tỷ lệ vượt qua 96% trông có vẻ ấn tượng trên dashboard, nhưng nó không cho bạn biết liệu 4% lỗi đó là những khiếm khuyết thực sự hay chỉ là những lỗi cần phải chạy lại nhiều lần mới xuất hiện. Khi các lập trình viên phớt lờ các lỗi, bộ kiểm thử sẽ tiêu tốn thời gian và tài nguyên tính toán mà không hề ảnh hưởng đến các quyết định.

Tại sao tỷ lệ vượt qua có thể gây hiểu lầm

Các chỉ số tỷ lệ vượt qua gộp tất cả kết quả thành một con số duy nhất, che giấu đi hai câu hỏi quan trọng:

  • Các lỗi có tiết lộ các khiếm khuyết thực sự không? Một bài kiểm thử chập chờn (flaky test) mà không bao giờ bắt được lỗi thì chẳng mang lại giá trị gì.
  • Cần bao nhiêu lần chạy lại? Một bộ kiểm thử vượt qua sau ba lần chạy lại tự động là không đáng tin cậy, ngay cả khi tỷ lệ vượt qua cuối cùng là cao.

Một bộ kiểm thử báo cáo tỷ lệ thành công 99% nhưng liên tục bỏ lỡ các lỗi thanh toán (checkout failures) thì tệ hơn nhiều so với một bộ kiểm thử chỉ vượt qua 92% thời gian nhưng bắt được mọi lỗi ảnh hưởng đến doanh thu. Mục tiêu không phải là một con số phần trăm cao ngất ngưởng; mục tiêu là khả năng đánh giá rủi ro tốt hơn.

Các chỉ số quan trọng

Hãy thay thế việc tập trung vào tỷ lệ vượt qua bằng các phép đo phản ánh tính hữu dụng của bộ kiểm thử:

  • Sự lặp lại của lỗi – tần suất một bài kiểm thử gặp lỗi trong các lần chạy liên tiếp.
  • Tỷ lệ phát hiện khiếm khuyết – tỷ lệ các lỗi trở thành các bug đã được xác nhận.
  • Thời gian chẩn đoán – một bài kiểm thử thất bại có thể được hiểu và xử lý nhanh đến mức nào.
  • Sự phụ thuộc vào việc chạy lại – tần suất các bài kiểm thử cần chạy lại tự động để vượt qua.
  • Các lỗi hồi quy bị lọt lưới – những khiếm khuyết lọt qua được bộ kiểm thử.

Theo dõi các tín hiệu này sẽ cho bạn biết liệu một lỗi là một cảnh báo có thể hành động hay chỉ là một lỗi chập chờn (flake).

Chi phí bảo trì tiềm ẩn

Một bài kiểm thử mất mười phút để viết nhưng mất ba giờ mỗi tháng để sửa là một khoản đầu tư tồi. Chi phí bảo trì tăng vọt khi các bài kiểm thử không ổn định (fragile), yêu cầu cập nhật dữ liệu liên tục, hoặc phụ thuộc vào các bộ chọn UI (UI selectors) dễ gãy. Chi phí này trở nên rõ rệt khi AI tạo ra các bài kiểm thử. Tốc độ tạo ra không quan trọng nếu các bài kiểm thử được tạo ra bị hỏng mỗi khi UI thay đổi.

Khi đánh giá các bài kiểm thử do AI tạo ra, hãy hỏi:

  • Bài kiểm thử cần chỉnh sửa thủ công thường xuyên đến mức nào?
  • Nó giải thích lý do thất bại rõ ràng đến mức nào?
  • Con người cần bao nhiêu ngữ cảnh để sửa lỗi đó?

Nếu các câu trả lời cho thấy cần sự can thiệp thường xuyên của con người, thì lợi ích của tự động hóa sẽ biến mất.

Khả năng quan sát (Observability): biến các lỗi thành hành động

Một bản log dài 4.000 dòng mất bốn mươi phút để phân tích thì cũng vô dụng như không có bản log nào vậy. Khả năng quan sát tốt cho phép bạn trả lời nhanh ba câu hỏi:

  • Bài kiểm thử đã mong đợi điều gì?
  • Điều gì thực sự đã xảy ra?
  • Nguyên nhân gốc rễ là lỗi sản phẩm, vấn đề dữ liệu hay vấn đề hạ tầng?

Kiểm thử các AI agent đòi hỏi các bước kiểm tra sâu hơn

Khi hệ thống cần kiểm thử là một AI agent, một bài kiểm thử vượt qua có thể che giấu một quy trình nội bộ bị lỗi. Một agent có thể đưa ra câu trả lời đúng bằng cách đi đường tắt sai lầm, chọn sai công cụ, hoặc không cập nhật bộ nhớ một cách chính xác. Do đó, việc kiểm thử đáng tin cậy phải xem xét:

  • Logic lựa chọn công cụ
  • Hành vi cập nhật bộ nhớ
  • Cơ chế phục hồi