Code chạy được chưa đủ để kết luận chất lượng
Code do AI tạo có thể dùng được, nhưng vẫn cần con người kiểm tra trước khi bàn giao. Một chức năng chạy tốt trong buổi giới thiệu chưa chắc đã xử lý đúng mọi tình huống thực tế. Để đánh giá chất lượng, hãy kiểm tra ba việc: phần mềm có làm đúng yêu cầu, bảo vệ dữ liệu và dễ sửa khi cần hay không.
Ở đây, AI là công cụ hỗ trợ lập trình viên viết mã nguồn, tức các câu lệnh tạo nên phần mềm. Điều này khác với xây dựng chatbot hay một sản phẩm AI. Ví dụ, đội ngũ có thể dùng AI để làm phần mềm quản lý đơn hàng. Dù dùng công cụ nào, đội ngũ phát triển vẫn chịu trách nhiệm kiểm tra và sửa lỗi.
Thống nhất thế nào là làm đúng trước khi viết code
Trước khi viết code, hai bên cần thống nhất thế nào là làm đúng. Đây chính là tiêu chí nghiệm thu: những điều kiện để khách hàng xác nhận và nhận bàn giao chức năng. Chẳng hạn, yêu cầu “thêm nút duyệt đơn” cần nói rõ ai được duyệt, đơn nào được duyệt và khi nào hệ thống phải từ chối. Những câu hỏi dưới đây giúp làm rõ yêu cầu đó.
- Ai được tạo, sửa, duyệt và hủy đơn? Hệ thống có thực sự từ chối người không có quyền, hay chỉ ẩn nút trên màn hình?
- Nếu hai người duyệt đồng thời, hệ thống chọn kết quả nào và ghi nhận lịch sử ra sao?
- Nếu người dùng bấm gửi lại khi mạng chậm, hệ thống có tạo đơn hoặc giao dịch trùng không?
- Hệ thống cần xử lý bao nhiêu dữ liệu, trong bao lâu và trên những thiết bị nào?
Ai sẽ kiểm tra code và cần kiểm tra kỹ phần nào?
Review code là việc đọc và kiểm tra mã nguồn. Người kiểm tra cần hiểu yêu cầu và thiết kế, không chỉ nhờ chính công cụ AI đã viết code tự đánh giá lại. Các chức năng liên quan đến thanh toán, quyền truy cập hoặc dữ liệu nhạy cảm cần được kiểm tra kỹ hơn bởi người có chuyên môn. Nếu chưa giải thích được cách đoạn code hoạt động, đội ngũ cần làm rõ trước khi chấp nhận.
- Khi thao tác thất bại, dữ liệu có bị lưu dở dang không? Hệ thống có giải phóng kết nối và các tài nguyên đã dùng không?
- Kiểm tra các thư viện, tức phần code có sẵn được dùng lại: chúng có tồn tại, phù hợp với hệ thống và được phép sử dụng không?
- Tìm phần xử lý bị lặp, thành phần không cần thiết và cách sắp xếp code khiến việc sửa sau này khó khăn.
- Lưu tên người rà soát, lỗi đã tìm thấy và cách xử lý trong hồ sơ đề nghị đưa code vào bản chính.
Kiểm thử theo yêu cầu thực tế, không chỉ theo code có sẵn
Kiểm thử cần dựa vào yêu cầu đã thống nhất, không chỉ dựa vào code đang có. Nếu AI hiểu sai yêu cầu rồi viết cả code lẫn bài kiểm tra theo cách hiểu đó, kết quả vẫn có thể báo đạt. Vì vậy, cần kiểm tra từng quy tắc riêng, cách các bộ phận của hệ thống phối hợp và cả quá trình người dùng thao tác từ đầu đến cuối.
Ví dụ giả định: một đơn đã hủy không được chuyển sang trạng thái đã giao. Đội ngũ cần thử cả tài khoản không có quyền, thao tác gửi lặp và trường hợp hai người cập nhật cùng lúc. Họ cũng cần kiểm tra trực tiếp API, tức nơi hệ thống tiếp nhận yêu cầu từ giao diện hoặc ứng dụng khác. Mục đích là bảo đảm quy tắc vẫn được giữ ngay cả khi thao tác không đi qua màn hình thông thường.
Trước bàn giao, cần tài liệu gì và xử lý sự cố ra sao?
Buổi demo, tức buổi giới thiệu phần mềm chạy thử, chỉ cho thấy một số tình huống. Khi nghiệm thu, bạn cần biết những gì đã được kiểm tra, lỗi nào còn tồn tại và trường hợp nào chưa được hỗ trợ. Kiểm thử không thể bảo đảm phần mềm hết mọi lỗi. Tuy nhiên, hồ sơ rõ ràng giúp hai bên biết rủi ro còn lại và ai có quyền chấp nhận chúng.
- Với mỗi yêu cầu quan trọng, lưu kết quả kiểm thử để khách hàng có thể xem lại.
- Chuẩn bị hướng dẫn đưa phần mềm vào sử dụng, thiết lập hệ thống và khôi phục dữ liệu. Thử các hướng dẫn theo điều kiện của dự án.
- Thống nhất cần theo dõi lỗi hoặc dấu hiệu bất thường nào sau khi đưa vào sử dụng, và ai tiếp nhận sự cố.
- Chốt trước trường hợp phải dừng triển khai hoặc quay lại phiên bản cũ khi chức năng quan trọng bị lỗi.
| Hạng mục | Tài liệu hoặc kết quả cần xem | Người xác nhận |
|---|---|---|
| Quy tắc nghiệp vụ | Kết quả thử từng yêu cầu, gồm thao tác bị cấm và trường hợp bất thường | Người phụ trách nghiệp vụ |
| Quyền truy cập và cập nhật dữ liệu | Kết quả thử tài khoản thiếu quyền, gửi lại yêu cầu và cập nhật đồng thời | Người phụ trách kỹ thuật |
| Khả năng bảo trì | Ghi chép kiểm tra code, thư viện được dùng và vấn đề đã xử lý | Người rà soát độc lập với người viết |
| Triển khai và khôi phục | Hướng dẫn đã thử, bản sao lưu và điều kiện dừng phát hành | Người phụ trách vận hành |
| Lỗi còn tồn tại | Danh sách lỗi, ảnh hưởng, cách xử lý tạm thời và quyết định chấp nhận | Người có thẩm quyền nghiệm thu |
Hai bên cần chỉ định người xác nhận cho từng mục trong bảng. Mỗi mục nên có đường dẫn đến kết quả kiểm tra và trạng thái đạt, chưa đạt hoặc không áp dụng kèm lý do. Đừng chỉ đánh dấu hoàn tất: người xác nhận cần xem tài liệu và kết quả thực tế.
Để đặt checklist này vào toàn bộ quá trình triển khai, xem cách Genki tiếp cận dự án từ yêu cầu đến bàn giao
Hỏi nhà cung cấp về quy trình, không chỉ công cụ
Khi trao đổi với nhà cung cấp, hãy chọn một chức năng cụ thể và hỏi: từ yêu cầu đến bàn giao, chức năng này được kiểm tra như thế nào? Ai chịu trách nhiệm và bạn được xem kết quả gì? Hỏi thêm cách đội ngũ xử lý khi AI đề xuất một giải pháp không phù hợp với hệ thống. Tên công cụ hay số lượng code tạo ra không thay thế được những câu trả lời này.
Bạn có thể bắt đầu với một chức năng nhỏ và tiêu chí nghiệm thu rõ ràng. Chỉ nên mở rộng khi đội ngũ đã cho thấy họ có thể bàn giao, sửa lỗi và hỗ trợ duy trì hệ thống. AI có thể giúp một số công việc nhanh hơn, nhưng không thay thế thiết kế, kiểm thử hay trách nhiệm của người phát triển.