WEBSITE ĐANG PHÁT TRIỂN

Test coverage khi vibe code: AI viết tests thì ai chịu trách nhiệm?

AI viết code nhanh, AI viết tests cũng nhanh – nhưng khi cả hai cùng đến từ một nguồn, coverage 100% vẫn có thể che giấu bug production. Đây không phải lỗi của AI. Đây là structural problem của vibe coding workflow: không có adversarial thinking, không có người hỏi "nhưng nếu... thì sao?" Vai trò QA không bị AI xóa bỏ – nó đang trở nên quan trọng hơn bao giờ hết. Tuần trước, tôi review một đợt regression sau khi team deploy feature mới. CI green. Test coverage 94%. Zero failing tests. Mọi thứ sạch đẹp trên dashboard. Hai giờ sau khi lên production – một user nhắn tin vào support: "Giỏ hàng của tôi bị mất khi tôi quay lại từ trang thanh toán." Tôi kéo code ra. Dev gen bằng Cursor, tests cũng gen bằng Cursor. Coverage report trông rất đẹp – unit tests cover từng function, integration tests cover các happy path chính. Chỉ có một thứ tests không cover: cái user journey cụ thể đó – tab back sau khi redirect sang payment gateway của bên thứ ba, state của cart bị reset vì AI không biết rằng cái flow đó tồn tại. AI không biết business context của bạn. AI không có ký ức về lần trước user complain gì. AI không đặt câu hỏi theo kiểu của một tester: "Nhưng nếu user làm cái này trước thì sao?" Và đó chính là vấn đề cốt lõi.

Test coverage khi vibe code: AI viết tests thì ai chịu trách nhiệm?

Vấn đề: Khi code và tests đến từ cùng một nguồn

Có một thuật ngữ trong statistics gọi là circular reasoning – dùng một luận điểm để chứng minh chính nó. Vibe coding đang tạo ra phiên bản software engineering của circular reasoning: AI viết code, rồi AI viết tests để verify code đó. Tests được viết với chính cái hiểu biết (và cả cái blind spot) của AI đã viết code.

Nghiên cứu từ GitClear (2025) cho thấy AI coding tools có thể tăng tốc development 20-55%, nhưng "sustainable code" – code ở lại codebase mà không cần rewrite – chỉ tăng khoảng 10%. Khoảng cách đó chính là chỗ bug sống.

Cụ thể hơn: Sonar's State of AI in Code report (January 2026) tìm ra rằng 95% developer phải tốn effort đáng kể để review AI-generated code, và 38% cho rằng nó khó review hơn code human viết. Lý do không phải code phức tạp – mà là code trông đúng nhưng thiếu context.

Bây giờ áp pattern đó vào testing:

AI gen test cho function calculateCartTotal() sẽ test đủ các case mà AI biết: số dương, số âm, zero, discount code. Nhưng AI sẽ không test: điều gì xảy ra khi user đang ở bước checkout, tab back, rồi add thêm item? Đó là user behavior thật, không có trong code, không có trong spec, chỉ có trong đầu người làm QA đã từng ngồi cùng user testing session.

Tôi gọi cái này là circular validation: code và tests có cùng hiểu biết, cùng assumption, cùng blind spot. Coverage% tăng nhưng confidence thật sự không tăng theo.


Case thực: AI tests vs Human QA tests – Chúng khác nhau ở đâu?

Tôi đã test trực tiếp điều này trên một SaaS project nhỏ. Cùng một feature – user profile update – tôi so sánh test suite do AI gen và test suite do tôi viết từ đầu.

AI-generated tests (Cursor + Claude):

  • Happy path: update name, update email – pass
  • Validation: email không hợp lệ – throw error – pass
  • Auth: unauthenticated request – 401 – pass
  • Coverage report: 87%

Tests tôi thêm vào sau khi review:

  • Điều gì xảy ra khi user update email thành email đang được dùng bởi account khác? (race condition kiểu này hay bị bỏ qua)
  • Điều gì xảy ra khi user paste emoji vào display name? (Unicode edge case, thường crash DB collation)
  • Điều gì xảy ra khi update xảy ra đúng lúc session đang expire?
  • Điều gì xảy ra khi file avatar upload chứa tên file có ký tự đặc biệt trên Windows vs Linux?

Trong số 4 tests tôi thêm, 2 cái fail ngay. Một cái là silent data corruption – không crash, chỉ lưu sai. Một cái là 500 error không có thông báo gì cho user.

Coverage report trước khi tôi thêm: 87%.

Coverage report sau khi tôi thêm và fix bugs: 91%.

Con số tăng ít. Nhưng 2 bug production đã được bắt trước khi ship.


