[Leader nên đọc] Giám đốc QA – Phần 4: Xây hệ thống niềm tin

Phần 4 trong loạt 5 bài “The Director of QA Dilemma” của Jason Arbon.

AI không xóa sổ nghề testing. Nó chỉ đổi ba câu hỏi cũ thành ba câu hỏi mới: AI test cái gì, test lúc nào, và người đứng đầu QA còn tồn tại để làm gì?

Câu trả lời ngắn gọn: Director of QA phải thôi đi bảo vệ các hoạt động test thuần túy, và bắt đầu thiết kế cái mà doanh nghiệp thực sự cần — đủ cơ sở để dám bấm nút release phần mềm do AI viết ra.

1. Niềm tin không còn là một khâu

Ngày trước, QA giống anh bảo vệ đứng ở cổng nhà máy: hàng ra tới cửa mới kiểm. Code xong thì test, test xong thì release.

Với AI, cái cổng đó vô nghĩa. Hàng được sản xuất quá nhanh, quá nhiều, và bởi những cái máy tự viết ra chính nó. Bằng chứng về chất lượng phải được sinh ra liên tục trên suốt dây chuyền, chứ không dồn vào một điểm cuối.

Nó bắt đầu từ lúc coding agent lập kế hoạch. Rồi kéo dài qua lúc agent sửa code, chọn thư viện, gọi tool, tự sinh test case, chạy thử ứng dụng. Rồi tiếp tục qua code review, staging, shadow traffic, canary, giám sát production, xử lý sự cố — cho đến lần đổi model hoặc đổi prompt kế tiếp.

Không đội ngũ con người nào test tay xuể khối lượng đó. Và cũng không có “vòng hồi quy cuối cùng” nào cứu được một quy trình mà 20 khâu trước đó chẳng để lại bằng chứng gì.

Nên vai trò của QA phải dịch chuyển: từ chỗ chạy test, sang chỗ định hình luật chơi — skill, policy, eval, observability, ngưỡng release, và các kênh đánh giá độc lập trên toàn vòng đời.

Mục tiêu không phải kiểm soát từng bài test. Mục tiêu là thiết kế hệ thống niềm tin cho cả doanh nghiệp.

2. Hệ thống đo lường mới chính là sản phẩm

Tài sản giá trị nhất mà QA sở hữu trong 5 năm tới không phải một test framework. Đó là một hệ thống trả lời được đúng một câu hỏi:

Tại sao doanh nghiệp nên tin vào thay đổi này?

Muốn trả lời, hệ thống phải ghi lại và lưu trữ đầy đủ:

• Đã thay đổi những gì
• Dùng model nào, prompt nào
• Agent nhận được ngữ cảnh gì
• Agent đã gọi những tool nào
• Đã chạy những kịch bản test nào
• Đã mô phỏng nhóm người dùng nào, ở góc rủi ro nào
• Kết quả dao động ra sao giữa các lần chạy
• Đã fail ở đâu, vì sao
• Các reviewer bất đồng ở điểm nào
• Và quan trọng: chỗ nào đang thiếu bằng chứng

Hệ thống đó phải phân biệt được hai thứ nhìn giống hệt nhau trên dashboard nhưng phải xử lý ngược nhau hoàn toàn: lỗi sản phẩm thật (tất định, lặp lại được) và độ nhiễu tự nhiên của model (chạy lại là khác).

Nó phải so được chất lượng giữa các phiên bản mà không tự lừa mình rằng một con số tổng hợp là đủ. Nó phải lôi ra ánh sáng những lỗi nghiêm trọng đang bị con số trung bình che lấp. Và nó phải biến mỗi sự cố production thành một eval case cố định — chứ không dừng ở bản post-mortem nằm chết trong Confluence.

Trên hết, hệ thống phải dẫn tới một hành động cụ thể:

Ship. Canary. Hold. Roll back. Escalate. Hay thu thập thêm bằng chứng.

Một báo cáo đầy phần trăm nhưng không giúp bạn chọn được 1 trong 6 việc trên thì không phải hệ thống niềm tin. Đó là đồ trang trí.

