Test Thủ Công Đã Hết Thời? 10 Mô Hình Sụp Đổ API Test Thời Đại AI

Thành thật mà nói, tôi cũng từng là tín đồ của test thủ công

Thành thật mà nói, cho đến gần đây tôi vẫn nghĩ "test thủ công mới là tốt nhất".

"Code do AI viết không thể tin được. Phải có con người kiểm tra trực tiếp mới được" - tôi từng nghĩ như vậy.

Nhưng trong một dự án, tôi đã phải trải qua trải nghiệm đau đớn. Khi sử dụng ChatGPT và Copilot để phát triển API, test thủ công hoàn toàn không thể theo kịp.

Ban đầu tôi nghĩ "chỉ là hơi bận thôi". Nhưng rồi test trở thành nút thắt cổ chai của quá trình phát triển, khiến cả team bị đình trệ.

Trong bài viết này, tôi sẽ chia sẻ 10 bài học từ trải nghiệm thực tế về "sự sụp đổ của test API thủ công".

Nếu bạn cũng đang nghĩ "test thủ công vẫn ổn", thì câu chuyện này có thể không phải chuyện của người khác.

Những Khoảnh Khắc Sụp Đổ Tôi Đã Trải Qua

1. Tốc Độ Sinh Code Của AI Vượt Quá Khả Năng Kiểm Tra Của Con Người

Đây là điều gây sốc nhất.

Khi yêu cầu ChatGPT "tạo API quản lý người dùng", trong 5 phút sẽ có code cho 10 endpoint. Nhưng để test thủ công những thứ này, cả ngày cũng không xong.

• Endpoint tăng 5 cái mỗi 30 phút
• Cấu trúc request thay đổi 3 lần trong 1 giờ
• Chỉ riêng việc kiểm tra phạm vi ảnh hưởng đã mất nửa ngày

"Tại sao chỉ mình tôi chậm thế này?" - tôi nghĩ vậy, nhưng vấn đề không phải ở kỹ năng mà ở cấu trúc.

2. Câu Chuyện Rơi Vào 'Bẫy' Của Code AI

API do AI tạo ra trông có vẻ hoàn thiện cực kỳ cao.

// API do ChatGPT tạo (trông hoàn hảo)
app.post('/api/users', async (req, res) => {
  const { name, email } = req.body;
  const user = await User.create({ name, email });
  res.json({ success: true, user });
});

"Ồ, chạy được rồi! Hoàn hảo!" - tôi nghĩ vậy và chỉ test thủ công case bình thường rồi kết thúc.

Nhưng sau đó mới phát hiện:

• Thiếu xử lý chuỗi rỗng
• Không có kiểm tra email trùng lặp
• Format response lỗi không nhất quán

Test thủ công dễ kết thúc ở mức "chạy được là OK". Các giá trị biên hay case ngoại lệ thường bị hoãn lại vì phiền phức.

3. Địa Ngục Cập Nhật Test Case

Điều này cũng khó khăn.

Khi liên tục thay đổi spec API bằng AI, việc cập nhật test case hoàn toàn không theo kịp.

• Thứ Hai: Cập nhật spec
• Thứ Ba: Thay đổi implementation
• Thứ Tư: "Ủa? Test case giờ thế nào?"
• Thứ Năm: "Không biết đang test cái gì"

Kết quả là test API mới bằng test case cũ - tình huống vô lý.

4. Vấn Đề Kết Quả Test Khác Nhau Theo Người

Điều khó khăn nhất trong team development là:

• Tôi: "API này hoạt động bình thường"
• Đồng nghiệp A: "Có lỗi xảy ra"
• Đồng nghiệp B: "Response chậm"

Cùng một API nhưng kết quả test khác nhau tùy người.

Dù có tạo manual cũng vậy:

• Khác biệt về môi trường
• Khác biệt về điểm kiểm tra
• Khác biệt về cách tạo data

Kết quả vẫn khác nhau. Đây không phải đảm bảo chất lượng.

Phân Tích Nguyên Nhân Gốc Rễ Của Sự Sụp Đổ

5. Vấn Đề Kết Quả Test 'Biến Mất'

Kết quả test thủ công được lưu ở đâu?

• Postman trên máy local của tôi
• Tin nhắn "hoạt động rồi!" trên Slack
• Ghi chú tay

Tất cả đều tạm thời. Ngày hôm sau là "hôm qua test cái gì nhỉ?".

Càng tăng tốc độ phát triển bằng AI, vấn đề 'biến mất' này càng trở nên ch致命.

6. Bị Loại Khỏi CI/CD Hoàn Toàn

Điều này cũng đau đớn.

Team sử dụng GitHub Actions cho CI/CD, nhưng chỉ test thủ công bị bỏ rơi hoàn toàn.

