Nhiều người non-tech nghĩ QA là chuyện của tester hoặc developer. Có tool, có automation, có test suite. Đúng, nhưng chưa đủ.

Với app do Claude build hoặc sửa, rất nhiều lỗi quan trọng nhìn bằng mắt thường là thấy: nút sai chỗ, flow thiếu bước, form cho submit dữ liệu rỗng, mobile vỡ layout, loading state không có, sample data bị tưởng là real data.

Bạn không cần biết Playwright hay Jest để bắt các lỗi này. Bạn cần một checklist thực tế và kỷ luật ghi bug rõ.

Test flow chính từ đầu tới cuối

Bắt đầu bằng happy path: người dùng bình thường làm việc chính mà app hứa sẽ hỗ trợ.

Ví dụ booking app:

1. Mở dashboard.
2. Search customer.
3. Chọn service.
4. Chọn ngày giờ.
5. Review thông tin.
6. Confirm booking.
7. Thấy trạng thái thành công.

Trong lúc test, đừng chỉ nhìn “có chạy không”. Hỏi:

  • Có bước nào phải đoán không?
  • Nút chính có rõ không?
  • Sau khi bấm, app phản hồi có đủ nhanh và dễ hiểu không?
  • Data ở màn hình review có đúng với input trước đó không?
  • User có đường quay lại nếu chọn sai không?

Nếu flow chính đã gãy, đừng test tiếp phần phụ. Ghi bug, đưa lại cho Claude hoặc developer.

Test input sai, rỗng, trùng

AI rất hay build happy path đẹp nhưng validation yếu. Người dùng thật không nhập dữ liệu đẹp như sample.

Thử các case này:

  • Bỏ trống field bắt buộc.
  • Nhập email sai format.
  • Nhập số âm ở field tiền/số lượng.
  • Nhập ngày trong quá khứ nếu business không cho phép.
  • Nhập text rất dài.
  • Nhập duplicate item.
  • Bấm submit hai lần liên tục.
  • Copy paste nội dung có khoảng trắng đầu/cuối.

Expected behavior không nhất thiết phải phức tạp. Chỉ cần app không silently accept dữ liệu sai và không crash.

Bug report tốt:

Screen: Create service
Input: price = -100
Expected: show validation error and block submit
Actual: service created with negative price
Screenshot: negative-price-created.png

Câu này tốt hơn nhiều so với “validation có vấn đề”.

Test mobile và desktop

Nếu app chạy trên browser, test ít nhất hai kích thước:

  • Desktop/laptop bình thường.
  • Mobile hẹp, khoảng 390px hoặc dùng điện thoại thật.

Bạn đang tìm:

  • Text tràn khỏi button/card.
  • Table quá rộng làm mất cột quan trọng.
  • Modal cao hơn màn hình và không scroll được.
  • Nút primary bị đẩy khỏi viewport.
  • Header che content.
  • Input khó bấm.
  • Keyboard mobile che nút submit.

Với prototype, mobile vỡ có thể chấp nhận nếu feature chỉ dùng nội bộ desktop. Nhưng phải ghi rõ. Đừng để “chưa test mobile” biến thành “mobile ổn”.

Prompt feedback:

Ở mobile width 390px, bảng booking bị tràn ngang và mất cột status.
Giữ nội dung chính: customer, status, date, action.
Sửa layout mobile, không đổi desktop layout nếu không cần.

Test loading, error, empty

Claude hay build màn hình với data có sẵn. App thật luôn có ba trạng thái phụ:

  • Loading: data chưa về.
  • Error: API fail hoặc permission denied.
  • Empty: không có record.

Checklist:

  • Khi loading, user có biết app đang chờ không?
  • Loading có làm layout nhảy lung tung không?
  • Khi error, message có đọc được không?
  • Error có nói user nên làm gì tiếp không?
  • Empty state có phân biệt “chưa có data” với “search không có kết quả” không?

Ví dụ bug:

Screen: Customer search
Case: search keyword không có kết quả
Expected: show "Không tìm thấy khách hàng" và nút clear search
Actual: màn hình trắng, user tưởng app lỗi

