Agent QA cần phác đồ trước khi chạy

Agent QA cần phác đồ trước khi chạy

Agentic QA không đáng tin chỉ vì biết bấm UI. Muốn vào production, bạn cần suite, orchestration, guardrail và nhật ký lỗi đủ để sửa đúng bệnh.

Có lần mình thấy một team demo agent QA rất mượt: nhập kịch bản tiếng Việt, agent mở browser, bấm qua vài màn hình, điền form, chụp screenshot, rồi báo xanh lè. Cả phòng vỗ tay. Ba ngày sau, pipeline vẫn đỏ vì lỗi cũ: agent chạy sai môi trường, test phụ thuộc dữ liệu hôm qua, và không ai biết nó fail vì app hỏng hay vì agent lạc đường.

Đây là khoảnh khắc hơi giống đi khám mà bác sĩ chỉ nhìn bạn ho một tiếng rồi kê thuốc. Có thể đúng. Nhưng đưa vào production thì hơi run.

Luận điểm của mình: agentic QA chỉ đáng tin khi bạn thiết kế nó như một hệ thống orchestration có guardrail, không phải như một con bot biết bấm UI. Test đơn lẻ là màn khám sơ bộ. Production QA cần phác đồ: nhóm test, chạy song song, gate deploy, lưu trajectory, và biến lỗi lặp lại thành năng lực cần sửa.

Sơ đồ minh họa cho bài Agent QA cần phác đồ trước khi chạy

Sơ đồ tóm tắt ý chính của bài viết.

Tín hiệu thật: agent QA đã bước qua màn demo

Điểm đáng chú ý trong hướng tiếp cận QA Studio dùng Amazon Nova Act không nằm ở chuyện “AI tự test UI”. Chuyện đó giờ không còn mới. Phần đáng soi là lớp vận hành phía sau:

Nói thẳng ra thì, khác biệt nằm ở chỗ agent không còn là “người thử việc lanh tay” ngồi bấm màn hình, mà trở thành một thành phần trong dây chuyền release có hồ sơ bệnh án đầy đủ.

Với developer hoặc tech lead, câu hỏi không phải “agent có chạy được test này không?”. Câu hỏi đúng hơn là: khi nó chạy 50 test trong pipeline, fail 7 test, bạn có biết phải làm gì tiếp không?

Mổ hệ thống theo 4 lớp cần giữ

Nếu bạn đang build agent QA cho team mình, đừng bắt đầu bằng model. Bắt đầu bằng 4 lớp này.

1. Lớp suite: phân loại trước khi tăng tốc

Một lỗi phổ biến là gom tất cả kịch bản vào một cục “regression”. Kết quả: pipeline lâu, fail khó đọc, team bắt đầu bấm “rerun” như uống thuốc giảm đau.

Bạn nên chia suite theo quyết định release:

| Loại suite | Chạy khi nào | Mục tiêu |
|---|---|---|
| smoke | Mỗi pull request hoặc deploy nhỏ | Bắt lỗi gãy luồng sống còn |
| regression | Trước release lớn | Kiểm tra vùng chức năng rộng |
| integration | Khi nhiều module đổi cùng lúc | Bắt lỗi giao nhau giữa tính năng |
| canary | Sau deploy một phần | Xem môi trường thật có ổn không |

Ví dụ cụ thể: nếu bạn làm SaaS kế toán, smoke chỉ cần login, tạo hóa đơn nháp, lưu khách hàng, xuất PDF. Đừng nhét cả luồng đối soát ngân hàng vào smoke nếu nó không quyết định deploy trong 10 phút đầu.

2. Lớp worker: song song nhưng phải cô lập

Parallel execution — chạy nhiều test cùng lúc — giúp giảm thời gian suite. Nhưng chạy song song mà không cô lập dữ liệu thì giống cho nhiều bệnh nhân dùng chung một phiếu xét nghiệm.

Guardrail tối thiểu:

Một mẫu naming đơn giản:

qa-{suite}-{run_id}-{case_id}
qa-smoke-20260714-001-create-invoice

Nếu bạn dùng worker kiểu container task, điều quan trọng không phải tên dịch vụ cụ thể, mà là nguyên tắc: mỗi use case phải có biên giới tài nguyên và dữ liệu rõ ràng.

3. Lớp CLI: pipeline cần exit code, không cần thơ văn

Agent có thể giải thích rất hay, nhưng CI/CD chỉ cần một thứ lạnh lùng: exit code.

Một CLI tối thiểu nên hỗ trợ:

qa-agent run-suite \
  --suite smoke \
  --env staging \
  --run-id "$BUILD_ID" \
  --output ./artifacts/qa

Và trả về quy ước rõ:

0 = pass
1 = test failed
2 = infrastructure error
3 = invalid configuration

Đây là guardrail vận hành. Nếu app fail thì chặn deploy. Nếu hạ tầng test fail thì báo infra. Nếu cấu hình sai thì đừng đổ lỗi cho sản phẩm.

4. Lớp trajectory: fail mà không có dấu vết là fail vô dụng

Trajectory — đường đi từng bước của agent — là thứ giúp bạn phân biệt ba loại lỗi:

  1. Product bug: app thật sự sai.
  2. Test spec bug: kịch bản mô tả sai hoặc thiếu điều kiện.
  3. Agent capability gap: agent thiếu năng lực, ví dụ không biết xác minh precondition trước khi thao tác.

