Tiếng Việt: Hands-on: Full test strategy for a feature

Đến thời điểm này trong module, bạn đã học riêng lẻ từng kỹ thuật: viết prompt phân tích rủi ro, dùng AI để xác định coverage goal (mục tiêu độ phủ), map test level cho từng loại rủi ro. Bài học này gộp tất cả lại thành một quy trình end-to-end, để bạn thực hành từ đầu đến cuối trên một feature thực tế: User Account Subscription Management — module quản lý gói đăng ký tài khoản người dùng.

Đây là bài hands-on nên hãy chuẩn bị một cửa sổ chat với LLM (ChatGPT, Claude, hoặc bất kỳ agent nội bộ nào công ty bạn đang dùng) để chạy song song theo từng bước. Mục tiêu cuối bài: bạn có trong tay một bộ test strategy hoàn chỉnh, đã qua review, và một template có thể tái sử dụng cho các feature tương tự sau này.

Làm Sao Biến Một User Story Thành Test Strategy Hoàn Chỉnh Do AI Tạo Ra?

Câu hỏi lớn nhất mà QA mới làm việc với AI thường gặp: "Tôi có một user story (câu chuyện người dùng — mô tả ngắn gọn một yêu cầu chức năng dưới góc nhìn người dùng cuối), làm sao biến nó thành một test strategy đầy đủ mà không mất cả buổi họp?" Câu trả lời nằm ở cách bạn chuẩn bị input trước khi đưa cho AI, và cách bạn thiết kế prompt để AI trả về đúng những gì bạn cần, đúng format, đủ chi tiết.

Quy trình tổng quát gồm ba việc: (1) chọn và mô tả rõ feature, (2) tự đánh giá story trước khi giao cho AI, và (3) chạy một prompt "master" đủ mạnh để sinh ra bản strategy đầu tiên. Ba phần dưới đây sẽ đi qua từng việc một cách cụ thể.

Feature Thực Hành: User Account Subscription Management

Để bài học có tính thực hành cao, chúng ta dùng xuyên suốt một feature giả định nhưng rất gần với thực tế: hệ thống quản lý gói đăng ký (subscription) của một sản phẩm SaaS B2C, cho phép user tự nâng cấp (upgrade), hạ cấp (downgrade), hoặc hủy (cancel) gói dịch vụ.

User story:

Là một registered user, tôi muốn xem, thay đổi (upgrade/downgrade) hoặc hủy gói subscription hiện tại của mình (Free, Pro, Enterprise), để tôi có thể kiểm soát chi phí và quyền truy cập tính năng theo đúng nhu cầu sử dụng thực tế.

Acceptance Criteria (AC) — tiêu chí chấp nhận đi kèm story:

1. User xem được: plan hiện tại, ngày bắt đầu billing cycle (chu kỳ thanh toán), ngày renew tiếp theo, usage hiện tại so với hạn mức của plan.
2. Upgrade có hiệu lực ngay lập tức, hệ thống tính phí proration (tính tiền theo tỷ lệ thời gian còn lại của cycle) và charge qua payment gateway (Stripe).
3. Downgrade có hiệu lực vào cuối billing cycle hiện tại — user vẫn giữ quyền lợi của plan cũ đến hết cycle đã trả tiền.
4. Cancel giữ access đến hết billing cycle đã thanh toán (grace period), sau đó tài khoản chuyển về Free tier tự động.
5. Nếu payment method bị decline khi upgrade, hệ thống giữ nguyên plan hiện tại, hiển thị lỗi rõ ràng, không charge trùng.
6. Mọi thay đổi subscription đều gửi email/notification xác nhận cho user.
7. Admin/CS (customer support) có quyền override trạng thái subscription qua công cụ nội bộ (ví dụ: gia hạn miễn phí, hoàn tiền, chuyển plan thủ công).
8. Hệ thống nhận và xử lý webhook từ Stripe (payment_succeeded, payment_failed, subscription.updated...) để đồng bộ trạng thái.

