[Leader nên đọc] Tình thế tiến thoái lưỡng nan của Giám đốc QA, Phần 2: QA Mới Là Việc Khó Bây Giờ

Dịch từ blog substack của Jarbon

Code đang trở nên rẻ. Sự tự tin thì không.

AI không loại bỏ testing. Nó đang thay đổi ai làm việc đó, khi nào nó diễn ra, và QA leadership tồn tại để làm gì.

Đây là Phần 2 của The Director of QA Dilemma, một loạt bài năm phần về cùng một sự chuyển dịch lớn: Director of QA phải chuyển từ việc bảo vệ các hoạt động testing sang việc kiến tạo mức độ tự tin cho phép công ty ship phần mềm do AI sinh ra.

Nói thẳng: cuộc chuyển đổi AI lẽ ra phải là một pha ghi điểm dễ dàng đối với một QA director giàu kinh nghiệm, sáng tạo và thông minh.

Viết code không còn là phần khó nhất của phần mềm nữa. Với một tỷ trọng ngày càng lớn trong phát triển sản phẩm, việc code diễn ra nhanh, rẻ, và ngày càng được giao cho các agent.

Việc viết feature list, đặc tả cho các button, user story và product requirement ban đầu cũng đang trở nên rẻ.

Bộ ba sản phẩm cũ gồm product management, development và testing:

• Product xác định cần xây gì.
• Development xây nó.
• Testing quyết định xem nó có hoạt động hay không.

Những vai trò này đang gộp lại thành một. Khi AI có thể đề xuất sản phẩm, viết code, tạo ra các biến thể và chạy phần lớn công việc validation, thì năng lực khan hiếm chính là khả năng phán đoán để cân bằng giữa tốc độ, rủi ro, trải nghiệm khách hàng, giá trị kinh doanh và mức độ tự tin.

Điều đó nghe gần với công việc của một QA director giỏi hơn nhiều so với công việc của một project manager thuần túy hay một developer thuần túy.

Quality từng bị xem là chậm bởi vì code là phần công việc nhìn thấy được, còn validation thì lẽo đẽo theo sau. Giờ đây AI có thể sinh ra các bản triển khai và các biến thể sản phẩm gần như tức thì, trong khi việc thiết lập sự tự tin vẫn đòi hỏi bằng chứng, ngữ cảnh, thử nghiệm và phán đoán.

Quality không còn chỉ đơn thuần là phần chậm chạp nữa.

Quality mới là việc khó bây giờ.

QA Director Thời Chiến

Cuốn The Hard Thing About Hard Things của Ben Horowitz mô tả việc lãnh đạo khi không có câu trả lời dễ dàng nào, và phân biệt giữa lãnh đạo thời bình với lãnh đạo thời chiến. AI đã tạo ra một thời khắc thời chiến cho QA.

Điều đó không có nghĩa là hoảng loạn, liều lĩnh, hay đối xử tệ với con người. Nó có nghĩa là hành động khẩn trương, ra các quyết định khó một cách trực diện, dẫn dắt từ tuyến đầu, và không dùng quy trình làm nơi trú ẩn để né trách nhiệm.

Chi tiết sẽ khác nhau tùy công ty, nhưng playbook trước mắt thì ngắn gọn.

1. Tham gia vào cuộc chuyển đổi AI của Engineering và Product

Hiểu chính xác cách developer và product manager dùng AI, họ dùng coding agent nào, workflow nào đang thay đổi, và ở đâu họ vẫn còn thiếu tự tin.

Đưa khả năng phán đoán, các eval, các rủi ro và yêu cầu về bằng chứng của team bạn vào bên trong những agent và quy trình đó. Nếu QA không trở thành một phần của workflow mới, có thể sẽ chẳng còn chiếc ghế nào cho bạn khi workflow cũ dừng lại.

2. Xây dựng một team giúp tăng tốc cuộc vượt tuyến

Đánh giá xem ai không chỉ chịu đựng được sự chuyển đổi, mà còn chủ động tăng tốc nó.

Hãy tạo áp lực giảm nhân sự lên QA team và vendor truyền thống, dù con số cụ thể sẽ khác nhau tùy công ty. Các leader của bạn cần hiểu AI, thành thạo AI, thử nghiệm một cách rõ ràng, và sẵn sàng chấp nhận những rủi ro thông minh.

