[Leader nên đọc] Tình thế tiến thoái lưỡng nan của Giám đốc QA, Phần 1: Cái Bẫy

Một series rất hay và đáng dành 5 phút để đọc kĩ. Mình dịch từ blog substack của Jarbon

Tại sao việc cố gắng trấn an team và làm hài lòng ban quản lý lại có thể khiến một QA director không được bên nào tin tưởng.

AI không loại bỏ việc testing. Nó đang thay đổi ai là người thực hiện, khi nào nó diễn ra và vai trò của ban lãnh đạo QA là gì.

Đây là Phần 1 của loạt bài 5 phần The Director of QA Dilemma nói về một bước chuyển mình lớn hơn: Giám đốc QA (Director of QA) phải chuyển từ việc bảo vệ hoạt động testing sang việc xây dựng sự tự tin để giúp công ty có thể release các phần mềm do AI tạo ra (AI-generated software).

Mở đầu

QA Director bị kẹp giữa ba áp lực từ ba hướng khác nhau.

• Từ trên (CEO): áp lực về tốc độ — “có AI rồi, sao test vẫn chậm?”
• Từ ngang (Engineering): sự lạc quan thái quá — “AI viết được test thì QA sắp không cần nữa”
• Từ dưới (đội QA): nỗi lo mất việc

Cả ba phản ứng này đều dễ hiểu. Mỗi bên đều nắm được một phần sự thật nhưng bỏ sót phần quan trọng nhất — và chính sự thiếu sót đó mới là điều nguy hiểm, chứ không phải bản thân AI.

Lựa chọn đầu tiên: giám đốc QA cũng có thể chọn cách cố thủ — khẳng định cách làm cũ vẫn tốt, giữ nguyên bộ test automation, quy trình release và biên chế đội ngũ.

Cái giá của lựa chọn này: nó chỉ mua được thời gian. Về lâu dài, QA có nguy cơ trở thành nhóm “bảo tàng” — vẫn vận hành hiệu quả theo tiêu chuẩn của quá khứ, nhưng ngày càng lạc nhịp so với cách các nhóm dev đang làm việc.

Lựa chọn thứ hai: Giám đốc có thể chấp nhận câu chuyện đơn giản nhất về AI: các coding agents sẽ viết code, viết tests, chạy tests và quyết định khi nào công việc hoàn thành.

Nghe có vẻ hiệu quả, nhưng nếu để AI vừa làm vừa tự kiểm tra, thì “người gây lỗi” cũng chính là “người chứng minh mình không có lỗi” — giống như để học sinh tự làm bài rồi tự chấm điểm cho mình.

Nó nhanh và tiết kiệm, nhưng bằng chứng chất lượng thu được gần như không còn giá trị khách quan, vì AI có xu hướng “mù” đúng với những điểm mà chính nó đã hiểu sai từ đầu

Không có câu trả lời nào là đủ tốt.

Giám đốc QA phải ngừng việc làm chủ (owning) testing và bắt đầu làm chủ sự tự tin (confidence).

Thỏa Thuận Cũ Đang Bị Phá Vỡ

Các tổ chức QA truyền thống được xây dựng quanh một sự phân công lao động rất thực dụng:

• Developer tạo ra sản phẩm.
• Tester kiểm tra.
• Automation engineer thì code automation cho những test case regression.
• Còn các lãnh đạo QA thì lo bố trí nhân sự, quản lý môi trường, theo dõi lỗi, báo cáo tỷ lệ pass và thương lượng về rủi ro khi release.

Đó là một mô hình lý tưởng. Dù chưa có tổ chức nào thực hiện được một cách rạch ròi, nhưng mọi người đều có một vai trò dễ nhận biết.

AI phá vỡ thỏa thuận này vì quá trình implementation (triển khai) và validation hiện đang diễn ra trong cùng một môi trường generative (môi trường tạo sinh).

Một coding agent có thể kiểm tra các requirements, sửa đổi code, khởi chạy ứng dụng, viết tests, chạy thử APIs, click qua interface, xem xét logs, sửa chữa các failures và lặp lại vòng lặp này trước khi quá trình chuyển giao (handoff) cho QA truyền thống bắt đầu.

Kiểm thử không hề biến mất. Nó phình ra một cách khủng khiếp.

Chỉ có điều: ai là chủ sở hữu của nó thì không còn hiển nhiên nữa.

Nếu vị Giám đốc định nghĩa giá trị của đội mình là chạy test, bảo trì hàng đống script, ghi bug, hay canh giữ cái cổng release cuối cùng — thì chức năng đó càng dễ bị bỏ qua. AI có thể làm phần lớn những việc ấy nhanh hơn và rẻ hơn.

Giá trị không còn nằm ở khối lượng hoạt động kiểm thử. Nó nằm ở việc phán xét xem những bằng chứng thu được có ý nghĩa gì hay không.

Tôi Liên Tục Nghe Cùng Một Câu Chuyện