Feature này có đặc điểm rất tiêu biểu cho các hệ thống subscription thực tế: có state machine (máy trạng thái) rõ ràng, có tích hợp bên thứ ba (payment gateway), có yếu tố thời gian (billing cycle, proration, grace period), và có tác động tài chính trực tiếp — đây chính là mảnh đất màu mỡ để luyện risk assessment và coverage goal bằng AI.

Mẹo: Khi chọn feature để luyện tập với AI, ưu tiên feature có ít nhất 2 trong 3 đặc điểm: có state machine, có tích hợp bên thứ ba, hoặc có tác động tài chính/pháp lý. Đây là những feature mà test strategy hời hợt sẽ gây thiệt hại thật, nên luyện tập trên chúng giúp bạn xây phản xạ đúng ngay từ đầu, thay vì chỉ luyện trên các feature CRUD đơn giản.

Bước 1: Đánh Giá Story Ban Đầu

Trước khi mở bất kỳ cửa sổ chat AI nào, QA senior luôn dừng lại vài phút để tự đọc và đánh giá story. Đây là bước dễ bị bỏ qua nhất khi mọi người quá hào hứng "giao việc cho AI ngay", nhưng lại là bước quyết định chất lượng output — vì AI chỉ tốt bằng chất lượng context bạn cung cấp (nguyên lý garbage in, garbage out vẫn đúng 100% với LLM).

Khi tự đánh giá story, hãy trả lời nhanh các câu hỏi sau và ghi lại thành một "story assessment note" ngắn:

• Actor nào tham gia? Registered user, Stripe (hệ thống bên ngoài), Admin/CS, hệ thống job nội bộ (cron xử lý renew).
• Trigger nào kích hoạt luồng? User bấm nút trên UI, webhook từ Stripe, cron job chạy theo lịch, action từ admin panel.
• Có state nào ẩn không được nêu rõ trong AC? Ví dụ: trạng thái "pending downgrade" (đã yêu cầu downgrade nhưng chưa đến cuối cycle) — AC không nói rõ user có thể hủy yêu cầu downgrade này không.
• Điểm mơ hồ (ambiguity) nào cần làm rõ với Product/Dev trước? Ví dụ: nếu user downgrade rồi lại upgrade trong cùng cycle, tính phí thế nào? AC chưa trả lời.
• Có phụ thuộc dữ liệu lịch sử nào không? Ví dụ: user đã từng cancel và tái đăng ký, dữ liệu billing history có bị ảnh hưởng không.

Với feature subscription của chúng ta, sau khi tự đánh giá, note của một QA senior có thể như sau:

STORY ASSESSMENT NOTE — User Account Subscription Management

Actors: End user (web + mobile app), Stripe webhook, Admin/CS tool, nightly renewal cron job.

Ambiguities to raise with PO before finalizing strategy:
1. Upgrade rồi downgrade trong cùng cycle — quy tắc tính tiền là gì? (chưa có trong AC)
2. "Pending downgrade" có thể bị hủy bởi user trước khi cycle kết thúc không?
3. Webhook trễ hoặc mất (Stripe retry) — hệ thống có idempotency handling không?
4. Múi giờ nào được dùng để tính "cuối billing cycle"? Theo user hay theo server?

Hidden states suspected: Active, PendingDowngrade, PendingCancellation,
GracePeriod, Suspended (do payment fail), Expired.

Integration risk: Stripe webhook là single point of truth cho payment status,
nhưng app cũng có local DB state — nguy cơ lệch dữ liệu (data drift) là rất cao.

Ghi chú này không cần hoàn hảo hay đầy đủ — mục đích là để bạn mang theo hiểu biết chủ động vào phiên làm việc với AI, tránh tình trạng AI trả lời rất "đẹp" nhưng bạn không biết nó đã bỏ sót điều gì vì bản thân bạn cũng chưa từng nghĩ tới.

Master Prompt Để Sinh Test Strategy