Đào tạo lại và bố trí lại những người có thể chuyển mình. Ra quyết định khó khăn với những người từ chối.

Nếu bạn không chủ động tái cấu trúc team, người khác sẽ tái cấu trúc nó — và tính cả bạn vào phần thay đổi đó.

3. Biến tài sản hiện có thành context cho AI

Test case, automation, test plan, lịch sử bug, report và kiến thức nghiệp vụ của bạn không phải tất cả đều là chi phí chìm.

Export chúng ra khỏi các công cụ đóng, sang những định dạng mở mà AI đọc được. Đưa chúng vào một AI workspace doanh nghiệp đã được phê duyệt, với các quyền riêng tư và kiểm soát truy cập phù hợp.

Bổ sung code liên quan, chiến lược sản phẩm và bối cảnh kinh doanh.

Rồi hỏi agent xem tài sản nào còn giá trị, tài sản nào đã trở thành gánh nặng, cái gì nên bị deprecate, và làm sao truyền đạt sự chuyển đổi này. Yêu cầu nó tạo ra kế hoạch, lịch trình, danh sách rủi ro và các thử nghiệm đầu tiên.

4. Bắt đầu mọi việc bằng AI

Trước khi viết email, lập kế hoạch dự án, review một release, thiết kế một bộ test hay bước vào một cuộc họp, hãy hỏi agent xem bạn nên cân nhắc điều gì dựa trên context đã được lưu giữ.

Hỏi xem công việc đó ảnh hưởng thế nào đến cuộc chuyển đổi rộng hơn. Dùng agent để phản biện thông điệp của bạn, phơi bày những rủi ro còn bỏ sót, và gợi ý hành động tiếp theo.

Đây không phải là ủy thác một cách mù quáng. Đây là một phản xạ mới: để AI giúp bạn nghĩ trước khi bạn tiêu tốn thời gian con người để làm.

5. Dẫn dắt từ tuyến đầu

Không còn chỗ cho một manager thuần túy chỉ biết giao phó toàn bộ việc thử nghiệm AI cho người khác.

Hãy ủy thác phần thực thi, tạo không gian cho team, và truyền đạt roadmap — nhưng vẫn phải hiện diện rõ ràng trong các công cụ và trong công việc. Tôi đã thấy những lead chủ động ngừng chờ đợi, làm việc trực tiếp với developer, và trở thành lựa chọn hiển nhiên để vận hành chức năng quality mới.

Người đó có thể lấy mất vị trí Director. Director lẽ ra phải là người dẫn đầu cuộc tiến công đó trước tiên.

6. Bắt mọi lớp trừu tượng cũ phải chứng minh giá trị của nó

Test-case management system, bug tracker, browser-driving framework, device harness, page-object model, dashboard và các workflow độc quyền không nên tồn tại chỉ vì công ty đã trả tiền cho chúng.

Export dữ liệu ra. Tự hỏi liệu một AI agent có thể làm trực tiếp công việc nền tảng đó không — nhanh hơn và ít phải bảo trì hơn. Giữ lại những hệ thống vẫn cung cấp khả năng governance, kiểm soát truy cập, tính auditability, khả năng thực thi mang tính deterministic, hoặc hồ sơ tuân thủ quy định. Loại bỏ những thứ giờ đây tạo ra nhiều ma sát hơn giá trị.

Phương án thay thế theo hướng AI-first cho một testing framework cũ có thể không phải là một framework mới hơn. Nó có thể là không có framework nào cả.

Hãy đưa một agent có khả năng duyệt web đã được phê duyệt vào một website và yêu cầu nó điều tra. Trong vài giây, nó có thể điều hướng, quan sát, hình thành giả thuyết và tìm ra vấn đề. Kết quả sẽ không hoàn hảo, nhưng một framework mất nhiều ngày để cấu hình, nhiều tuần để mở rộng và nhiều năm để bảo trì thì cũng đâu có hoàn hảo.

Công nghệ đã đủ tốt để bắt đầu. Chờ đợi sự chắc chắn tự nó chính là quyết định dễ khiến tổ chức QA trở nên vô nghĩa nhất.

Phần 3, Stop Defending the Org Chart, sẽ xem xét khía cạnh con người của cuộc chuyển đổi này: nỗi sợ trong team, năng lực không đồng đều, sự hội tụ vai trò, và cái giá về mặt cảm xúc khi phải khai tử những hệ thống từng thành công của ngày hôm qua.