Nếu bạn đã đi qua bảy module trước của khoá học, bạn đã có trong tay từng "mảnh ghép" riêng lẻ: cách viết prompt hiệu quả, cách nạp context cho agent, cách để AI sinh test plan, cách để AI viết test case và script automation, cách dùng AI để explore ứng dụng, cách để agent chạy trong CI/CD (continuous integration/continuous deployment — tích hợp và triển khai liên tục) và giữ context xuyên suốt pipeline. Nhưng trong công việc thực tế, không ai làm việc theo từng mảnh rời rạc như vậy. Bạn cần một vòng lặp (loop) liền mạch, có điểm bắt đầu rõ ràng, có điểm kết thúc rõ ràng, và có thể lặp lại được cho mọi feature, mọi sprint.
Đây chính là mục tiêu của topic này: ráp toàn bộ các kỹ năng bạn đã học thành một quy trình agentic QA hoàn chỉnh, đi từ lúc có một spec (hoặc một đoạn code diff) cho tới lúc bạn tự tin gật đầu "go" để release. Đây là bài tổng hợp (capstone) của Module 8, nên tôi sẽ không dạy lại kỹ thuật viết prompt hay kỹ thuật test case generation — thay vào đó tôi sẽ chỉ cho bạn cách các kỹ thuật đó "khớp" vào nhau ra sao, ở đâu cần con người can thiệp, và ở đâu bạn có thể để agent tự chạy.
Toàn cảnh vòng lặp agentic QA từ spec đến khi lên production trông như thế nào?
Hãy tưởng tượng vòng lặp agentic QA như một dây chuyền có 7 trạm (stage), mỗi trạm nhận input từ trạm trước và tạo ra một output cụ thể cho trạm sau. Tôi hay vẽ nó lên bảng cho junior QA như sau:
[Stage 1: Context/Spec Capture]
│
▼
[Stage 2: AI-Generated Test Plan]
│
▼
[Stage 3: Test Case + Automated Script Generation]
│
▼
[Stage 4: CI Execution]
│
▼
[Stage 5: AI-Guided Exploratory Testing] ◄── runs in parallel with Stage 4
│
▼
[Stage 6: Triage & Bug Report]
│
▼
[Stage 7: Coverage Report / Go-No-Go]
│
└──► loops back to Stage 1 for the next sprint/feature
Điểm khác biệt căn bản giữa vòng lặp này và quy trình QA truyền thống là: ở mỗi trạm, bạn không "làm thủ công" mà bạn điều phối agent làm rồi review output của nó. Vai trò của QA engineer chuyển từ "người thực thi" sang "người ra brief, review, và quyết định" — giống như một tech lead điều phối một đội junior cực kỳ nhanh nhưng thiếu context về domain.
Một điều quan trọng cần nhấn mạnh ngay từ đầu: vòng lặp này không tuyến tính hoàn toàn. Stage 5 (exploratory testing) thường chạy song song với Stage 4 (CI execution) chứ không phải chờ CI xong mới bắt đầu — vì exploratory testing tập trung vào những góc mà automated test không phủ tới, nên nó không cần đợi kết quả automation. Và toàn bộ vòng lặp là một chu kỳ (cycle) — Stage 7 không phải là điểm kết mà là điểm quay lại Stage 1 cho iteration kế tiếp.
Ví dụ thực tế: team tôi làm một tính năng "bulk export báo cáo" cho một sản phẩm fintech. Từ lúc PM viết xong spec đến lúc release, toàn bộ 7 trạm trên chạy trong khoảng 1.5 ngày làm việc — so với khoảng 4 ngày nếu làm thủ công 100%. Tốc độ không đến từ việc AI "code nhanh hơn người", mà đến từ việc loại bỏ các khoảng chờ (idle time) giữa các trạm: test plan có ngay sau khi spec chốt, test case có ngay sau khi plan được duyệt, script chạy được ngay khi case viết xong.
Mẹo: Đừng cố áp toàn bộ 7 trạm cho mọi thay đổi. Với một bug fix nhỏ 3 dòng code, bạn có thể gộp Stage 2 và Stage 3 lại (hỏi agent "generate test plan and test cases in one pass for this diff"), bỏ qua Stage 5 hoàn toàn. Vòng lặp đầy đủ dành cho feature lớn hoặc thay đổi có rủi ro cao; đừng biến nó thành thủ tục hành chính rườm rà cho mọi PR.
Các module trước đã "nạp" gì vào vòng lặp thống nhất này?
Mỗi module trước trong khoá học tương ứng với một trạm (hoặc một kỹ năng nền cho nhiều trạm). Việc hiểu bản đồ này giúp bạn biết "quay lại module nào" khi bị kẹt ở một trạm cụ thể trong vòng lặp.
- Module về context engineering → nền tảng cho Stage 1. Kỹ năng đóng gói spec, tài liệu design, code liên quan thành context mà agent hiểu được, không bị tràn context window (giới hạn lượng văn bản model xử lý được trong một lần) và không bị "lạc trôi" giữa các file không liên quan.
- Module về viết prompt hiệu quả → chạy xuyên suốt mọi trạm, nhưng đậm nhất ở Stage 2 và Stage 3, nơi chất lượng prompt quyết định trực tiếp chất lượng test plan và test case sinh ra.
- Module về AI test planning → chính là "động cơ" của Stage 2. Bạn đã học cách yêu cầu agent phân tích spec, liệt kê risk area, đề xuất test strategy (positive/negative/edge case, boundary, security...).
- Module về AI test case generation → nền cho phần đầu của Stage 3, sinh ra test case ở dạng đọc được (Gherkin, bảng, checklist).
- Module về AI-assisted automation → nền cho phần sau của Stage 3, biến test case thành script chạy được (Playwright, Cypress, REST Assured, v.v.).
- Module về AI exploratory testing → nền cho Stage 5, dùng agent như một "bạn khám phá" tìm ra những case bạn không nghĩ tới khi viết test case theo spec.
- Module về persistent context cho CI agent → nền cho Stage 4 và Stage 6, giữ agent "nhớ" được lịch sử chạy, flaky test, cấu hình môi trường qua nhiều lần chạy pipeline mà không phải build lại context từ đầu mỗi lần.
Cách tôi khuyên bạn dùng bản đồ này: khi review lại vòng lặp cho project của bạn, hãy đánh dấu trạm nào team đang yếu nhất (ví dụ: Stage 3 sinh script sai selector liên tục), rồi quay lại module tương ứng để ôn kỹ thuật, thay vì cố "vá" ở tầng vòng lặp.
Mẹo: Tạo một file context/module-map.md trong repo doc của team, note lại "trạm nào dùng kỹ thuật nào, quy về module nào" — khi có QA mới join, họ dùng file này để tự tra cứu thay vì hỏi lại bạn từng câu.
Điểm khởi đầu của vòng lặp: bắt đầu từ spec, từ code diff, hay dùng cả hai?
Trong thực tế, bạn hiếm khi bắt đầu vòng lặp agentic QA từ con số 0 với một trang trắng. Có ba kiểu điểm khởi đầu (entry point), và việc chọn đúng điểm khởi đầu quyết định chất lượng của toàn bộ chuỗi sau đó — chọn sai, agent sẽ sinh ra test plan lệch hướng ngay từ Stage 2.
Entry Point 1: Spec-First
Đây là kịch bản "sách giáo khoa": bạn có một spec hoàn chỉnh (PRD, user story kèm acceptance criteria, hoặc Figma + mô tả nghiệp vụ) trước khi code được viết ra, hoặc song song với lúc dev bắt đầu code.
Ưu điểm của entry point này là agent có đầy đủ "ý định nghiệp vụ" (business intent) ngay từ đầu — nó biết feature này giải quyết vấn đề gì cho user, không chỉ biết "code làm gì". Điều này giúp Stage 2 (test plan) bao quát được cả các case về trải nghiệm người dùng, không chỉ case kỹ thuật.
Nhược điểm: spec thường viết trước khi code tồn tại, nên sẽ có khoảng lệch (drift) giữa spec và implementation thực tế — dev có thể đổi hành vi so với spec ban đầu mà không update lại tài liệu. Nếu bạn chỉ dựa vào spec mà không đối chiếu code, test case sinh ra có thể test đúng "spec nói vậy" nhưng sai với "code làm vậy".
Ví dụ prompt khởi động cho Stage 1 khi đi theo entry point này:
You are a senior QA engineer. I'm giving you a product spec for a new feature.
Read the spec below and produce a structured summary covering:
1. Core user goal
2. Explicit acceptance criteria (list each one, numbered)
3. Any ambiguous or underspecified requirements you notice
4. Systems/APIs/data this feature likely touches, based on the description
Spec:
"""
<paste spec content here>
"""
Do not generate test cases yet. Just confirm you understand the spec correctly.
Lý do tôi luôn thêm câu "Do not generate test cases yet" — vì các agent hiện đại rất "hăng", cứ thấy spec là nhảy thẳng vào sinh test case, bỏ qua bước xác nhận hiểu đúng ý. Bước xác nhận này cực kỳ quan trọng: nếu agent hiểu sai spec ngay từ Stage 1, sai lầm đó sẽ lan truyền và khuếch đại qua toàn bộ 6 trạm còn lại.
Entry Point 2: Code-Change-First
Kịch bản này phổ biến hơn Spec-First trong môi trường brownfield (dự án đã chạy lâu, thay đổi nhỏ liên tục): bạn không có spec chính thức, thứ bạn có là một pull request, một diff, hoặc một Jira ticket ngắn gọn kiểu "fix bug X" mà không có tài liệu chi tiết.
Bước đầu tiên bắt buộc là capture cái diff — lấy chính xác phần code đã thay đổi, không phải toàn bộ file. Lý do: nếu bạn đưa nguyên file 2000 dòng vào context, agent sẽ tốn effort để phân tích cả phần code không liên quan, và dễ bị "phân tán" khỏi phần thực sự thay đổi. Lệnh tôi hay dùng:
git diff main...feature/bulk-export --unified=10 > /tmp/qa-context/diff.patch
git log main...feature/bulk-export --oneline > /tmp/qa-context/commits.txt
Việc thêm --unified=10 (lấy 10 dòng context quanh mỗi đoạn thay đổi thay vì mặc định 3 dòng) giúp agent thấy được đủ ngữ cảnh xung quanh dòng sửa — ví dụ thấy được cả function signature, cả điều kiện guard clause phía trên — mà không cần nạp cả file.
Sau khi có diff, bước tiếp theo là chạy một planning prompt dựa trên diff đó, ví dụ:
Here is a git diff for a bug fix in our payment reconciliation service.
Analyze the diff and answer:
1. What behavior changed, in plain language?
2. What existing behavior could this change have broken (regression risk)?
3. What edge cases does this diff NOT seem to handle?
4. Based on the code, infer 3-5 acceptance criteria this fix is likely trying to satisfy.
Diff:
"""
<paste diff.patch content>
"""
Điểm mấu chốt ở đây là câu hỏi số 4 — bắt agent "suy ngược" acceptance criteria từ code, vì không có spec để tham chiếu. Đây là kỹ thuật "reverse-engineer intent from implementation", rất hữu ích khi làm việc với legacy code hoặc ticket viết sơ sài.
Nhược điểm lớn nhất của Code-Change-First: agent chỉ biết "code làm gì", không biết "code lẽ ra phải làm gì". Nếu bug fix đó thực ra sửa sai hướng (fix đúng symptom nhưng sai root cause), agent dựa trên diff sẽ không phát hiện ra, vì nó không có nguồn sự thật độc lập để đối chiếu.
Entry Point 3: Dual-Context (Đề Xuất)
Đây là cách tôi khuyên dùng mặc định cho mọi feature có độ phức tạp trung bình trở lên: nạp cả spec và diff cùng lúc vào context cho agent, để nó tự đối chiếu hai nguồn với nhau.
Việc chuẩn bị cả hai nguồn context đòi hỏi một chút kỷ luật tổ chức. Tôi thường tạo cấu trúc thư mục tạm cho mỗi feature như sau trước khi bắt đầu vòng lặp:
qa-context/bulk-export-feature/
├── spec.md # Original PRD or user story, copied verbatim
├── diff.patch # git diff of the entire related PR
├── api-schema.json # Related OpenAPI/schema, if any
└── prior-bugs.md # Related bugs that occurred before in this module (if any)
Prompt khởi động cho dual-context thường trông như sau:
You are a senior QA engineer preparing to design a test plan.
I'm giving you TWO sources: the original product spec, and the actual code diff
that implements it. Cross-reference them and report:
1. Requirements in the spec that are NOT reflected in the diff (missing implementation)
2. Behavior in the diff that is NOT described in the spec (undocumented behavior —
could be intentional, could be scope creep)
3. Any direct contradictions between spec and diff
4. A confidence rating (High/Medium/Low) on how completely this diff satisfies the spec
Spec:
"""
<spec.md content>
"""
Diff:
"""
<diff.patch content>
"""
Tôi có thể kể một case thật: team tôi review một feature "cho phép user hủy đơn hàng trong vòng 24h". Spec ghi rõ "24 giờ kể từ lúc đặt hàng". Khi cho agent đối chiếu diff, nó phát hiện code implement lại tính "24 giờ kể từ lúc đơn hàng được confirm bởi seller" — chứ không phải lúc đặt. Đây là một lệch hành vi (behavior drift) rất dễ bị người review code bỏ sót vì logic vẫn "đúng cú pháp", nhưng dual-context đối chiếu ra ngay ở Stage 1, trước khi tốn công viết test case cho hành vi sai.
Nhược điểm duy nhất của Dual-Context là tốn thêm một bước chuẩn bị và tốn thêm token (đơn vị văn bản mà model tính chi phí xử lý) so với chỉ dùng một nguồn — nhưng đổi lại, nó bắt được đúng loại lỗi nguy hiểm nhất: lỗi mà cả code lẫn spec "tự nó nhìn thì đều hợp lý", chỉ sai khi đặt cạnh nhau.
Mẹo: Khi PR không có Jira ticket liên kết rõ ràng, đừng bỏ qua Entry Point 3. Hãy chủ động hỏi tác giả PR "spec cho cái này ở đâu" trước khi bắt đầu — nếu không có spec chính thức, dùng chính commit message + PR description làm "spec thay thế" cho agent đối chiếu, còn hơn chạy Code-Change-First một mình.
Vòng lặp agentic QA tạo ra output gì ở mỗi trạm?
Một trong những lỗi tôi thấy nhiều QA mới học agentic workflow mắc phải là: chạy agent, đọc câu trả lời trên chat, rồi... không lưu lại gì cả. Vòng lặp chỉ thực sự có giá trị khi mỗi trạm tạo ra một artifact (sản phẩm/tài liệu đầu ra) cụ thể, có thể lưu vào version control, review được, và trạm sau dùng lại được. Phần này liệt kê rõ output kỳ vọng ở từng trạm.
Stage 2 Output: Test Plan Do AI Sinh Ra
Output của Stage 2 không phải là một đoạn chat trả lời, mà phải là một file test plan có cấu trúc, thường ở dạng Markdown, lưu trong repo (ví dụ test-plans/bulk-export-v1.md). Một test plan tốt do agent sinh ra cần có tối thiểu các phần:
- Scope: những gì được test, những gì cố ý không test (out of scope) và lý do.
- Risk areas: liệt kê theo mức độ rủi ro (cao/trung/thấp), ví dụ "tính sai số lượng dòng dữ liệu export khi > 10,000 record" là risk cao với feature bulk export.
- Test approach theo layer: unit / API / UI / performance / security — không phải mọi feature cần cả 5 layer.
- Test data cần chuẩn bị: ví dụ "cần seed account có > 50,000 record để test performance export".
- Entry/exit criteria: khi nào bắt đầu test được (feature deploy lên staging), khi nào coi là "đủ" để chuyển sang Stage 3.
Sai lầm phổ biến: nhận test plan từ agent rồi copy-paste thẳng vào repo không đọc kỹ. Test plan do AI sinh thường rất đầy đủ về mặt hình thức nhưng có thể generic hoá quá mức ở phần risk area — ví dụ nó liệt kê "test injection ở input field" cho mọi form, kể cả form không nhận input tự do. QA lead vẫn phải đọc và cắt bớt phần không phù hợp trước khi merge test plan vào repo.
Stage 3 Output: Test Case Và Script Tự Động Hoá
Stage 3 tạo ra hai lớp output riêng biệt, không nên gộp chung:
- Test case ở dạng con người đọc được — thường là Gherkin (
Given/When/Then) hoặc bảng test case, lưu ởtest-cases/bulk-export/TC-001-export-under-10k-rows.md. Lớp này dùng để review với PM/BA, và dùng làm tài liệu tham chiếu khi automation bị lỗi. - Script tự động hoá thực thi được — file code thật, ví dụ
e2e/bulk-export/export-flow.spec.ts(Playwright) hoặctests/api/test_export_endpoint.py(pytest). Lớp này commit vào repo automation, chạy được trong CI ngay.
Ví dụ prompt để agent tạo cả hai lớp cùng lúc, giữ chúng đồng bộ với nhau:
Based on this test plan and the API schema below, generate:
1. A Gherkin-style test case document (Markdown) — human readable, one scenario per file section
2. A corresponding Playwright test file in TypeScript that automates each scenario
Make sure scenario names in the Gherkin doc match the `test()` block titles in the
Playwright file exactly, so we can trace one to the other.
Test plan: <paste>
API schema: <paste>
Chi tiết "làm sao khớp tên scenario giữa hai file" nghe nhỏ nhưng cực kỳ quan trọng khi maintain lâu dài — nếu 6 tháng sau một test tự động fail, người debug cần tìm ngay được test case gốc mô tả ý định của nó bằng tên, không phải đọc code để đoán.
Stage 4 Output: Kết Quả Chạy CI
Output của Stage 4 là kết quả thực thi — không phải do AI "viết ra" mà do pipeline chạy ra, nhưng agent tham gia ở việc diễn giải kết quả đó. Output cụ thể gồm:
- Report chuẩn (JUnit XML, Allure report, hoặc HTML report từ Playwright) — artifact máy đọc được, lưu trong CI history.
- Một bản tóm tắt do agent viết, dịch report kỹ thuật thành ngôn ngữ dễ hiểu cho stakeholder không kỹ thuật: "18/20 test pass, 2 fail đều liên quan tới timeout khi export > 50,000 dòng, nghi ngờ do timeout config chưa tăng cho case lớn".
- Phân loại flaky test (test không ổn định — lúc pass lúc fail dù code không đổi) — agent với persistent context (đã học ở module trước) có thể so sánh lịch sử chạy để gắn nhãn "test này fail 3/10 lần gần nhất không liên quan tới code diff hiện tại → khả năng flaky, không phải regression thật".
Ví dụ prompt để agent diễn giải report CI thành bản tóm tắt:
You are a QA engineer summarizing a CI test run for a non-technical stakeholder.
Here is the raw JUnit XML / Allure report below. Produce:
1. A one-paragraph, plain-language summary (pass rate, most severe failure first)
2. For each failure: a root-cause hypothesis in plain language (timeout, assertion
mismatch, environment/config issue, data setup issue...)
3. For each failing test, check the last 5 run histories below and flag it as
"likely flaky" if it failed intermittently without any related code change,
or "likely regression" if the failure correlates with a recent diff
4. One final recommendation: safe to proceed to exploratory testing / needs
investigation before proceeding
CI report:
"""
<paste JUnit XML / Allure report content>
"""
Run history (last 5 runs per test, if available):
"""
<paste run history>
"""
Đây là điểm agent tạo giá trị lớn nhất ở Stage 4: không phải chạy test (máy làm việc đó), mà là rút ra insight từ hàng chục/hàng trăm log dài dòng nhanh hơn con người đọc thủ công.
Stage 5 Output: Kết Quả Exploratory Testing
Vì exploratory testing về bản chất không theo script cố định, output ở đây khác hẳn: là một log các phát hiện (findings log), không phải pass/fail.
Trước khi có log, bạn cần một charter (kịch bản thăm dò) để agent biết nên tập trung khám phá vùng nào trong session, thay vì đi lang thang vô định. Ví dụ prompt tạo charter dựa trên diff:
Based on this code diff for the bulk export feature, generate an exploratory
testing charter for a 45-minute session. The charter should:
1. Identify the 3 riskiest areas of this diff to explore manually, and explain
why each one is risky (complex logic, touches shared code, no existing test...)
2. For each risky area, suggest 2-3 concrete directions to explore — not scripted
steps, but starting points a tester can improvise from
3. List what NOT to bother exploring, because Stage 3 automation already covers it
Diff:
"""
<paste diff.patch content>
"""
Sau khi chạy charter, kết quả ghi lại theo format tôi hay dùng, lưu ở exploratory-logs/bulk-export-session-1.md:
## Session: Bulk Export — Exploratory Round 1
Agent explored: filter combinations, boundary of row count, concurrent export requests
### Findings
1. [Potential bug] Exporting with filter "date range = future dates" returns empty file
with no warning message — user may think export is broken.
2. [UX concern] No progress indicator when export > 20,000 rows — session felt frozen
for ~8 seconds.
3. [Confirmed working] Concurrent export requests from same user correctly queue,
don't corrupt file.
Điểm khác biệt so với bug report chính thức (Stage 6): log này chưa qua triage, mức độ nghiêm trọng chưa được đánh giá, có thể chứa cả false positive. Đây là raw material, cần con người/agent xử lý tiếp ở Stage 6.
Stage 6 Output: Triage Và Bug Report
Output Stage 6 là các bug report đã được chuẩn hoá, sẵn sàng đưa vào issue tracker (Jira, Linear). Agent hỗ trợ triage bằng cách gộp finding từ Stage 4 (regression) và Stage 5 (exploratory) lại, rồi phân loại theo severity/priority, viết thành ticket có đủ: steps to reproduce, expected vs actual, môi trường, mức độ ảnh hưởng.
Ví dụ prompt triage:
Here are 5 raw findings from exploratory testing and 2 failed automated tests.
For each item:
1. Classify severity (Blocker/Critical/Major/Minor) and justify in one sentence
2. Draft a bug ticket title + description in the format our team uses:
"[Component] Short description — Steps / Expected / Actual"
3. Flag any duplicates between the exploratory findings and automated failures
<paste findings + failures>
Sai lầm cần tránh: để agent tự set severity mà không có ai review, đặc biệt là gắn "Blocker" quá tay. Agent thường thiếu context về business priority thực tế (ví dụ: bug này ảnh hưởng 0.1% user hay 40% user) — QA lead vẫn cần điều chỉnh severity dựa trên context nghiệp vụ agent không có.
Stage 7 Output: Báo Cáo Coverage
Đây là output cuối cùng, dùng để ra quyết định go/no-go. Coverage report tổng hợp không chỉ số liệu (% test case pass, % code coverage) mà quan trọng hơn là coverage theo risk area đã định nghĩa ở Stage 2 — trả lời câu hỏi "chúng ta đã test đủ những vùng rủi ro cao chưa", không chỉ "chúng ta đã chạy bao nhiêu test".
Ví dụ prompt để agent tổng hợp coverage report từ các artifact của các trạm trước:
You have four inputs: the original test plan (with risk areas), the CI execution
results, the exploratory testing findings log, and the triage summary with bug
severities. Cross-reference all four and produce a coverage report table with
columns: Risk Area | Coverage Status (Fully covered / Partially covered / Gap
identified) | Notes.
Then add a final Go/No-Go recommendation with a one-sentence justification,
explicitly calling out any Blocker/Critical bug that is still unresolved.
Test plan: <paste>
CI results: <paste>
Exploratory findings: <paste>
Triage summary: <paste>
Một coverage report tốt do agent tổng hợp thường có dạng:
## Coverage Report: Bulk Export Feature — Release Candidate 1
| Risk Area (from test plan) | Coverage Status | Notes |
|---|---|---|
| Export correctness < 10k rows | Fully covered | 12/12 automated tests pass |
| Export performance > 50k rows | Partially covered | Manual test done, automation pending |
| Concurrent export requests | Fully covered | Automated + exploratory confirmed |
| Export with future date filter | Gap identified | Bug ticket QA-482 filed, unresolved |
Recommendation: NO-GO until QA-482 is resolved or explicitly accepted as known issue.
Recommendation cuối bài — go/no-go — là quyết định con người phải ký tên chịu trách nhiệm, agent chỉ tổng hợp dữ liệu để hỗ trợ ra quyết định nhanh hơn, không thay thế người quyết định. Đây cũng là nguyên tắc tổng của cả 7 trạm: agent làm nặng phần thu thập-tổng hợp-sinh nội dung, con người vẫn giữ vai trò review-quyết định ở từng điểm chuyển giao quan trọng.
Mẹo: Đừng chỉ lưu coverage report dạng file tĩnh cuối sprint. Hãy để agent update lại report này ngay khi có bug mới được fix hoặc test mới pass, biến nó thành "living document" (tài liệu sống, luôn được cập nhật theo tiến độ) trong suốt giai đoạn regression — team sẽ nhìn vào đúng một nguồn để biết "còn thiếu gì trước khi release" thay vì hỏi rải rác trên chat.
Khép lại: vòng lặp agentic QA không phải để bạn chạy một lần rồi xong — nó là khung làm việc bạn lặp lại mỗi sprint, mỗi feature, thậm chí mỗi PR (ở quy mô rút gọn). Giá trị thật của nó không nằm ở việc "AI viết test case hộ bạn" — cái đó chỉ là Stage 3. Giá trị thật nằm ở việc bạn có một chuỗi artifact liên tục, review được, truy vết được, từ dòng đầu tiên trong spec tới dòng cuối cùng trong coverage report. Khi một bug production xuất hiện sau này, bạn có thể lần lại: spec nói gì, test plan có cover risk đó không, test case nào lẽ ra phải bắt được nó, và vì sao nó lọt lưới. Đó là thứ phân biệt một QA process "có AI" với một QA process "agentic" thực sự.