Đừng chỉ nhờ AI viết code: Hãy giao cho nó việc tìm lỗi

AI có thể viết code rất nhanh. Nhưng một vai trò khác cũng đáng để giao cho nó: tìm cách làm cho chức năng vừa viết bị lỗi.

 

Một chức năng mới vừa hoàn thành. Chạy thử vài case chính đều ổn. Giao diện đẹp, dữ liệu lưu được, flow tưởng như đã xong.

Thay vì tiếp tục nhờ AI viết chức năng kế tiếp, có thể đổi câu hỏi: “Nếu muốn làm chức năng này lỗi, bạn sẽ thử những trường hợp nào?”

AI viết nhanh hơn, kiểm thử cũng phải thay đổi

Ngày nay, chúng ta đều thấy AI đang làm tốc độ xử lý công việc thay đổi rõ rệt, đặc biệt trong lĩnh vực phát triển phần mềm, AI cũng hỗ trợ và mang đến các thay đổi khá rõ.
– Một developer có thể tạo component, API, query hoặc một chức năng nhỏ trong thời gian ngắn hơn trước.
– Một người không chuyên sâu về code cũng có thể dựng prototype khá nhanh nếu biết mô tả đúng yêu cầu.

Tốc độ tạo ra phần mềm tăng lên cũng kéo theo vấn đề khác: khối lượng cần kiểm tra tăng theo. Code được sinh nhanh không đồng nghĩa code đã đúng. Một chức năng chạy được cũng chưa đồng nghĩa nó đáp ứng đúng nghiệp vụ.

Vì vậy, nếu chúng ta chỉ dùng AI ở phía “xây”, chúng ta mới khai thác một nửa khả năng của nó.

Thay vì chỉ hỏi AI “hãy làm chức năng này”, hãy thử giao thêm một vai trò khác: “hãy tìm mọi cách hợp lý để chứng minh chức năng này chưa ổn”.

Bắt đầu từ requirement, chưa cần bắt đầu từ code

Một trong những việc AI làm khá tốt là đọc requirement và đặt câu hỏi ngược lại. Ví dụ một yêu cầu rất đơn giản:
“Người dùng chỉ được chọn ngày từ hôm nay trở về tối đa bảy ngày trước.”
Nếu chỉ kiểm tra happy case, chúng ta có thể thử hôm nay, hôm qua và một ngày cách đây năm ngày rồi kết luận chức năng ổn. Nhưng khi giao requirement cho AI với vai trò tester, danh sách có thể mở rộng:

• Đúng ngày hôm nay có được chọn không?
• Đúng ngày thứ bảy có được chọn không?
• Ngày thứ tám xử lý thế nào?
• Người dùng nhập ngày bằng bàn phím thay vì date picker thì sao?
• Timezone giữa client và server khác nhau thì sao?
• Người dùng mở form trước 0 giờ nhưng submit sau 0 giờ?
• API có chặn dữ liệu sai nếu frontend bị bypass không?

AI chưa cần chạy bất kỳ đoạn code nào để tạo giá trị ở bước này. Nó đang giúp đội dự án nhìn requirement từ nhiều hướng hơn, nhìn tổng thể hơn

Từ test case đến edge case

Con người thường kiểm thử theo cách mình nghĩ người dùng sẽ sử dụng. Nhưng lỗi phần mềm lại thường nằm ở những thứ người dùng không nên làm nhưng vẫn có thể làm.

Một trường số lượng yêu cầu lớn hơn 0. Vậy điều gì xảy ra với 0, -1, 0.0001, số cực lớn, ký tự, khoảng trắng hoặc giá trị null?
Một Work Order không được phép trùng. Vậy khác chữ hoa chữ thường thì sao? Có khoảng trắng phía cuối thì sao? Hai người submit gần như cùng lúc thì sao? Đây là nơi AI khá hữu ích: nó không mệt khi phải liệt kê hàng chục biến thể của cùng một rule.

Regression mới là chỗ AI có thể tiết kiệm nhiều thời gian

Một thay đổi nhỏ đôi khi làm hỏng chức năng tưởng như không liên quan. Sửa logic ngày tháng có thể ảnh hưởng báo cáo. Thay đổi API có thể làm một màn hình cũ không load được. Chỉnh quyền user có thể khiến một action biến mất ở role khác.

Vấn đề của regression testing là số lượng case tăng dần theo tuổi của hệ thống. Đây lại là loại công việc phù hợp để tự động hóa.
AI có thể hỗ trợ đọc phần code vừa thay đổi, đối chiếu dependency, đề xuất nhóm chức năng có nguy cơ bị ảnh hưởng và tạo lại bộ test cần chạy.
Nếu kết hợp với automation testing, vai trò của AI còn có thể đi xa hơn: chuẩn bị dữ liệu test, chạy kịch bản, đọc log và gom các lỗi cần con người xem lại.

Có thể tổ chức AI thành nhiều vai trò