Màn hình trắng là lỗi QA kinh điển. Không cần biết code để bắt.

Phân biệt sample data và real data

Vibe coding rất dễ tự lừa mình vì sample data đẹp. Tên khách hàng đủ dài vừa phải, status đủ loại, số tiền tròn, ngày tháng hợp lý.

Trước khi gọi app là “gần xong”, hỏi:

  • Data đang từ API thật hay hard-coded sample?
  • Nếu là sample, có label rõ không?
  • Nếu là API thật, endpoint nào?
  • Có auth/permission không?
  • Data có bị cache cũ không?
  • Có record edge case không: tên dài, thiếu avatar, status lạ, list rỗng?

Prompt:

Kiểm tra giúp tôi màn hình này đang dùng sample data hay real API.
Chỉ đọc code và giải thích. Nếu có mock/hard-coded data,
chỉ rõ file và dòng liên quan, chưa sửa.

Nếu Claude phát hiện mock, bước tiếp theo không phải “replace đại bằng API”. Bước tiếp theo là tìm endpoint/hook có sẵn trong repo, hoặc hỏi developer nếu không thấy.

Test privacy bằng câu hỏi đơn giản

Non-tech vẫn có thể bắt lỗi privacy bằng checklist.

Hỏi:

  • Tôi đã upload file gì vào Claude hoặc tool nào?
  • File đó có thông tin khách hàng, email, phone, payment, health, tài chính không?
  • App lưu dữ liệu ở đâu?
  • Data có gửi ra service bên ngoài không?
  • Log có in thông tin nhạy cảm không?
  • Screenshot bug có lộ thông tin thật không?

Nếu đang dùng data thật, hãy che hoặc tạo bản sample trước khi đưa vào chat. Đừng upload CSV khách hàng thật chỉ để prototype nhanh hơn.

Khi app chạm auth, payment, customer data, file upload, hoặc thông tin nhạy cảm, dừng ở mức QA notes và gọi developer/security review. Claude có thể hỗ trợ chuẩn bị checklist, nhưng không nên là người duy nhất quyết định an toàn.

Screenshot mọi bug

Bug không có evidence thường quay lại nhiều lần.

Mỗi bug nên có:

  • Screenshot hoặc screen recording ngắn.
  • URL hoặc màn hình.
  • Input đã dùng.
  • Expected behavior.
  • Actual behavior.
  • Thiết bị/kích thước màn hình nếu liên quan.

Format nhanh:

Bug: Confirm button vẫn active khi thiếu service
Screen: /bookings/new
Viewport: mobile 390px
Input: customer selected, service empty, date selected
Expected: Confirm disabled, show message "Chọn dịch vụ"
Actual: Confirm active, bấm vào thì tạo booking lỗi
Evidence: confirm-active-no-service.png

Đưa bug này lại cho Claude:

Sửa đúng bug trong report này.
Không refactor unrelated code.
Sau khi sửa, liệt kê file changed và cách tôi test lại.

Ranh giới “không refactor unrelated code” giúp giữ diff nhỏ.

Checklist cuối trước khi nói xong

Dùng checklist này cho mỗi Claude-built app hoặc feature:

  • Flow chính chạy từ đầu tới cuối.
  • Required fields không cho submit rỗng.
  • Input sai format bị chặn.
  • Duplicate action không tạo record trùng.
  • Mobile và desktop đều dùng được trong scope đã định.
  • Loading state có hiển thị.
  • Error state có message đọc được.
  • Empty state không trắng màn hình.
  • Data sample và real data được phân biệt.
  • Không có thông tin nhạy cảm trong screenshot, log, sample file.
  • Không có behavior liên quan auth/payment/customer data được ship mà chưa dev review.
  • Bug đã có screenshot và expected/actual rõ.

QA bằng mắt không thay thế automated test. Nhưng với vibe coding, nó là lớp phòng thủ đầu tiên và rẻ nhất. Nếu bạn không làm lớp này, bạn đang giao quyền định nghĩa “done” cho một model nhìn code nhiều hơn nhìn người dùng.

Tham khảo