Tại sao AI không có "adversarial thinking"?

Đây là điểm quan trọng nhất cần hiểu.

AI được train để generate code hữu ích, đúng syntax, chạy được. AI viết tests để verify code đó chạy đúng theo cái cách AI hiểu "đúng". Nhưng testing thật sự là một activity adversarial – bạn đang cố gắng phá cái thứ mình vừa build.

Tôi đã làm QA đủ lâu để biết: tester giỏi nhất là người nghĩ như attacker, như confused user, như người làm điều sai theo cách không ai expect. Cái mindset đó không có trong training data của AI coding tools.

Một ví dụ cụ thể từ review của TestSprite (một AI testing agent đang được dùng nhiều trong 2026): khi test app e-commerce Indonesia, tool tự gen tests validate giá tiền – nhưng tests pass mọi số dương, không validate format. Một assertion như expect(invoiceTotal).toMatch(/[\d,]+/) sẽ accept cả "$1,250,000" lẫn "Rp 1.250.000" – nhưng với user Indonesia, đó là hai thứ hoàn toàn khác nhau, và một cái là sai theo quy định pháp lý.

AI không biết điều đó. Developer không biết điều đó. Chỉ có QA người biết context business mới biết cần hỏi câu đó.


5 nguyên tắc viết tests trong kỷ nguyên vibe coding

Sau nhiều tháng làm việc với team đang vibe code production systems, tôi rút ra được 5 nguyên tắc practical. Không phải lý thuyết – những thứ này tôi đang áp dụng từng sprint.

1. AI tests là baseline, không phải ceiling

Khi AI gen tests, coi đó là điểm xuất phát. Chạy qua, nhìn xem AI đã cover gì, rồi hỏi: "Còn cái gì AI không nghĩ tới?" AI giỏi happy path và validation đơn giản. AI kém ở state transitions, concurrent scenarios, business-specific edge cases.

Checklist tối thiểu để review AI-generated tests:

  • [ ] Tests có bao gồm ít nhất một scenario user "làm sai"?
  • [ ] Tests có cover trường hợp external dependency fail (API timeout, DB down)?
  • [ ] Tests có kiểm tra output format, không chỉ kiểm tra output tồn tại?
  • [ ] Tests có giả lập được trạng thái "giữa chừng" (vd: request gửi đi nhưng response chưa về)?

2. Viết tests từ bug report, không phải từ code

Mỗi lần bug production được reported, ngay lập tức viết một failing test reproduce được bug đó – trước khi fix. Đây là cái AI không làm được: AI không có ký ức về production incidents. Human QA có.

Cái test đó sẽ ở lại codebase mãi mãi như một guard. Lần sau AI refactor cái chỗ đó, test sẽ catch regression.

3. Coverage% không phải mục tiêu, nó là side effect

Tôi thấy pattern này quá nhiều: team đặt target "phải đạt 80% coverage" rồi AI gen tests đủ để hit target. Coverage% tăng, confidence thật sự không tăng.

Hỏi câu này thay vì nhìn vào số: "Nếu tôi thay đổi business rule này, tests có fail không?" Nếu có – tests đó đang protect bạn. Nếu không – tests đó chỉ đang trang trí.

4. Tách riêng "AI-generated tests" và "QA-curated tests" trong CI pipeline

Không phải để phân biệt đối xử, mà để có visibility. Khi AI tests fail, biết ngay đó là regression ở happy path. Khi QA tests fail, biết ngay đó là edge case quan trọng bị broken.

Một số team tôi biết đang dùng tag trong test file:

// @ai-generated - baseline coverage, review before trusting
// @qa-curated - adversarial tests, must not regress

Simple. Không cần fancy tooling.

5. Dùng AI để expand test ideas, không phải để replace test thinking

Cái AI thật sự giúp được trong testing: khi bạn đã có một test case, dùng AI để generate variations. "Tôi có test này, hãy suggest thêm 5 edge case tôi có thể bỏ qua." Đây là AI amplifying human judgment, không phải replacing nó.

Prompt tôi dùng thường xuyên:

"Đây là function [code]. Đây là tests tôi đã có [tests]. Hãy list các edge case quan trọng tôi có thể bỏ sót, đặc biệt là các scenario liên quan đến [business context cụ thể]."

Với context đủ tốt, AI sẽ gợi ý được những case tôi chưa nghĩ tới. Nhưng tôi vẫn là người quyết định cái nào quan trọng.


QA không chết vì AI – QA quan trọng hơn bao giờ hết

Tôi nghe câu này từ nhiều người trong industry trong 12 tháng qua: "AI sẽ thay thế QA."