• Code được deploy tự động khi push
• Nhưng API test vẫn thủ công
• Kết quả là "phát hiện vấn đề sau deploy"

"Test là công việc làm cuối cùng khi có thời gian" trở thành hiện thực.

7. Test Liên Kết Nhiều API Không Thực Tế

API do AI tạo thường không đơn lẻ mà dựa trên tiền đề liên kết nhiều API.

• Đăng ký user → Xác thực → Cập nhật profile
• Tìm kiếm sản phẩm → Thêm giỏ hàng → Xử lý thanh toán

Test thủ công những thứ này mỗi lần là không thực tế.

8. Vòng Luẩn Quẩn 'Thiết Kế Test' Phụ Thuộc Cá Nhân

Điều đáng sợ nhất:

AI viết code → Con người suy nghĩ thiết kế test → Chỉ một người nắm toàn bộ

Khi tôi nghỉ thì không ai có thể test API - tình huống này đã xảy ra.

Vấn Đề Của Luồng Phát Triển Bị Phân Tách

9. Spec·Test·Implementation Tách Biệt

Đây là nguyên nhân lớn nhất của sự sụp đổ.

• Spec: Notion
• Test: Postman
• Implementation: Code AI tạo

Tất cả ở những nơi khác nhau nên không thể duy trì tính nhất quán.

Spec thay đổi nhưng quên cập nhật test case. Implementation thay đổi nhưng quên cập nhật spec.

Để giải quyết sự phân tách này, cuối cùng tôi đã chuyển sang công cụ có thể quản lý API spec và test ở cùng một nơi (như Apidog).

Thực tế, sau khi bắt đầu sử dụng Apidog:

• Thay đổi spec → Tự động cập nhật test case
• Thực thi test → Kết quả được lưu thành lịch sử
• Liên kết CI/CD → Chạy automated test

Luồng này được tạo ra và tình huống "không biết đang kiểm tra gì, ở đâu" đã giảm đáng kể.

10. Nỗi Sợ Của 'Ảo Tưởng Đang Kiểm Tra'

Điều nguy hiểm nhất là cảm giác an tâm.

"Có người kiểm tra nên ổn" "Thử rồi chạy được nên không vấn đề"

Nhưng thực tế, con người không thể nhìn thấy tất cả đã trở thành hiện thực.

Test thủ công tưởng là 'nguồn an tâm' nhưng thực ra đã trở thành 'điểm mù'.

Không Phải Phủ Định Hoàn Toàn Test Thủ Công

Đừng hiểu lầm, bản thân test thủ công không xấu.

Ngay cả bây giờ:

• Kiểm tra ban đầu tính năng mới
• Xác nhận liên kết UI
• Kiểm tra usability

Test thủ công vẫn quan trọng.

Chỉ là cấu trúc duy trì test thủ công làm 'chính' sẽ sụp đổ.

Thực tế, trước đây tôi cũng vận hành với spec·test·kết quả thực thi phân tán ở các nơi khác nhau. Ban đầu test thủ công vẫn chạy được, nhưng khi API thay đổi nhiều thì chỉ còn lại "ảo tưởng đang kiểm tra".

Giải Pháp Tôi Tìm Ra: Tiền Đề Thống Nhất

Cuối cùng, việc quản lý những thứ sau với cùng một tiền đề là quan trọng:

• API spec
• Test case
• Mock data
• Kết quả thực thi

Gần đây, phương pháp quản lý tích hợp tập trung vào API spec được sử dụng nhiều.

Ví dụ, sử dụng công cụ có thể xử lý API definition và test với cùng tiền đề (như Apidog) giúp dễ dàng phát hiện sớm sự khác biệt với code AI tạo.

※ Đây chỉ là một ví dụ, điều quan trọng là có "hệ thống không sụp đổ về mặt cấu trúc".

Tổng Kết: Cần Thay Đổi Chính 'Tiền Đề'

Trong thời đại AI, điều cần xem xét lại không phải:

• Thủ công hay tự động
• Sử dụng công cụ nào

Mà là chính tiền đề "con người có thể kiểm tra tất cả".

Tôi cũng có sự kháng cự ban đầu. Nhưng khi buông bỏ tiền đề đó, cách thức test API cũng tự nhiên thay đổi.

Nếu bạn cũng cảm thấy "giới hạn của test thủ công", hãy dừng lại và suy nghĩ.

Vấn đề có thể không phải ở kỹ năng cá nhân mà là kết quả của việc cấu trúc thời đại đã thay đổi.

---

Nếu bài viết này hữu ích, hãy chia sẻ! Nếu bạn có "trải nghiệm sụp đổ test thủ công", hãy chia sẻ trong comment.