Đây là phần quan trọng nhất của bài học: một prompt "master" — đủ dài, đủ chi tiết, có persona, có context, có yêu cầu output rõ ràng — để AI sinh ra bản test strategy đầu tiên cho feature subscription. Prompt càng có cấu trúc, output càng nhất quán và ít cần sửa lại.

You are a Senior QA Architect with 10+ years of experience testing
subscription-based SaaS products, payment integrations, and financial
workflows. You have deep expertise in risk-based testing, state machine
testing, and third-party integration testing (especially payment gateways
like Stripe).

## CONTEXT

I need a complete test strategy for the following feature.

Feature name: User Account Subscription Management
Product type: B2C SaaS web app + companion mobile app (iOS/Android),
shared backend API.
Payment provider: Stripe (Subscriptions + Webhooks API).

User story:
"As a registered user, I want to view, upgrade/downgrade, or cancel my
current subscription plan (Free, Pro, Enterprise), so that I can control
my cost and feature access based on my actual needs."

Acceptance Criteria:
1. User can view current plan, billing cycle start date, next renewal date,
   and current usage vs plan limits.
2. Upgrade takes effect immediately; system charges prorated amount via
   Stripe.
3. Downgrade takes effect at the end of the current billing cycle; user
   retains current plan benefits until then.
4. Cancellation keeps access until the end of the paid billing cycle
   (grace period), then auto-reverts to Free tier.
5. If payment method is declined during upgrade, the current plan is
   preserved, a clear error is shown, and no duplicate charge occurs.
6. Every subscription change triggers a confirmation email/notification.
7. Admin/CS can override subscription state via an internal tool (extend
   trial, refund, manual plan change).
8. System consumes Stripe webhooks (payment_succeeded, payment_failed,
   customer.subscription.updated) to sync internal state.

Known open questions I have NOT resolved yet with Product:
- Pricing/proration rule when a user upgrades then downgrades within the
  same cycle.
- Whether a "pending downgrade" can be cancelled by the user before it
  takes effect.
- Timezone used to determine "end of billing cycle".
- Idempotency handling for delayed/duplicate Stripe webhooks.

Regression context: this feature touches an existing billing module with
~40 automated API tests and no existing E2E coverage for subscription
changes. The team ships weekly; this feature is targeted for the next
release in 3 weeks.

## TASK

Generate a complete initial test strategy document for this feature. It
must include the following sections, in this order:

1. **Scope** — what is explicitly in scope and out of scope for this
   testing effort.
2. **Risk Assessment** — a table of risk items, each with: risk
   description, likelihood (High/Medium/Low), impact (High/Medium/Low),
   risk score, and rationale.
3. **Coverage Goals** — testable objectives derived from the AC and the
   risk assessment, phrased as "we must verify that...".
4. **Test Level Mapping** — for each coverage goal, recommend the most
   appropriate test level(s): Unit, API/Integration, E2E/UI, Manual
   Exploratory — with justification.
5. **Open Questions for Product/Dev** — list ambiguities that must be
   resolved before test case authoring begins.
6. **Assumptions** — anything you assumed due to missing information.

## OUTPUT FORMAT

Use Markdown with clear headings matching the 6 sections above. Use tables
for Risk Assessment and Test Level Mapping. Be specific to THIS feature —
do not give generic subscription-testing advice that could apply to any
SaaS product. Flag with "⚠️" any AC that you find ambiguous or
underspecified based on the context I gave you.

Khi chạy prompt này, bạn sẽ nhận về một bản strategy nháp khá đầy đủ — nhưng đừng dừng lại ở đây. Đây chỉ là điểm khởi đầu, không phải bản final. Phần tiếp theo sẽ hướng dẫn bạn đào sâu từng phần trong cùng một phiên chat, tận dụng context đã có sẵn (LLM nhớ toàn bộ cuộc hội thoại trong context window — giới hạn dữ liệu mà mô hình có thể "nhìn thấy" trong một lượt xử lý).