Xây được thứ này cần trộn nhiều thứ lại: automation, thống kê, tư duy sản phẩm, phân tích rủi ro, human review, observability, và cả kỹ năng trình bày. Nghe vượt xa QA truyền thống — nhưng lại đúng y cái mà ban lãnh đạo vẫn luôn mong đợi ở QA.

Không phải nhiều test case hơn. Là nhiều niềm tin có cơ sở hơn.

3. Bằng chứng độc lập ngày càng đắt giá

AI gộp chung việc làm và việc kiểm vào cùng một cái harness. Chính vì thế, bằng chứng đến từ bên ngoài lại càng có giá.

Coding agent nên tự test công việc của nó, liên tục. Vòng phản hồi đó nhanh và hữu ích. Nhưng không bao giờ đủ.

Lý do rất đơn giản: vừa đá bóng vừa thổi còi.

Agent thiết kế code sẽ mang nguyên bộ giả định của nó sang lúc viết test. Model sinh code có đúng những điểm mù của model review code. Còn các nhà cung cấp model thì luôn tối ưu sản phẩm theo benchmark và lợi ích kinh doanh của chính họ.

Vậy nên Director of QA phải chủ động cài các lớp kiểm tra độc lập:

• Bộ xác thực tất định (deterministic validator)
• Đối chiếu với dữ liệu hành vi thật trên production
• Human review trên mẫu ngẫu nhiên
• Red team và stress test
• Đánh giá chéo bằng một dòng model khác
• Một evaluation agent tách biệt hoàn toàn
• Nền tảng đánh giá chất lượng của bên thứ ba

Không phải bước nào cũng cần một phòng ban riêng hay một vendor riêng. Nguyên tắc là: mức độ độc lập tỉ lệ thuận với mức độ rủi ro. Đổi nhãn một cái nút thì không cần quy trình như luồng thanh toán, khuyến nghị y khoa, hành động tự động không có người xác nhận, hay chính sách phân quyền dữ liệu.

Hậu quả càng lớn, càng không được để bên tạo ra sản phẩm tự chấm điểm cho mình.

4. Chất lượng trở thành chiều ngang

Tổ chức QA thế hệ mới không đứng chờ ở cuối quy trình. Họ cắm sẵn cơ chế tạo niềm tin ngay tại nơi hành vi sản phẩm được sinh ra: prompt hướng dẫn agent, phân quyền hành động, kho dữ liệu mẫu, các bài test bắt buộc, hệ thống lưu trace, ngưỡng chặn release, và tín hiệu phản hồi từ production.

Director of QA không cần sở hữu mọi công cụ. Director cần sở hữu tiêu chuẩn để ghép các công cụ đó lại thành một chuỗi đáng tin.

Điều này cũng thay đổi luôn cách báo cáo thành công. Số lượng test case hay tỷ lệ automation là những chỉ số mờ nhạt. Thước đo thật nằm ở:

• Thời gian từ lúc đổi code đến lúc có bằng chứng release đáng tin — ngắn lại bao nhiêu
• Độ bao phủ rủi ro thực chất, thay cho độ bao phủ dòng code
• Tỷ lệ chặn được lỗi nghiêm trọng trước khi phát hành diện rộng
• Khả năng roll back sẵn sàng ở mọi thời điểm
• Số sự cố production đã được chuyển thành bài test hồi quy cố định
• Mức đồng thuận — và những điểm bất đồng có cơ sở — giữa các reviewer
• Tốc độ ra quyết định phát hành
• Chi phí tạo bằng chứng có cân xứng với quy mô rủi ro hay không

Mục đích không phải thay một cái bảng cũ bằng một dashboard mới bóng bẩy hơn. Mục đích là gắn hệ thống đo lường vào đúng chỗ nó cần gắn: quyết định release thực tế.

---

Phần 5, Lead Before They Work Around You, sẽ khép lại loạt bài: cái giá phải trả về vị thế khi chần chừ thay đổi, và sự xuất hiện của một vai trò mới — Director of Confidence Engineering.