Tôi khá sát sao với giai đoạn chuyển giao này. Các giám đốc QA vẫn thường liên hệ riêng với tôi để đối chiếu tình hình, hỏi xem những công ty khác đang làm gì, và cùng nhau mổ xẻ xem AI có ý nghĩa gì với đội nhóm và sự nghiệp của họ.

Đây không phải một cuộc khảo sát chính thức, và những người tìm đến tôi thì đương nhiên là những người đang phải vật lộn với vấn đề này nhiều hơn cả. Dù vậy, mô típ lặp lại đến mức đáng chú ý: họ cảm thấy bị mắc kẹt giữa đội ngũ cùng quy trình mà họ đang có, và một tổ chức AI-first mà ban lãnh đạo ngày càng mong đợi.

Phần lớn họ cố đánh cả hai lá bài cùng lúc.

• Với đội, họ trấn an rằng công việc hiện tại vẫn còn giá trị và chẳng có gì phải thay đổi nhiều.
• Với ban lãnh đạo, họ báo rằng QA đang tiếp nhận AI và sắp tới sẽ chạy nhanh hơn.

Nhưng đội vẫn coi các thử nghiệm đó là một mối đe dọa. Còn ban lãnh đạo thì thấy tốc độ test, chi phí và thời gian xoay vòng chẳng cải thiện được bao nhiêu. Thay vì làm hài lòng cả hai phía, vị Giám đốc làm thất vọng cả hai.

Tôi từng nghe kể về những đội QA đi vòng qua đầu Giám đốc của mình để tìm đến ban lãnh đạo cấp cao, lãnh đạo engineering, thậm chí cả HR — vì họ không đồng tình với những thay đổi được đề xuất, hoặc lo sợ những thay đổi đó sẽ ảnh hưởng đến công việc của mình.

Tôi cũng từng thấy các nhóm engineering và product âm thầm “đi đường khác” mà không cần QA. Họ bắt đầu tự xây các vòng lặp kiểm định bằng Claude, Codex và các coding agent khác. Họ không phải lúc nào cũng gạt lãnh đạo QA ra ngay lập tức. Đầu tiên, họ tạo ra một phương án thay thế. Sau đó, họ chứng minh rằng phần lớn phương án đó hoạt động được. Chỉ đến lúc ấy họ mới quay lại và quyết định xem còn cần gì — nếu còn — từ tổ chức QA hiện hữu.

Và vị giám đốc bị điều chuyển đi.

Hai Lựa Chọn Tồi

Lựa chọn tồi thứ nhất là phủ nhận.

Một vị Giám đốc có thể khăng khăng rằng test do AI sinh ra thì không đáng tin, rằng coding agent vẫn mắc lỗi, và rằng kiểm thử thủ công sẽ luôn luôn cần thiết. Từng câu trong đó có thể đều đúng, nhưng kết luận thì không suy ra được từ đó. Một AI chưa hoàn hảo vẫn có thể tự động hóa một tỷ lệ lớn công việc, vận hành liên tục không nghỉ, và tạo ra nhiều biến thể hơn mức một đội người có thể xem xét hết.

Bảo vệ từng đầu việc hiện tại chỉ vì AI chưa làm được nó một cách hoàn hảo thì không phải là chiến lược. Đó là lý lẽ để bị thay thế muộn hơn một chút.

Lựa chọn tồi thứ hai là đầu hàng.

Một vị Giám đốc có thể cắt giảm đội ngũ, mua một sản phẩm AI testing, đẩy trách nhiệm chất lượng về cho developer, rồi mặc định rằng cái bộ khung coding-agent kia rồi sẽ tự lo được phần còn lại. Đây là sự nhầm lẫn giữa sinh ra test và sự tự tin về chất lượng.

Một agent có thể viết một nghìn cái test mà vẫn bỏ sót đúng cái rủi ro quan trọng. Nó có thể tạo ra những assertion chỉ lặp lại chính những giả định mà nó đã dùng khi implement. Nó có thể tối ưu cho phần “đúng đắn nhìn thấy được”, trong khi bỏ qua quyền riêng tư, khả năng tiếp cận (accessibility), khả năng phục hồi, chi phí, độ trễ, chính sách, hay niềm tin của người dùng. Nó thậm chí có thể làm cho dashboard xanh hơn bằng cách nới lỏng chính các phép kiểm tra.

Câu hỏi không phải là liệu AI có test được hay không. Nó test được.

Câu hỏi là: ai quyết định điều gì xứng đáng được kiểm thử, bằng chứng nào đủ độc lập để đáng tin, thất bại nào mới thực sự quan trọng, và khi nào thì phần bất định còn lại là mức mà doanh nghiệp có thể chấp nhận.

Đó chính là cơ hội của vị Giám đốc.

Phần 2, “QA Mới Là Việc Khó”, sẽ giải thích tại sao chính cú đảo lộn này lại khiến một lãnh đạo QA xuất sắc trở nên quan trọng hơn chứ không phải kém đi — và một giám đốc QA thời chiến nên làm gì tiếp theo.