Một cách khá thú vị là không dùng một phiên AI cho tất cả mọi việc. Có thể tách vai:

• Builder: đọc requirement và xây chức năng.
• Reviewer: đọc code nhưng không sửa, tập trung tìm rủi ro.
• Tester: tạo test scenario từ requirement.
• Regression checker: xác định phần cũ có thể bị ảnh hưởng.
• Business reviewer: kiểm tra flow có hợp lý với nghiệp vụ không.

Điểm đáng chú ý là các vai trò này nên được yêu cầu phản biện lẫn nhau thay vì cùng cố gắng chứng minh sản phẩm đã đúng. Một AI vừa viết code rồi được hỏi “code này đúng chưa?” rất dễ tiếp tục đi theo giả định ban đầu. Một context khác được giao nhiệm vụ tìm lỗi thường tạo ra góc nhìn tốt hơn.

AI có thể chạy nhiều, nhưng dữ liệu test phải có chủ đích

Kiểm thử không chỉ là bấm nhiều lần.  Muốn kiểm thử có giá trị, dữ liệu phải đại diện được các tình huống thực tế. Một ứng dụng quản lý kho chẳng hạn, không nên chỉ test item có tồn kho dương và dữ liệu sạch. Cần có item hết hàng, item ngừng sử dụng, transaction cùng thời điểm, số lượng lẻ, chứng từ đã khóa, user thiếu quyền hoặc dữ liệu lịch sử từ phiên bản cũ.

AI có thể giúp sinh những dataset như vậy nhanh hơn, nhưng business rule vẫn cần con người xác nhận.

Những việc vẫn không nên giao hoàn toàn cho AI

AI tìm được nhiều lỗi không có nghĩa AI hiểu đầy đủ sản phẩm. Có những câu hỏi vẫn cần BA, key user hoặc người vận hành thật trả lời:

• Flow này có thuận tiện khi dùng mỗi ngày không?
• Rule này có đúng chính sách doanh nghiệp không?
• Một ngoại lệ có được phép về mặt nghiệp vụ không?
• Kết quả tài chính có đúng bản chất giao dịch không?
• Người dùng có hiểu thông báo lỗi không?

AI có thể phát hiện rằng hai kết quả khác nhau. Nhưng việc xác định kết quả nào đúng với business vẫn cần người hiểu business.

Một flow nhỏ có thể áp dụng ngay

Không cần xây một hệ thống AI testing phức tạp ngay từ đầu. Với một chức năng mới, có thể thử quy trình:

1. Viết requirement và acceptance criteria rõ ràng.
2. Cho AI tạo test case trước khi development.
3. Developer hoặc AI hoàn thiện chức năng.
4. Dùng một context khác yêu cầu review và tìm edge case.
5. Chạy automated test cho những case có thể tự động hóa.
6. AI tổng hợp lỗi, log và các điểm bất thường.
7. Con người kiểm tra business case và quyết định nghiệm thu.

Điểm quan trọng không nằm ở việc AI chạy được bao nhiêu test.

Nó nằm ở việc chúng ta bắt đầu dùng AI để phản biện sản phẩm, thay vì chỉ dùng AI để tạo sản phẩm.

AI không nhất thiết thay tester, nhưng chắc chắn làm thay đổi cách test

Tester trước đây phải dành khá nhiều thời gian cho những thao tác lặp lại: chuẩn bị dữ liệu, chạy cùng một kịch bản, kiểm tra log, ghi nhận kết quả. Khi một phần công việc đó được tự động hóa, giá trị của người làm kiểm thử dịch chuyển dần sang những việc khó hơn:

• Hiểu business rule.
• Nhận diện rủi ro.
• Thiết kế scenario tốt.
• Đặt câu hỏi về ngoại lệ.
• Đánh giá trải nghiệm người dùng.
• Quyết định lỗi nào thực sự quan trọng.

Điều này khá giống nhiều vai trò khác trong thời đại AI: phần thao tác giảm đi, phần tư duy lại quan trọng hơn.

AI có thể chạy một nghìn test case. Nhưng chọn một trăm case đáng chạy và hiểu vì sao chúng quan trọng vẫn là một năng lực khác.

Kết

Chúng ta đang khá quen với việc nhờ AI tạo code, tạo màn hình, viết query hay sửa lỗi.

Có lẽ đã đến lúc sử dụng nó nhiều hơn ở phía còn lại. Cho AI đọc requirement. Cho nó đặt câu hỏi. Cho nó tìm edge case. Cho nó thử phá những gì vừa được xây. Cho nó chạy lại những phần cũ sau mỗi thay đổi.
Rồi con người xem lại những gì AI tìm được và quyết định điều gì thực sự đúng với nghiệp vụ. AI giúp chúng ta xây nhanh hơn. Nhưng nếu biết điều phối đúng, nó cũng có thể giúp chúng ta nghi ngờ sản phẩm sớm hơn — trước khi người dùng thật là người tìm ra lỗi.