Đây là chỗ các hướng như SkillOpt và TRACE gợi ý một bước tiến hay: đừng chỉ rerun lỗi lặp lại. Hãy biến lỗi lặp lại thành tài sản huấn luyện hoặc tài liệu kỹ năng.

Bạn chưa cần nhảy ngay vào training phức tạp. Nhưng bạn nên có bảng phân loại lỗi đủ sạch để biết agent đang thiếu gì.

Playbook một buổi: dựng phác đồ agent QA tối thiểu

Hình dung thế này: team bạn có một web app nội bộ, mỗi tuần deploy vài lần, QA thủ công đang bị nghẽn ở các luồng lặp lại. Trong một buổi chiều, đừng cố “AI hóa toàn bộ QA”. Làm khung trước.

Bước 1: chọn 5 luồng sống còn

Viết ra 5 user journey nếu hỏng thì không nên deploy. Mỗi luồng nên có:

id: create_invoice
suite: smoke
preconditions:
  - user exists with billing permission
steps:
  - login
  - create draft invoice
  - add one line item
  - save invoice
assertions:
  - invoice status is draft
  - total amount is visible
artifacts:
  - screenshot_on_failure
  - browser_trace

Đừng viết “kiểm tra tính năng hóa đơn hoạt động”. Agent không đọc được ý định mơ hồ tốt hơn con người đâu.

Bước 2: tách suite theo quyền chặn deploy

Tạo file cấu hình suite:

suites:
  smoke:
    cases:
      - login
      - create_invoice
      - export_pdf
    gate: blocking

  regression:
    cases:
      - create_invoice
      - edit_customer
      - apply_discount
      - search_transaction
    gate: advisory

blocking nghĩa là fail thì pipeline dừng. advisory nghĩa là báo động nhưng chưa chắc chặn deploy. Quyền chặn deploy phải là quyết định sản phẩm, không phải cảm xúc của agent.

Bước 3: chuẩn hóa report để người trực release đọc được

Report nên có ít nhất:

{
  "run_id": "build-8421",
  "suite": "smoke",
  "environment": "staging",
  "status": "failed",
  "failed_cases": [
    {
      "id": "create_invoice",
      "failure_type": "agent_capability_gap",
      "last_step": "save invoice",
      "artifact_path": "./artifacts/create_invoice"
    }
  ]
}

Điểm mấu chốt là failure_type. Không có nó, mọi lỗi đều biến thành “QA đỏ”, rồi cả team hội chẩn trong Slack lúc 6 giờ tối.

Bước 4: tạo sổ tay kỹ năng cho lỗi lặp lại

Khi một lỗi xuất hiện nhiều lần, đừng chỉ sửa prompt chính. Tạo file skill riêng:

# Skill: Verify invoice creation

## Before action
- Confirm the user is on the invoice creation page.
- If a loading spinner is visible, wait until it disappears.
- Check that the Save button is enabled before clicking.

## Known failure patterns
- Do not treat a toast notification as proof if invoice ID is absent.
- If the total amount is blank, inspect line item inputs before saving.

## Success criteria
- Invoice ID is visible.
- Status is Draft.
- Total amount matches line items.

Skill kiểu này chưa phải fine-tuning. Nó là lớp trí nhớ vận hành: rẻ, dễ review, dễ rollback. Khi đủ log và đủ lỗi lặp lại, lúc đó bạn mới cân nhắc tối ưu sâu hơn.

Ba bẫy khiến agent QA trông khỏe nhưng dễ tái phát

Bẫy 1: lấy pass rate làm KPI duy nhất. Pass cao có thể vì test quá dễ, assertion quá lỏng, hoặc agent bỏ qua bước khó. Hãy xem cả artifact, failure taxonomy và độ ổn định giữa các lần chạy.

Bẫy 2: cho agent quá nhiều quyền. Agent QA cần quyền đủ để test, không cần quyền xóa dữ liệu thật, đổi cấu hình production, hoặc gọi API ngoài phạm vi. Tool calling — khả năng model gọi công cụ/API — phải đi kèm allowlist theo suite và môi trường.

Bẫy 3: nhầm lỗi agent với lỗi sản phẩm. Nếu agent không tìm thấy nút vì selector đổi, đó có thể là test fragility. Nếu agent thấy nút nhưng app lưu sai dữ liệu, đó là product bug. Nếu agent quên kiểm tra điều kiện trước khi bấm, đó là capability gap.

Cách phân loại này giúp bạn không kê cùng một toa thuốc cho mọi triệu chứng.

Sau bài này, nên đổi cách nghĩ thế nào?

Đừng hỏi “dùng agent nào để thay QA?”. Hãy hỏi: hệ thống QA của mình đã có đủ lớp để agent fail một cách có ích chưa?

Nếu là mình, mình sẽ bắt đầu từ smoke suite có 5 luồng, CLI trả exit code rõ, artifact bắt buộc, và bảng phân loại lỗi. Sau đó mới tính chuyện chạy song song rộng hơn, tối ưu skill document, hay huấn luyện theo capability.

Agent QA vào production không cần diễn như bác sĩ thiên tài. Nó cần biết ghi hồ sơ, tuân phác đồ, và báo đúng chỗ đau. Chữa release bằng cảm giác thì sớm muộn cũng phải trực đêm.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo