Tiếng Việt: Capstone: Full feature QA lifecycle

Đây là bài capstone của Module 11, và cũng là bài capstone của cả khoá học theo một nghĩa nào đó: nó không dạy kỹ thuật mới, mà ghép toàn bộ kỹ thuật đã học — từ sprint ceremony, dual-context model, generate test, đến QA reporting và văn hoá AI trong team — vào một luồng công việc (workflow) liên tục, chạy trên một feature thật từ lúc backlog refinement đến lúc report cuối sprint. Nếu các bài trước dạy bạn từng công cụ riêng lẻ, bài này dạy bạn cách cầm cả bộ công cụ đó và vận hành như một QA senior thực thụ đang làm việc trong một sprint có deadline, có risk, có stakeholder chờ report. Đọc xong bài này, bạn nên có đủ tự tin để áp dụng nguyên khung này cho feature tiếp theo của chính team bạn — không cần đợi ai hướng dẫn thêm.

Làm Thế Nào Để Chạy Toàn Bộ Vòng Đời QA Agentic Cho Một Feature Thực Tế Từ Đầu Đến Cuối?

Trước khi đi vào chi tiết từng giai đoạn, cần một feature đủ phức tạp để minh hoạ toàn bộ vòng đời — không phải feature "CRUD đơn giản" mà mọi kỹ thuật đều trở nên hiển nhiên, cũng không phải feature quá exotic để không liên hệ được với công việc thực tế của bạn.

Feature Minh Họa: Luồng Upgrade Gói Subscription

Giả sử bạn là QA lead của TaskFlow, một SaaS quản lý công việc nhóm, đang có 3 gói: Basic, Pro, Enterprise. Sprint này, team dev triển khai feature Subscription Plan Upgrade Flow — cho phép user đang dùng Basic tự nâng cấp lên Pro hoặc Enterprise ngay giữa chu kỳ thanh toán (billing cycle), không cần đợi đến ngày renew. Đây là loại feature quen thuộc với bất kỳ QA nào từng làm sản phẩm subscription, và nó "khó" đúng ở những chỗ khiến QA đau đầu thật ngoài đời:

• Proration (tính phí theo tỷ lệ ngày còn lại): khi user upgrade giữa chu kỳ, hệ thống phải tính lại số tiền phải trả — trừ đi phần Basic chưa dùng, cộng vào phần Pro/Enterprise tính theo số ngày còn lại trong tháng.
• Payment retry: nếu thẻ thanh toán bị từ chối, hệ thống tự động thử lại sau 24 giờ, tối đa 3 lần, trước khi coi là thất bại.
• Downgrade lock: user không được downgrade trong vòng 7 ngày kể từ lần thay đổi gói gần nhất — tránh tình trạng "upgrade rồi downgrade ngay" để lợi dụng giá.
• Email xác nhận thay đổi gói: gửi trong vòng 2 phút sau khi upgrade thành công, có nội dung gói mới, ngày hiệu lực, số tiền đã tính prorate.

Đây chính là feature xuyên suốt toàn bài — mọi prompt, mọi ví dụ context, mọi test case minh họa dưới đây đều bám vào feature này, đúng như cách bạn sẽ làm với một feature thật trong sprint của mình.

Tổng Quan 5 Giai Đoạn Của Vòng Đời

Vòng đời QA agentic đầy đủ cho một feature gồm 5 giai đoạn liên tiếp, mỗi giai đoạn dùng lại kỹ thuật đã học ở các bài trước của module:

Bốn mục H2 chính của bài này không đặt tên trực tiếp theo 5 giai đoạn, nhưng ánh xạ rõ vào chúng: mục 1 xử lý Giai đoạn 1; mục 2 xử lý Giai đoạn 2; mục 3 xử lý Giai đoạn 3 (cả 4 loại artifact); mục 4 khép lại bằng việc nhìn lại Giai đoạn 4 và 5 dưới góc độ "AI làm được gì, người phải làm gì" — đúng tinh thần bài "Building a QA AI Culture" đã nói: AI không thay QA, AI thay đổi cách QA làm việc.

Giai Đoạn 1: Đánh Giá Testability Trước Sprint

Trước khi sprint planning chốt, PO đưa user story thô cho feature upgrade gói:

"As a Basic user, I want to upgrade to Pro or Enterprise mid-cycle so that I can access advanced features immediately without waiting for renewal."

Kèm 3 acceptance criteria (AC) sơ sài:
- AC-01: User có thể upgrade từ Basic lên Pro hoặc Enterprise bất kỳ lúc nào.
- AC-02: Hệ thống tính phí prorate.
- AC-03: User nhận email xác nhận.

Đây là lúc bạn chạy testability assessment bằng AI — trước khi story vào sprint, không phải sau. Mục tiêu không phải generate test case ngay, mà là tìm lỗ hổng trong chính spec:

ROLE: You are a senior QA reviewing a user story before it is committed
to sprint planning.

TASK: Review the user story and acceptance criteria below. Do NOT write
test cases. Instead, list every question that must be answered before
this story is testable — group by category:
1) Business rule ambiguity (undefined behavior, no source of truth)
2) Missing edge-case definition (boundary conditions not addressed)
3) Missing non-functional criteria (performance, notification timing,
   idempotency, concurrency)
4) Dependency/integration risk (third-party systems, async processes)

USER STORY:
"As a Basic user, I want to upgrade to Pro or Enterprise mid-cycle so
that I can access advanced features immediately without waiting for
renewal."

ACCEPTANCE CRITERIA:
- AC-01: User can upgrade from Basic to Pro or Enterprise at any time.
- AC-02: The system calculates a prorated charge.
- AC-03: User receives a confirmation email.

Với feature upgrade gói, output thực tế thường trông như thế này (rút gọn):

1. Business rule ambiguity: "Prorate được tính theo ngày calendar hay ngày 24h? Nếu user upgrade lúc 23:55, ngày đó có tính không?"
2. Business rule ambiguity: "Nếu payment thất bại cả 3 lần retry, subscription trở về Basic hay giữ nguyên Pro và chờ user tự thanh toán?"
3. Missing edge-case: "AC không nói gì về việc downgrade sau upgrade — có lock period không?"
4. Missing non-functional: "Email xác nhận có SLA gửi trong bao lâu không? Nếu email service down thì sao?"
5. Dependency risk: "Payment gateway (Stripe/tương tự) có webhook riêng cho payment.failed — hệ thống có xử lý trường hợp webhook đến trễ hoặc trùng (duplicate event) không?"

Đây chính là giá trị lớn nhất của Giai đoạn 1: AI không "biết" nghiệp vụ, nhưng nó rất tốt trong việc soi ra câu chưa được trả lời. Bạn đem danh sách này vào buổi refinement, và chính buổi đó mới sinh ra AC-04 (downgrade lock 7 ngày) và AC-05 (SLA email 2 phút) — hai AC quan trọng nhất của feature mà story gốc hoàn toàn không có.

Mẹo: Luôn chạy testability assessment trước refinement, không phải sau. Nếu chạy sau khi AC đã chốt, bạn chỉ còn tìm được gap ở cấp test case — trong khi chạy trước, bạn còn cơ hội đẩy gap ngược lại thành AC mới, rẻ hơn nhiều so với phát hiện ở giai đoạn test hoặc production.

Làm Thế Nào Để Áp Dụng Dual-Context Model Xuyên Suốt Planning, Generation và Execution?

Sau refinement, spec đã đầy đủ hơn (5 AC, có edge case được liệt ra). Nhưng để generate test có chất lượng, AI cần nhiều hơn một đoạn spec — nó cần hiểu cả nghiệp vụ và cả những gì code thực sự thay đổi. Đây là lúc dual-context model — mô hình đã giới thiệu ở module trước — phát huy giá trị rõ nhất trong toàn bộ vòng đời.

Dual-Context Model Trong Thực Tế

Dual-context model chia context (ngữ cảnh) đưa vào AI thành 2 khối tách biệt, không trộn lẫn:

• Spec context block — mô tả feature nên hoạt động thế nào: user story, AC, edge case, business rule. Đây là "ý định" (intent).
• Code-change context block — mô tả code thực sự thay đổi gì: file nào bị sửa, class/function mới, field mới trong database, PR summary. Đây là "hiện thực" (implementation).

Tách riêng hai khối này quan trọng vì chúng phục vụ hai câu hỏi khác nhau khi review test case: "Test case này có đúng với ý định nghiệp vụ không?" (đối chiếu spec context) và "Test case này có che được đúng phần code vừa thay đổi, tránh test lan man vào phần không đổi không?" (đối chiếu code-change context). Nếu bạn chỉ đưa 1 trong 2, AI sẽ generate test case lệch: chỉ có spec context → test case đúng nghiệp vụ nhưng bỏ sót các implementation detail rủi ro (ví dụ: retry logic dùng cron job chạy mỗi giờ, không phải real-time — ảnh hưởng tới cách viết test timing); chỉ có code-change context → test case bám sát code nhưng dễ trở thành "test theo cách code viết ra", bỏ sót case mà spec yêu cầu nhưng code (có thể) đã bỏ sót.

Xây Dựng Spec Context Block

Spec context block với feature upgrade gói, sau khi đã hoàn thiện qua refinement, có dạng như sau — đây chính là artifact bạn sẽ dán vào đầu mọi prompt generate ở Giai đoạn 3:

## SPEC CONTEXT: Subscription Plan Upgrade Flow

FEATURE SUMMARY:
Basic-tier users can upgrade to Pro or Enterprise mid-billing-cycle.
The system prorates the charge, attempts payment, and locks downgrade
for 7 days after any plan change.

ACCEPTANCE CRITERIA:
- AC-01: User on Basic can upgrade to Pro or Enterprise at any point
  during the current billing cycle. Upgrade takes effect immediately.
- AC-02: Prorated charge = (new plan daily rate - old plan daily rate)
  x remaining full calendar days in the cycle. Partial days (upgrade
  after 00:00 local time) count as a full remaining day.
- AC-03: If payment fails, the system retries automatically at +24h,
  up to 3 attempts. If all 3 fail, the subscription reverts to the
  previous plan and the user is notified in-app and via email.
- AC-04: Downgrade is blocked for 7 days after any plan change
  (upgrade or downgrade). Attempting to downgrade within this window
  returns an explicit "locked" state to the user, not a generic error.
- AC-05: A confirmation email is sent within 2 minutes of a successful
  upgrade, containing: new plan name, effective date, prorated amount
  charged, and next billing date.

KNOWN EDGE CASES (from refinement):
- Upgrade requested on the last calendar day of the billing cycle.
- Upgrade requested twice within seconds (double-click / duplicate
  submit) — must not double-charge.
- Payment gateway webhook for "payment.failed" arrives more than once
  for the same attempt (webhook retry from provider).
- User has an active discount coupon on the Basic plan — coupon must
  not silently apply to the new plan's prorated charge.
- Enterprise plan has custom negotiated pricing (not the public rate)
  for some accounts — proration must use the account's actual rate.
- User is inside a free trial when requesting upgrade.

OUT OF SCOPE FOR THIS STORY:
- Annual billing plans (only monthly billing is affected this sprint).
- Team/seat-based pricing changes (handled in a separate story).

Điểm cần chú ý: block này không phải nguyên văn user story hay AC gốc — nó là bản đã lọc và có cấu trúc, viết lại để máy đọc dễ, con người đọc cũng dễ. Bạn nên duy trì block này như một tài liệu sống, cập nhật mỗi khi refinement phát sinh thêm case mới, và lưu nó cùng chỗ với test documentation của feature (đúng như nguyên tắc quản lý tri thức đã nói ở bài trước của module).

Xây Dựng Code-Change Context Block

Sau khi dev bắt đầu implement (thường vào giữa sprint, khi PR đầu tiên lên), bạn lấy PR/diff thực tế để dựng code-change context block. Không cần convert toàn bộ diff — chỉ cần tóm tắt đủ để AI hiểu phạm vi thay đổi:

## CODE-CHANGE CONTEXT: PR #482 — "Add plan upgrade proration and
payment retry logic"

CHANGED FILES:
- billing/upgrade_service.py       (new: UpgradeService.execute())
- billing/proration_calculator.py  (new: ProrationCalculator class)
- billing/payment_retry_worker.py  (new: cron job, runs hourly,
                                     picks up failed attempts due
                                     for retry)
- api/routes/subscriptions.py      (new endpoint:
                                     POST /subscriptions/{id}/upgrade)
- models/subscription.py           (new field: downgrade_locked_until)
- email/templates/plan_change_confirmation.html (new template)

PR SUMMARY (from author):
"Implements mid-cycle upgrade with proration. Proration is calculated
in ProrationCalculator using the account's stored daily_rate (falls
back to public rate if not set — covers Enterprise custom pricing).
Payment retry is NOT real-time: failed payments are queued and picked
up by an hourly cron (payment_retry_worker.py), so the '24h retry'
requirement is implemented as 'next cron run after 24h has elapsed',
not an exact 24h timer. Idempotency is handled via an Idempotency-Key
header on the upgrade endpoint, stored for 24h. downgrade_locked_until
is set on any plan change (both upgrade and downgrade)."

NOTABLE IMPLEMENTATION DETAILS QA SHOULD KNOW:
- Retry timing is cron-based (hourly tick), not a precise 24h timer —
  test timing assertions must account for this granularity.
- Idempotency key is only honored for 24h; requests reusing an expired
  key are treated as new requests.
- No explicit handling found in the diff for "upgrade requested during
  active free trial" — worth flagging in review, may be an unhandled
  case rather than an intentional out-of-scope decision.

Chú ý dòng cuối: chính từ việc đọc code-change context, bạn phát hiện một khoảng trống mà spec context không nói tới (free trial) — đây là ví dụ cụ thể cho việc dual-context không chỉ giúp generate test tốt hơn, mà còn tự nó là một hình thức review chéo giữa spec và code.

Kết Hợp Hai Context Trong Generation Prompt

Khi generate bất kỳ artifact nào ở Giai đoạn 3 (manual test, API test, E2E test, charter), prompt luôn theo cùng một khung: dán cả 2 block context vào đầu, rồi mới thêm instruction riêng cho loại artifact cần tạo:

[PASTE SPEC CONTEXT BLOCK]

[PASTE CODE-CHANGE CONTEXT BLOCK]

---
TASK: <instruction riêng cho từng loại artifact — xem phần dưới>

Việc luôn dùng cùng một khung này có 2 lợi ích thực tế: (1) bạn không phải soạn lại context từ đầu cho mỗi loại artifact — chỉ copy-paste 2 block rồi đổi phần TASK; (2) khi review 4 loại artifact khác nhau, bạn biết chắc chúng được sinh ra từ cùng một nguồn sự thật, nên không lo tình trạng manual test nói một kiểu, E2E test lại giả định một kiểu khác về cùng một business rule.

Mẹo: Lưu 2 block context này thành 1 file riêng (ví dụ context/upgrade-plan-flow.context.md) trong repo tài liệu test của feature, không lưu rời trong lịch sử chat. Đây chính là artifact quan trọng nhất của cả vòng đời — mất nó, bạn phải dựng lại từ đầu mỗi lần cần generate thêm; giữ nó, bạn tái sử dụng cho mọi lần regression, mọi lần AI thay đổi model, mọi lần onboard QA mới vào feature.

Làm Thế Nào Để Generate Manual Test, API/E2E Test Tự Động và Exploratory Charter Trong Một Workflow?

Đây là Giai đoạn 3 — giai đoạn tốn nhiều thời gian nhất nếu làm tay, và cũng là nơi agentic workflow tạo ra chênh lệch năng suất rõ nhất. Với 2 context block đã có ở trên, bạn generate 4 loại artifact theo một trình tự cố định, không tuỳ tiện.

Thứ Tự Generation

Thứ tự đề xuất — và lý do đằng sau nó — là:

1. Manual test case trước — vì đây là bản "map" đầy đủ nhất về hành vi cần kiểm, dễ review với PO/BA (họ không đọc code test).
2. API test kế tiếp — vì API là lớp gần logic nghiệp vụ nhất (proration, retry, lock), lỗi phát hiện ở đây rẻ và nhanh sửa nhất.
3. E2E test sau đó — vì E2E nên thu hẹp lại chỉ còn các luồng người dùng quan trọng nhất đã được xác nhận đúng ở tầng API, tránh việc E2E test phải gánh luôn cả việc kiểm logic nghiệp vụ (chậm, dễ flaky).
4. Exploratory charter cuối cùng — vì charter nên nhằm vào đúng những chỗ 3 loại test có cấu trúc phía trên không che được, nên bạn cần thấy toàn bộ 3 loại kia trước khi biết charter nên nhằm vào đâu.

Bước 1: Generate Manual Test Case

[PASTE SPEC CONTEXT BLOCK]
[PASTE CODE-CHANGE CONTEXT BLOCK]

---
TASK: Generate manual test cases for QA execution (human tester, no
automation). Cover positive paths, negative paths, and edge cases
from the spec context. For each test case, output:
| Test ID | Title | Precondition | Steps | Expected Result | Priority | Linked AC |

Rules:
- Every edge case listed in "KNOWN EDGE CASES" must map to at least
  one test case.
- Do not merge proration calculation and payment retry into the same
  test case — they must be verifiable independently.
- Flag any test case that depends on the "free trial upgrade" gap
  noted in the code-change context as "BLOCKED — needs clarification".

Output mẫu (rút gọn 5 trong tổng số test case thực tế sẽ dài hơn nhiều):

1. TC-01 — Upgrade từ Basic lên Pro vào giữa chu kỳ, tính đúng số tiền prorate. (Linked AC-02)
2. TC-02 — Upgrade vào ngày cuối cùng của billing cycle, prorate = 1 ngày, không bị tính âm hoặc 0 đồng bất thường. (Linked AC-02, edge case "last day")
3. TC-03 — Payment thất bại lần 1, hệ thống không charge lại ngay mà chờ retry theo cron; sau retry thành công, subscription active đúng gói mới. (Linked AC-03)
4. TC-04 — Payment thất bại cả 3 lần retry, subscription trở về Basic, user nhận cả in-app notification và email. (Linked AC-03)
5. TC-05 — BLOCKED — needs clarification — Upgrade khi đang trong free trial: hành vi không được định nghĩa trong spec context, cần PO xác nhận trước khi viết test case dứt điểm.

Test case số 5 chính là ví dụ sống cho việc dual-context hoạt động đúng: AI không "bịa" ra hành vi cho trường hợp free trial — nó gắn cờ rõ ràng, đẩy trách nhiệm quyết định về đúng người (PO), thay vì QA tự đoán rồi viết test case dựa trên giả định sai.

Bước 2: Generate API Test

[PASTE SPEC CONTEXT BLOCK]
[PASTE CODE-CHANGE CONTEXT BLOCK]

---
TASK: Generate API-level automated test cases (framework-agnostic —
describe request, expected status code, and assertions) for the
endpoint POST /subscriptions/{id}/upgrade.

Cover:
1) Contract-level cases (valid/invalid payload, missing fields)
2) Business-logic cases tied to AC-02, AC-03, AC-04 specifically
3) Idempotency behavior described in the code-change context
   (Idempotency-Key header, 24h expiry)
4) Webhook-driven state changes (payment.failed arriving more than
   once for the same attempt)

For each case, specify: request, expected HTTP status, key assertions
on the response body, and any expected side effect (DB state, queued
job, webhook emitted).

Output mẫu (assertion rút gọn):

• Upgrade hợp lệ Basic → Pro: POST /subscriptions/{id}/upgrade với target_plan=pro → 200 OK, response chứa prorated_amount khớp công thức AC-02, effective_date = ngày hiện tại, subscription record trong DB có plan=pro.
• Downgrade trong lock window: request target_plan=basic khi downgrade_locked_until còn hiệu lực → 409 Conflict, error_code=DOWNGRADE_LOCKED, body chứa locked_until timestamp cụ thể (không phải message chung).
• Duplicate request cùng Idempotency-Key: gửi 2 lần request giống nhau trong 24h với cùng key → lần 2 trả về cùng response với lần 1, không tạo thêm charge, DB chỉ có 1 record giao dịch.
• Idempotency key đã hết hạn (>24h): request lặp lại với key cũ hơn 24h → được xử lý như request mới, không trả kết quả cache — assertion phải kiểm tra có charge thứ 2 phát sinh thật.
• Webhook payment.failed gửi trùng (duplicate event) cho cùng attempt: hệ thống chỉ tăng retry_count đúng 1 lần, không tăng gấp đôi dù webhook đến 2 lần.

Bước 3: Generate E2E Test

[PASTE SPEC CONTEXT BLOCK]
[PASTE CODE-CHANGE CONTEXT BLOCK]

---
TASK: Generate E2E test scripts (Playwright-style, describe as
step-by-step actions + assertions, not full code) for the critical
user-facing paths only — do not re-test business logic already
covered at the API layer. Focus on: what the user sees and can
verify visually/interactively.

Scope: exactly 4 scenarios —
1) Successful upgrade happy path, confirming UI feedback and amount
   shown matches what will be charged.
2) Payment failure shown to user with a retry countdown/status,
   not a dead-end error.
3) Downgrade attempt blocked, with a clear "locked until <date>"
   message in the UI (not a generic error banner).
4) Confirmation email content check (can be a mocked inbox check).

Output mẫu:

1. E2E-01: Đăng nhập user Basic → vào Billing → chọn "Upgrade to Pro" → xem preview số tiền prorate hiển thị đúng trước khi confirm → confirm → thấy banner "Upgraded to Pro" → refresh trang, plan hiển thị đúng là Pro.
2. E2E-02: Giả lập thẻ bị từ chối (dùng test card của payment gateway) → user thấy trạng thái "Payment failed — retrying" kèm thời điểm retry tiếp theo, không phải màn hình lỗi cụt.
3. E2E-03: User vừa upgrade xong, thử downgrade ngay → UI hiển thị rõ "Bạn không thể đổi gói cho đến [ngày]", có ngày cụ thể, không chỉ là "Action not allowed".
4. E2E-04: Sau upgrade thành công, kiểm tra mailbox test (qua mail-catcher tool) trong vòng 2 phút, xác nhận email chứa đúng plan mới, effective date, và số tiền đã charge — khớp với số hiển thị ở bước E2E-01.

Bước 4: Generate Exploratory Charter

[PASTE SPEC CONTEXT BLOCK]
[PASTE CODE-CHANGE CONTEXT BLOCK]

---
TASK: The manual, API, and E2E test suites above already cover the
scenarios explicitly defined in the spec. Generate exploratory test
charters (session-based test management style: charter statement,
areas to explore, timebox, risk framing) for areas that are NOT
fully determined by the spec — where behavior depends on timing,
concurrency, or interaction between subsystems rather than a single
clear rule.

Generate exactly 3 charters, each with a distinct risk angle.

Output mẫu:

• Charter 1 — "Explore race conditions around double-submit and concurrent plan changes." Timebox 60 phút. Khu vực khám phá: click "Upgrade" nhiều lần liên tiếp, mở 2 tab cùng thực hiện upgrade song song, thử upgrade ngay trong lúc một retry payment khác đang chạy nền cho cùng subscription. Rủi ro: double-charge hoặc state subscription không nhất quán giữa các tab.
• Charter 2 — "Explore timezone and calendar-boundary behavior around proration." Timebox 45 phút. Khu vực khám phá: đổi timezone của tài khoản test, thử upgrade quanh mốc nửa đêm, thử với tháng có số ngày khác nhau (28/30/31 ngày), kiểm tra proration có bị lệch 1 ngày (off-by-one) không.
• Charter 3 — "Explore UI/communication clarity during the payment-retry window." Timebox 45 phút. Khu vực khám phá: trải nghiệm người dùng thực tế trong 3 lần retry — họ có bị bối rối, có nhận được thông tin đủ để biết chuyện gì đang xảy ra với tiền của họ không, có bị spam nhiều email/notification trùng lặp không. Đây là charter thiên về đánh giá cảm nhận (UX judgment), không phải đúng/sai kỹ thuật thuần túy.

Mẹo: Khi generate charter, luôn ép AI giải thích "vì sao case này không nằm trong 3 loại test có cấu trúc phía trên" (như đã làm ở TASK trên). Nếu AI không giải thích được, nhiều khả năng đó là case nên đưa vào test case có cấu trúc, không phải charter — exploratory chỉ nên dành cho vùng thật sự mơ hồ về hành vi, không phải nơi "giấu" case mà bạn lười viết structured test.

Agentic QA Workflow Tự Động Bắt Được Gì, Và Đâu Là Chỗ Human Judgment Vẫn Không Thể Thay Thế?

Sau khi chạy hết 5 giai đoạn cho feature upgrade gói — assessment, dual-context, generate 4 loại artifact, execute, rồi tổng hợp report cuối sprint theo kỹ thuật đã học ở bài "QA Reporting và Metrics" — câu hỏi quan trọng nhất không phải "AI làm được gì" mà là "AI làm được gì tốt hơn con người làm tay, và ở đâu con người vẫn phải là người ra quyết định cuối." Đây là câu hỏi cốt lõi của tinh thần Agentic QA đã xuyên suốt cả khoá học.

Những Gì Agentic Workflow Tự Động Bắt Được

Những Chỗ Human Judgment Vẫn Không Thể Thay Thế

Mô Hình Kết Hợp Human-AI Tích Hợp

Nhìn hai bảng trên cùng lúc, một mẫu hình rõ ràng xuất hiện: AI mạnh ở breadth (độ rộng, không bỏ sót) và consistency (nhất quán), con người mạnh ở judgment (đánh giá theo ngữ cảnh) và accountability (chịu trách nhiệm). Mô hình cộng tác đúng không phải "AI làm hết, người review qua loa" — cũng không phải "người làm hết, AI chỉ hỗ trợ gõ chữ". Mô hình đúng là: AI phụ trách toàn bộ bề rộng đầu tiên của mỗi giai đoạn (assessment, generation), con người phụ trách quyết định cuối ở từng điểm rẽ quan trọng (chốt AC, chốt case nào chạy trước, chốt case nào cần PO trả lời, chốt go/no-go). Đây đúng là điều bài "Building a QA AI Culture" đã nói ở cấp độ văn hoá team — bài này chỉ là minh chứng cụ thể, từng dòng prompt, cho việc mô hình đó vận hành ra sao trên một feature thật.

Mẹo: Sau mỗi sprint áp dụng workflow này, giữ lại đúng 2 bảng như trên (đã catch tự động / cần human judgment) nhưng điền bằng case thật của feature đó, không phải case ví dụ. Sau vài sprint, bạn sẽ có một tài liệu sống cho biết chính xác team mình cần đầu tư kỹ năng con người vào đâu — đó là tài liệu định hướng training QA hữu ích hơn nhiều so với một khoá học chung.

Tự Chạy Capstone Của Riêng Bạn

Đây là checklist thực hành — áp dụng đúng 5 giai đoạn trên cho một feature thật của team bạn trong sprint tới:

1. Chọn một feature sắp vào sprint có ít nhất 2 trong số các đặc điểm: có business rule tính toán (như proration), có xử lý bất đồng bộ/retry, có ràng buộc theo thời gian, có tích hợp bên thứ ba. Feature quá đơn giản sẽ không cho bạn thấy giá trị đầy đủ của workflow.
2. Giai đoạn 1: Trước refinement, chạy prompt testability assessment trên story thô. Ghi lại số câu hỏi phát sinh — dùng chính số này làm minh chứng giá trị khi trình bày lại với team.
3. Giai đoạn 2: Sau refinement, dựng spec context block. Sau khi PR đầu tiên lên, dựng code-change context block. Lưu cả hai vào một file trong repo tài liệu, không phải trong lịch sử chat.
4. Giai đoạn 3: Generate đúng theo thứ tự manual → API → E2E → exploratory charter, dùng lại nguyên khung 2 block context + TASK riêng cho từng loại, như các ví dụ ở trên.
5. Giai đoạn 4 & 5: Execute test đã review, rồi tổng hợp report theo cấu trúc đã học ở bài QA Reporting — nhưng thêm một mục riêng: "AI catch tự động" vs "Cần quyết định của người", theo đúng 2 bảng ở mục trên.
6. Cuối sprint, tự chấm điểm workflow bằng 3 câu hỏi: Có case nào production tìm ra mà cả 4 loại artifact đều bỏ sót không — nếu có, đó là chỗ cần bổ sung vào context cho lần sau. Có case nào AI generate ra nhưng hoá ra vô nghĩa/không khả thi — nếu có, đó là dấu hiệu context bạn đưa vào còn thiếu ràng buộc kiến trúc thực tế. Team có tiết kiệm được thời gian rõ rệt ở giai đoạn generate so với làm tay không — nếu không, quay lại xem prompt đã đủ cụ thể chưa, hay đang generate chung chung.

Chạy đúng quy trình này một lần cho một feature thật, bạn sẽ có bằng chứng cụ thể — không phải lý thuyết — để nhân rộng cách làm này ra toàn bộ team QA của bạn.