Mẹo: Luôn nhúng nguyên văn user story và AC vào prompt, đừng chỉ mô tả bằng lời của bạn hoặc paste link Jira. AI không tự truy cập được Jira của bạn, và nếu bạn diễn giải lại AC bằng ý riêng, bạn có thể vô tình bỏ sót đúng chi tiết mà AI cần để phát hiện rủi ro (ví dụ chi tiết "proration" ở AC #2 chính là nguồn gốc của rất nhiều rủi ro tính tiền sai).

Làm Sao Tạo Risk Assessment, Coverage Goal Và Test Level Mapping Trong Một Phiên Chat?

Bản strategy nháp từ prompt master thường đủ tốt để mở đầu, nhưng risk assessment ban đầu hay bị nông — AI có xu hướng liệt kê rủi ro hiển nhiên (payment fail, wrong amount charged) mà bỏ qua rủi ro tinh vi hơn (race condition giữa hai webhook, lệch timezone). Kỹ thuật ở đây là không hỏi lại từ đầu, mà đào sâu ngay trong phiên chat đang có, để AI tận dụng context đã xây dựng.

Đào Sâu Risk Assessment

Sau khi có bảng risk assessment đầu tiên, hãy yêu cầu AI tự phản biện chính nó bằng một prompt truy vấn theo từng góc nhìn chuyên biệt:

Review the risk assessment table you just generated. I want you to find
GAPS by analyzing the feature from three additional angles that are
commonly missed in subscription systems:

1. **Concurrency & race conditions**: What can go wrong if two state-
   changing events happen close together (e.g., user clicks "cancel" at
   the same moment a Stripe renewal webhook arrives; user upgrades twice
   in quick succession from two browser tabs)?

2. **Data consistency between systems**: Where can our internal DB state
   and Stripe's state disagree, and what user-visible symptoms would that
   cause?

3. **Financial correctness edge cases**: Beyond "wrong amount charged",
   what subtler billing bugs are possible (double proration, negative
   balance, rounding errors across currencies, refund/charge ordering)?

For each new risk you find, add a row to the risk table using the same
format (description, likelihood, impact, risk score, rationale). Mark
these new rows with "[NEW]" so I can distinguish them from the first pass.

Kỹ thuật "buộc AI soi theo góc nhìn cụ thể" (concurrency, data consistency, financial correctness) hiệu quả hơn nhiều so với việc chỉ nói "hãy bổ sung thêm rủi ro". Vì mô hình LLM có xu hướng generic hóa nếu không được ép tập trung vào một chiều phân tích cụ thể.

Mở Rộng Coverage Goal Với Boundary Analysis

Coverage goal ban đầu thường phát biểu ở mức khá cao ("verify that upgrade charges the correct prorated amount"). Để coverage thực sự actionable cho test case sau này, bạn cần ép AI đi xuống mức boundary (giá trị biên) cụ thể:

For each coverage goal related to billing dates, proration, and usage
limits, apply boundary value analysis. For every relevant variable, list
the specific boundary values I should test at, one level below, and one
level above the boundary. Focus especially on:

- Billing cycle boundary (last second of cycle vs first second of new
  cycle, across different timezones).
- Proration calculation at day 1, mid-cycle, and last day of a 30-day and
  a 31-day cycle.
- Usage limits: exactly at limit, one unit over limit, one unit under
  limit, for each plan tier.
- Grace period expiry: last second of grace period, first second after
  expiry.

Present the result as a table: Variable | Boundary Scenario | Expected
Behavior | Why This Boundary Matters.

Kết quả bạn nhận được thường sẽ lộ ra những case rất dễ bị bỏ sót khi viết coverage goal bằng tay, ví dụ: "billing cycle 31 ngày nhưng logic proration hard-code chia cho 30" — một lỗi kinh điển trong hệ thống billing.

Tạo Bảng Test Level Mapping

Sau khi có coverage goal chi tiết đến mức boundary, bước tiếp theo là map từng goal vào đúng test level, để team phân bổ effort hợp lý (không phải cái gì cũng nên là E2E test chạy chậm và tốn kém duy trì).

Now map every coverage goal (including the boundary scenarios) to the
most appropriate test level(s). Use this exact table format:

| Coverage Goal / Boundary Scenario | Unit | API/Integration | E2E/UI | Manual Exploratory | Primary Owner |

Mark each applicable cell with an "X". A goal can map to more than one
level if justified. In a short note under the table, explain your
reasoning for any case where you chose E2E/UI over API/Integration —
I want to keep E2E test count as low as possible given our 3-week
timeline, so justify every E2E recommendation.

Bảng kết quả điển hình sẽ trông như sau (rút gọn để minh họa):

Việc ép AI giải thích lý do chọn E2E ("justify every E2E recommendation") rất quan trọng — nó buộc AI tự kiểm soát chi phí test suite, đúng với tinh thần test pyramid (kim tự tháp kiểm thử — ưu tiên test rẻ, nhanh ở lớp dưới) mà đội QA senior nào cũng cần.

Refine Lặp Lại: Dò Tìm Những Gì AI Bỏ Sót

Ngay cả sau hai lượt đào sâu trên, vẫn nên có một lượt "truy vấn ngược" cuối cùng, hỏi thẳng AI về giới hạn của chính nó:

Before we finalize this strategy, act as a skeptical reviewer of your own
output. Answer honestly:

1. What test level or risk category did you likely under-cover because
   you don't have visibility into our actual codebase, infra, or Stripe
   account configuration?
2. Are there any coverage goals that assume a system behavior which might
   not match how OUR system is actually implemented? List them explicitly
   as assumptions to verify with the dev team.
3. Given the open questions I listed at the start (proration rule on
   upgrade-then-downgrade, pending downgrade cancellation, timezone,
   webhook idempotency), which parts of the current strategy would most
   likely need to change once those questions are answered?

Câu trả lời từ bước này thường chính là danh sách "rủi ro của việc dùng AI" — những chỗ AI đang suy diễn dựa trên giả định chung của ngành subscription SaaS, chứ không dựa trên hệ thống thật của bạn. Đây là lý do bước review của con người ở phần tiếp theo không thể bỏ qua.

Mẹo: Luôn giữ nguyên một phiên chat (session) duy nhất từ prompt master đến hết vòng refinement, đừng mở chat mới cho mỗi bước. AI cần toàn bộ lịch sử hội thoại làm context để không lặp lại rủi ro đã liệt kê hoặc mâu thuẫn với bảng trước đó. Nếu context window quá dài và AI bắt đầu "quên" phần đầu, hãy dán lại bản risk table + coverage goal hiện tại vào đầu prompt tiếp theo thay vì tin rằng AI còn nhớ chính xác.

Làm Sao Review Và Refine Test Strategy Do AI Tạo Để Team Sign-Off?

Một bản strategy do AI sinh ra, dù đã qua nhiều vòng đào sâu, vẫn chỉ là bản đề xuất, không phải bản chính thức. Sign-off (sự phê duyệt chính thức, thường từ QA Lead, Tech Lead, và đôi khi Product Owner) chỉ nên xảy ra sau khi con người đã review có chủ đích, không phải "đọc lướt rồi gật đầu vì AI viết nghe rất chuyên nghiệp".

Checklist Self-Review

Trước khi mang strategy ra họp team, tự chạy qua một checklist review cá nhân. Đây là danh sách tối thiểu nên có:

• [ ] Traceability: Mọi AC đều có ít nhất một coverage goal tương ứng? Không có AC nào bị "rớt" khỏi bảng.
• [ ] Không hallucination (bịa đặt): Mọi rủi ro/coverage goal có nhắc đến hành vi hệ thống — bạn đã xác nhận hành vi đó đúng với hệ thống thật, không phải AI tự suy diễn từ "subscription system nói chung"?
• [ ] Tính khả thi: Với 3 tuần và team hiện có, số lượng test case đề xuất có thực tế không, hay đang đề xuất một khối lượng không tưởng?
• [ ] Không trùng lặp: Có coverage goal nào lặp lại ý nghĩa của goal khác dưới tên khác không?
• [ ] Ưu tiên hợp lý: Risk score cao có tương ứng với effort/test level phù hợp không (rủi ro cao mà chỉ có manual exploratory là dấu hiệu cảnh báo)?
• [ ] Open question đã đủ rõ để đưa cho PO/Dev trả lời — không mơ hồ, không cần PO phải đọc lại toàn bộ document mới hiểu câu hỏi.
• [ ] Ngôn ngữ, format đồng nhất với chuẩn tài liệu QA của team (naming convention, mức độ chi tiết).

Nếu checklist này phát hiện lỗ hổng — ví dụ AC #7 (admin override) chưa có coverage goal nào nhắc tới — đây chính là lúc quay lại phiên chat với AI và yêu cầu bổ sung có mục tiêu, thay vì tự viết tay từ đầu.

Chuẩn Bị Strategy Cho Buổi Review Của Team

Một bản strategy "raw" từ AI, dù đúng nội dung, thường không có cấu trúc tối ưu cho một buổi họp 30-45 phút. Trước khi gửi cho team, hãy tinh chỉnh thành bản review-ready:

1. Executive summary 5-7 dòng ở đầu: feature là gì, rủi ro lớn nhất là gì, effort ước tính, điều gì cần team quyết định trong buổi họp.
2. Đánh dấu rõ phần nào "chắc chắn" và phần nào "đang mở" — dùng ký hiệu nhất quán (ví dụ ✅ Confirmed / ⚠️ Needs Decision / ❓ Blocked on Product).
3. Danh sách quyết định cần chốt đặt riêng thành một mục ngay sau executive summary, không chôn giữa document — vì đây là phần team sẽ dành thời gian thảo luận nhiều nhất.
4. Loại bỏ jargon dư thừa mà AI có thể đã thêm vào (một số model có xu hướng viết dài dòng, lặp ý để "nghe đầy đủ hơn").

Mẹo: Dùng chính AI để rút gọn bước này — sau khi bạn đã chỉnh sửa nội dung, hỏi thêm: "Rewrite the Executive Summary section in 5-7 concise sentences suitable for a 30-minute review meeting with QA Lead, Tech Lead, and Product Owner who have NOT read the full document." Đây là cách tận dụng AI ở vai trò biên tập, sau khi con người đã chốt nội dung chuyên môn.

Dẫn Dắt Buổi Họp Review Strategy

Buổi họp review nên có agenda rõ ràng, không phải "đọc document từ trên xuống dưới":

Vai trò QA trong buổi họp này là người dẫn dắt (facilitator), không phải người thuyết trình. Với feature subscription, các câu hỏi mở đã liệt kê ở phần trước (quy tắc tính tiền khi upgrade-rồi-downgrade, timezone, idempotency webhook) chính là nội dung trọng tâm — Tech Lead và Product Owner cần chốt câu trả lời ngay trong buổi họp này để test case authoring không bị block sau đó.

Xử Lý Feedback Và Cập Nhật Strategy

Sau buổi họp, feedback thường rơi vào ba loại: (1) chốt câu trả lời cho open question, (2) yêu cầu thêm rủi ro/coverage mà team nghĩ ra trong lúc thảo luận, (3) yêu cầu giảm scope vì effort không thực tế. Xử lý hiệu quả nhất là đưa feedback trở lại đúng phiên chat AI đã dùng, thay vì tự sửa tay từng dòng:

The strategy review meeting produced the following decisions. Update the
test strategy document accordingly:

DECISIONS:
1. Proration rule confirmed: if a user upgrades then downgrades within
   the same cycle, the system charges the upgrade proration immediately
   and does NOT refund any amount on downgrade (downgrade only affects
   future cycles). Update the risk assessment and coverage goals for this
   scenario accordingly — remove any coverage goal that assumed a refund
   would occur.
2. Pending downgrade CAN be cancelled by the user before it takes effect.
   Add this as a new coverage goal with API and E2E mapping.
3. All billing cycle boundaries use UTC, not user local time. Update the
   boundary analysis table to remove timezone-conversion test cases and
   replace with UTC-only boundary cases.
4. Scope reduced: Admin/CS override testing will be Manual Exploratory
   only for this release, NOT automated. Update the Test Level Mapping
   table and note the automation deferral with a target release.

Output the fully updated document, and add a short "Changelog" section at
the end listing what changed and why, dated [DATE].

Yêu cầu AI xuất "Changelog" mỗi lần cập nhật giúp bạn giữ được lịch sử quyết định — rất hữu ích khi 2 tháng sau có người hỏi "tại sao lúc đó mình quyết định không test timezone conversion?"

Mẹo: Không bao giờ để AI tự quyết định câu trả lời cho open question thay team. Nếu bạn thấy mình đang viết prompt kiểu "AI nghĩ nên chọn phương án nào?" cho một quyết định có tác động business/tài chính, đó là dấu hiệu bạn đang lạm dụng AI để tránh trách nhiệm ra quyết định — hãy đưa câu hỏi đó lại cho người có thẩm quyền.

Làm Sao Lưu Test Strategy Thành Template Tái Sử Dụng?

Bản strategy hoàn chỉnh cho feature subscription management không nên "dùng một lần rồi bỏ". Nếu công ty bạn còn build thêm feature liên quan đến billing, state machine, hoặc tích hợp thanh toán khác (ví dụ: gift card, referral credit, invoice cho enterprise khách hàng), phần lớn cấu trúc phân tích rủi ro có thể tái sử dụng. Đây là lúc chuyển từ "một document" thành "một template".

Điều Gì Tạo Nên Một Strategy Template Tốt?

Một template tốt không phải là bản strategy cụ thể với tên biến đổi thành placeholder một cách máy móc. Nó cần tách được hai lớp: phần cấu trúc/chuyên môn tái sử dụng được và phần nội dung đặc thù của feature. Ví dụ với template "Payment/Subscription Feature", phần tái sử dụng gồm:

• Danh mục rủi ro chuẩn cho feature tài chính (double charge, refund/charge ordering, currency rounding, webhook idempotency, state drift giữa hệ thống nội bộ và bên thứ ba).
• Bộ câu hỏi mở nên luôn được hỏi Product trước khi bắt đầu (quy tắc proration, timezone chuẩn, chính sách grace period).
• Khung boundary analysis chuẩn cho biến thời gian (cycle boundary, expiry boundary).
• Test level mapping mẫu, phản ánh nguyên tắc test pyramid mà team đã đồng thuận.

Phần đặc thù (tên feature, AC cụ thể, số liệu plan/pricing) chính là phần bạn điền lại mỗi lần dùng template.

Trích Xuất Template Từ Một Strategy Đã Hoàn Thành

Sau khi strategy subscription đã sign-off, dùng AI để "trừu tượng hóa" nó thành template — đây là bước nhiều người bỏ qua vì nghĩ phải tự làm tay:

I have a completed, team-approved test strategy for a subscription
billing feature (pasted below). I want you to extract a REUSABLE TEMPLATE
from it, generalized for any "payment or financial state-machine" feature
(e.g., gift cards, invoicing, referral credits) — not just subscriptions.

Rules:
- Replace feature-specific details (plan names, specific AC numbers,
  specific dollar amounts) with clearly marked placeholders like
  [FEATURE_NAME], [STATE_LIST], [PAYMENT_PROVIDER].
- KEEP the general risk categories, the boundary analysis framework, and
  the standard open-questions checklist — these are the reusable value.
- Add a short "How to Use This Template" instruction block at the top,
  explaining what information the QA needs to gather before filling it
  in (equivalent to my "Story Assessment Note" step).
- Output as a Markdown template ready to be copy-pasted into a new
  document.

[PASTE FULL STRATEGY DOCUMENT HERE]

Kết quả là một file template .md có thể lưu vào thư mục dùng chung của team, với các placeholder rõ ràng và một hướng dẫn sử dụng ngắn ở đầu.

Xây Dựng Thư Viện Strategy Template

Một template không đủ — theo thời gian, team nên xây một thư viện template phân loại theo dạng feature, vì rủi ro của mỗi dạng feature khác nhau đáng kể. Gợi ý cách tổ chức:

/qa-templates/
  strategy/
    payment-financial-feature.template.md
    state-machine-feature.template.md       (workflow nhiều trạng thái, không liên quan tiền)
    third-party-integration-feature.template.md
    notification-messaging-feature.template.md
    data-migration-feature.template.md
  README.md   (bảng: loại feature -> template nên dùng -> ví dụ đã áp dụng)

Feature subscription của chúng ta thực chất giao giữa hai loại: payment-financial-feature và state-machine-feature — trong README nên ghi rõ điều này, và gợi ý khi nào dùng kết hợp cả hai template (kế thừa risk category từ cả hai, loại bỏ phần trùng lặp).

Mẹo: Đừng tạo template mới cho mỗi feature một chút khác biệt. Chỉ tách template mới khi loại rủi ro thật sự khác biệt về bản chất (ví dụ: feature liên quan compliance/dữ liệu cá nhân nên có template riêng vì cần thêm hạng mục rủi ro pháp lý — không nên nhồi vào template payment).

Versioning Và Duy Trì Template Theo Thời Gian

Template không phải tài liệu tĩnh. Sau mỗi lần dùng thực tế, thường sẽ phát hiện thiếu sót — ví dụ sau feature subscription, team nhận ra template payment thiếu hẳn hạng mục rủi ro "webhook retry gây duplicate event", nên cần bổ sung ngay vào template gốc để feature sau không lặp lại lỗ hổng này.

Áp dụng versioning đơn giản kiểu semantic (v1.0, v1.1...) và giữ changelog ngay trong file template:

<!-- CHANGELOG
v1.2 (2026-07-09) — Added "webhook idempotency/duplicate event" risk
  category after subscription-management project uncovered a real gap.
v1.1 (2026-05-14) — Added boundary analysis section for billing cycle
  edge cases.
v1.0 (2026-03-02) — Initial template extracted from invoicing project.
-->

Nguyên tắc: mỗi khi một strategy review phát hiện template gốc thiếu gì đó, cập nhật template ngay trong tuần đó, đừng để việc này trôi vào danh sách "để sau". Template chỉ có giá trị nếu nó phản ánh bài học thật, cập nhật liên tục — nếu không nó sẽ nhanh chóng lạc hậu và bị team bỏ qua.

Chia Sẻ Template Trong Toàn Team QA

Template hữu ích nhất khi được dùng thống nhất toàn team, không phải chỉ nằm trong máy cá nhân. Vài nguyên tắc chia sẻ hiệu quả:

• Lưu trong repo Git hoặc Confluence/Notion có version history — không dùng Google Docs cho phần nội dung dễ đổi nhanh (vì khó track thay đổi theo thời gian bằng git diff).
• Mỗi khi thêm template mới hoặc cập nhật lớn, thông báo ngắn trong QA sync/standup — không im lặng cập nhật rồi hy vọng người khác tự tìm thấy.
• Đưa việc "áp dụng template" thành checklist trong quy trình bắt đầu một feature mới (ví dụ: mục trong Definition of Ready của QA), để việc dùng template trở thành mặc định, không phải tùy chọn.
• Định kỳ (mỗi quarter) review lại toàn bộ thư viện template cùng team — hỏi "template nào ít được dùng? Vì sao?" — template không ai dùng thường là dấu hiệu nó quá phức tạp hoặc không còn khớp với cách team làm việc thực tế.

Mẹo: Khi onboard QA mới, đừng chỉ đưa link thư viện template và để họ tự đọc. Cho họ chạy thử ngay một feature thật (hoặc một feature giả lập như subscription management trong bài này) bằng chính template, dưới sự quan sát của QA senior — cách học nhanh nhất với loại tài liệu "quy trình + AI prompt" luôn là thực hành có người kèm, không phải đọc lý thuyết.