Họ sai. Và tôi sẽ giải thích tại sao.

Khi team development tốc độ tăng 3-5x vì vibe coding, lượng code cần được verify cũng tăng 3-5x. AI có thể gen tests, nhưng như tôi phân tích ở trên, những tests đó cần human review để có giá trị thật.

Quan trọng hơn: khi AI viết code, nó viết theo pattern phổ biến trong training data. Điều đó nghĩa là AI code có systemic blind spots – những loại edge case cả ngàn project trước đó đã bỏ qua sẽ tiếp tục bị bỏ qua. Chỉ có QA với context business cụ thể và kinh nghiệm production incidents mới bắt được những thứ đó.

Nghiên cứu DORA 2024 cho thấy: tăng 25% AI usage dẫn đến giảm 7.2% delivery stability. Incidents per pull request tăng 23.5% year-on-year trong khi PR count tăng 20%. Tức là code ship nhiều hơn, nhưng bug cũng nhiều hơn theo tỷ lệ cao hơn.

Ai sẽ catch những bug đó trước production? Không phải AI – vì AI là nguồn tạo ra bug. Không phải coverage metric – vì coverage cao mà vẫn lọt bug. Đó là QA, tester, người với adversarial mindset và knowledge về system thật.

Vai trò của QA trong kỷ nguyên vibe coding đang dịch chuyển: ít click-through manual testing hơn, nhiều test strategy hơn; ít viết boilerplate tests hơn, nhiều curate edge cases hơn; ít report bug hơn, nhiều shift-left quality gate hơn.

Công cụ thay đổi. Trách nhiệm thì không.


Câu hỏi tôi muốn hỏi team của bạn

Trước khi kết thúc bài này, tôi có một checklist nhanh – không phải để đánh giá, mà để reflective:

  • AI viết bao nhiêu % tests trong sprint gần nhất của team bạn?
  • Có ai review những tests đó để xem chúng đang test đúng cái gì không?
  • Lần cuối team bạn thêm test case từ production bug report là khi nào?
  • Team có biết phân biệt "coverage để happy" và "coverage để confident" không?

Nếu câu trả lời cho câu hỏi thứ ba là "lâu rồi" hoặc "không nhớ" – thì test suite của bạn đang dần trở thành theater. Trông đẹp trên CI. Không bảo vệ được gì.


Gửi các bạn QA/tester đang lo lắng về AI: đây là thời điểm tốt nhất để upgrade giá trị của mình. Dev đang ship code nhanh hơn bao giờ hết – và họ cần người giúp họ ship đúng, không phải chỉ ship nhanh.

"Quality is never an accident" – nó là kết quả của intelligent effort. Và intelligent effort đó đang cần các bạn hơn bao giờ hết.


Team bạn đang handle testing như thế nào trong thời đại vibe coding? Tôi thật sự muốn nghe: các bạn đang để AI gen toàn bộ tests, hay đang có process gì để curate chúng? Comment bên dưới, hoặc reach out trực tiếp – tôi đang collect case studies cho bài viết tiếp theo về test strategy cho AI-heavy teams.

/Ms Money - Quality is never an accident

#1percentbetter #softwaretesting #qualityassurance #vibecoding #automation



Bài viết liên quan

Xem thêm
Clean Code, Testing & Engineering Excellence

Vibe coding vui đấy, nhưng production thì không đùa được

Vibe coding với AI cực kỳ năng suất - nhưng 53% code AI sinh ra không qua nổi security review. Bài này tôi phân tích những lỗ hổng phổ biến nhất trong AI-generated code và checklist thực tế để vừa vibe vừa không mất ngủ vì production. Anh bạn tôi - một solo founder đang build SaaS app với Cursor - gọi điện lúc 11 giờ đêm tuần trước. "Ông ơi, tôi vừa nhận email từ khách hàng. Họ nói thấy data của người khác trong account của họ." Anh ấy đã dùng Cursor để build toàn bộ cái app trong 3 tuần. AI viết hết - backend, frontend, database schema, authentication. Năng suất khủng khiếp. Anh ấy tự hào lắm. Ra production mới phát hiện: AI đã generate thiếu Row Level Security (RLS) cho Supabase. Mọi user đều đọc được data của nhau. Đây không phải câu chuyện cá biệt. Vibe coding - cái trend "để AI viết hết, mình chỉ describe" - đang thay đổi hoàn toàn cách developer làm việc. Cursor, GitHub Copilot, Claude, v0.dev... Tôi dùng hàng ngày. Năng suất tăng 3-5x là thật. Thời gian từ idea đến MVP giảm từ tuần xuống ngày là thật. Nhưng có một thứ AI rất kém: security sense.