Tiếng Việt: Documenting and synthesizing exploratory findings

Một session exploratory testing (kiểm thử khám phá) tốt có thể tạo ra rất nhiều insight — nhưng nếu insight đó chỉ nằm trong đầu bạn hoặc trong một file note lộn xộn, giá trị của nó sẽ mất dần theo thời gian. Tôi từng chứng kiến không ít QA senior làm exploratory testing rất giỏi, tìm ra bug quan trọng, nhưng report lại yếu đến mức dev đọc xong không hiểu bug xảy ra thế nào, hoặc PM không thấy được mức độ nghiêm trọng. Kết quả: bug bị deprioritize, hoặc phải mất thêm một vòng hỏi-đáp mới tái hiện được.

Đây chính là lỗ hổng mà AI giải quyết rất tốt: không phải giúp bạn "test giỏi hơn", mà giúp bạn biến raw notes (ghi chú thô) trong lúc test thành structured findings (phát hiện có cấu trúc) — bug report rõ ràng, test case tái sử dụng được, và bức tranh coverage cập nhật theo thời gian thực. Trong bài này, chúng ta sẽ đi từ việc ghi note đúng cách, dùng AI để synthesize (tổng hợp) note thành findings, phát hiện pattern (mẫu hình lỗi) qua nhiều session, và cuối cùng là chuyển hoá toàn bộ thành tài sản test có thể dùng lại: bug report, test case, coverage tracking.

Chiến Lược Ghi Note Nào Phù Hợp Nhất Để AI Tổng Hợp?

Nếu bạn muốn AI tổng hợp note thành findings chất lượng, thì "garbage in, garbage out" áp dụng chính xác. AI không thể bù đắp cho note thiếu context — nó chỉ có thể tổ chức lại những gì bạn đã ghi. Vì vậy phần quan trọng nhất không phải là prompt, mà là thói quen ghi note trong lúc explore.

"Loại Note Đúng" Nghĩa Là Gì

Có ba loại thông tin bạn cần ghi lại trong một session exploratory, và hầu hết tester chỉ ghi loại đầu tiên:

1. Hành động (action) — bạn đã làm gì, theo thứ tự nào. Ví dụ: "Mở trang checkout → chọn voucher 50% → thêm sản phẩm thứ 2 vào cart → áp lại voucher".
2. Quan sát (observation) — hệ thống phản hồi thế nào, bao gồm cả những thứ "hơi lạ" nhưng chưa chắc là bug. Ví dụ: "Giá hiển thị nhảy số trong khoảng 300ms trước khi ổn định — có thể là do re-render, cần theo dõi thêm".
3. Giả thuyết & câu hỏi (hypothesis/question) — điều bạn nghĩ đang xảy ra bên dưới, hoặc điều bạn còn nghi ngờ. Ví dụ: "Nghi là voucher amount đang tính trên subtotal cũ (cache) chứ không phải subtotal mới sau khi thêm item".

Loại thứ 2 và thứ 3 chính là thứ hầu hết tester bỏ qua vì họ nghĩ "chưa chắc là bug thì không cần ghi". Nhưng đây lại là dữ liệu quý nhất để AI tìm pattern, vì rất nhiều bug nghiêm trọng bắt nguồn từ một quan sát "hơi lạ" mà ban đầu người ghi cũng không chắc.

Mẹo: Tập thói quen ghi note theo cấu trúc 3 phần "Do → See → Think" cho mọi hành động đáng chú ý, ngay cả khi bạn chưa chắc nó có phải bug hay không. Một note "Think: nghi ngờ X" ghi tại thời điểm test có giá trị synthesis cao hơn nhiều so với việc bạn nhớ lại nó sau này.

Format Ghi Note Hiệu Quả Nhất

Qua nhiều lần thử với các mô hình LLM khác nhau, tôi thấy format hiệu quả nhất khi đưa vào AI synthesis không phải là văn xuôi tự do (free-form prose) mà là timestamped, semi-structured bullet log — mỗi dòng có thời điểm, hành động ngắn, và nhãn (tag) phân loại. Ví dụ:

[10:02] ACTION: Login với account free-tier, vào trang Billing
[10:03] OBS: Nút "Upgrade" hiển thị disabled, không có tooltip giải thích lý do
[10:03] Q: Disabled do quyền, hay do bug load state chậm? Reload thử.
[10:04] ACTION: Reload trang Billing
[10:04] OBS: Nút "Upgrade" giờ enable được — vậy là do race condition lúc load, không phải business rule
[10:06] ACTION: Click Upgrade -> chọn plan Pro -> Submit
[10:07] OBS: Redirect về trang Billing cũ, KHÔNG có confirmation nào, nhưng invoice đã được tạo (check qua admin)
[10:07] SEVERITY-GUESS: Cao - user sẽ tưởng thao tác fail và bấm lại nhiều lần

Format này có ba lợi ích khi đưa vào AI:

• Timestamp giúp AI hiểu thứ tự nhân quả — cái gì xảy ra trước, cái gì là hệ quả.
• Tag (ACTION/OBS/Q/SEVERITY-GUESS) giúp AI phân loại nhanh mà không cần đoán ý bạn.
• Ngắn gọn, không cần viết câu hoàn chỉnh trong lúc test — vì lúc đang explore, bạn cần tốc độ, không cần văn phong.

Bạn không cần công cụ đặc biệt để ghi theo format này — một file .md hoặc .txt mở song song màn hình là đủ. Điều quan trọng là tính nhất quán của tag, để khi feed vào AI, nó nhận diện được cấu trúc.

Công Cụ Ghi Note Tích Hợp Tốt Với AI Synthesis

Một số lựa chọn thực tế mà team QA ở Việt Nam đang dùng, xếp theo mức độ tích hợp AI:

Với AI agent hiện đại (có thể đọc file, đọc log), tôi khuyên dùng plain Markdown hoặc Notion export — vì bạn có thể đưa trực tiếp vào context window (bộ nhớ ngữ cảnh) của AI mà không cần convert format. Nếu bạn dùng voice-to-text, hãy transcribe ngay sau session (đừng để qua ngày), vì AI synthesis phụ thuộc rất nhiều vào việc note còn "tươi" — chi tiết nhỏ dễ mất khi bạn tự diễn giải lại bằng trí nhớ.

Những Gì Cần Ghi Lại Mà Hầu Hết Tester Bỏ Qua

Ba loại thông tin sau đây gần như không bao giờ được ghi lại, nhưng lại là "vàng" khi synthesize:

• Trạng thái môi trường (environment state): bạn đang test trên data nào, account nào, feature flag nào đang on/off, thời điểm test (gần đầu tháng, cuối tháng — với hệ thống có billing cycle thì điều này quan trọng). Thiếu thông tin này, AI (và cả bạn sau này) không thể phân biệt "bug thật" với "chỉ xảy ra vì data đặc biệt".
• Đường đi KHÔNG dẫn đến bug (negative path): bạn đã thử điều gì mà không có vấn đề gì xảy ra. Nghe có vẻ dư thừa, nhưng khi tổng hợp coverage, đây là bằng chứng cho biết khu vực nào đã được test kỹ mà không cần test lại.
• Cảm giác "chậm" hoặc "khó dùng" không phải bug chức năng — ví dụ "Loading spinner xoay hơn 4 giây cho một action tưởng như đơn giản". Đây không phải bug functional nhưng là dữ liệu UX quý giá mà AI có thể gom lại thành một nhóm finding riêng về performance/UX.

Dùng AI Biến Note Thô Thành Finding Có Cấu Trúc Như Thế Nào?

Sau khi có note tốt, bước kế tiếp là dùng AI để "dịch" từ ngôn ngữ log rời rạc sang finding có cấu trúc: mô tả, mức độ nghiêm trọng, bước tái hiện, gợi ý nguyên nhân. Đây là bước mà AI tạo giá trị rõ nhất — vì việc viết lại report chuẩn chỉnh thường tốn 30-40% thời gian của một session exploratory truyền thống, và AI có thể rút xuống còn vài phút review.

Prompt Tổng Hợp Cốt Lõi

Đây là prompt "khung" tôi dùng cho hầu hết session, đủ chi tiết để AI hiểu được cấu trúc note và tự phân loại đúng:

You are a senior QA engineer helping synthesize raw exploratory testing notes
into structured findings.

CONTEXT:
- Product: [tên feature/module đang test, ví dụ "Checkout flow - Billing page"]
- Session goal: [mục tiêu ban đầu của session, ví dụ "Explore upgrade flow for edge cases around race conditions and error states"]
- Environment: [môi trường test, ví dụ "Staging, free-tier test account, feature flag new_billing_ui=true"]

RAW NOTES (timestamped, tags: ACTION / OBS / Q / SEVERITY-GUESS):
[paste toàn bộ raw notes ở đây]

TASK:
1. Group the notes into distinct "findings" — each finding is one potential
   issue, anomaly, or noteworthy observation. Do NOT merge unrelated
   observations into one finding just because they happened close in time.
2. For each finding, output:
   - Title: one-line summary, specific enough to search for later
   - Category: Bug / UX concern / Performance concern / Needs more investigation / Confirmed non-issue
   - Severity guess: Critical / High / Medium / Low, with one-sentence justification
   - Reproduction steps: numbered, based strictly on the ACTION lines — do not invent steps not present in the notes
   - Observed behavior: based on OBS lines
   - Suspected root cause: based on Q lines, clearly marked as a hypothesis, not fact
   - Confidence level: How confident are you this is a real, reproducible issue based on the notes alone (Low/Medium/High), and what additional verification would raise that confidence
3. Flag any note lines that don't fit cleanly into a finding, and ask me for
   clarification instead of guessing.
4. Do not soften or downplay severity to sound polite — call out anything
   that looks like a blocker even if the notes are ambiguous.

Output as a Markdown list of findings.

Ba yếu tố trong prompt này đáng chú ý:

• Yêu cầu tách finding riêng biệt thay vì gộp chung — vì AI có xu hướng gộp các quan sát gần nhau về thời gian thành một câu chuyện, dù chúng không liên quan.
• Yêu cầu "confidence level" — bắt AI tự đánh giá độ tin cậy của finding dựa trên note, không phải "diễn" ra một finding nghe hợp lý. Đây là cách chống lại hallucination (AI tự bịa thêm chi tiết không có trong note).
• Yêu cầu flag note không rõ nghĩa thay vì để AI tự đoán — vì note viết vội trong lúc test chắc chắn có chỗ mơ hồ, và bạn — người đã trải qua session — mới là người trả lời đúng, không phải AI.

Mẹo: Luôn để AI liệt kê "note nào bị bỏ qua hoặc không dùng để tạo finding nào" ở cuối output. Đây là cách kiểm tra chéo — nếu bạn thấy một dòng OBS quan trọng bị bỏ qua, đó là dấu hiệu prompt hoặc note của bạn cần rõ ràng hơn.

Làm Việc Với Output Sau Khi Synthesize

Output của AI không phải là bản final để gửi đi ngay — nó là bản draft cần bạn review theo 3 bước:

1. Kiểm tra reproduction steps có đúng với thực tế không. AI đôi khi suy luận thêm bước trung gian nghe "hợp lý" nhưng không có trong note gốc của bạn. Đọc lại raw note gốc song song để đối chiếu.
2. Đánh giá lại severity. AI đoán severity dựa trên ngôn ngữ mô tả, nhưng không có context về business impact (ví dụ: bug này ảnh hưởng bao nhiêu % user, có liên quan revenue không). Bạn — người hiểu domain — cần điều chỉnh severity cuối cùng.
3. Xác minh lại (re-verify) trước khi log chính thức, đặc biệt với finding có "Confidence: Low". Đừng log bug ra hệ thống tracking chỉ dựa trên suy luận của AI — hãy tái hiện lại ít nhất một lần.

Mẹo: Nếu team bạn có nhiều tester cùng dùng prompt này, hãy chuẩn hoá prompt thành một file synthesis-prompt.md chung trong repo, để mọi finding có cùng cấu trúc — điều này giúp việc gộp finding từ nhiều session (ở phần sau bài này) dễ hơn rất nhiều.

Ví Dụ: Từ Raw Notes Đến Structured Findings

Hãy xem một ví dụ cụ thể với feature "Áp dụng mã giảm giá trong giỏ hàng" của một app thương mại điện tử.

Raw notes (trong lúc test):

[14:10] ACTION: Thêm sản phẩm A (200k) vào cart
[14:11] ACTION: Áp voucher SUMMER20 (giảm 20%)
[14:11] OBS: Tổng tiền hiển thị 160k - đúng
[14:12] ACTION: Thêm sản phẩm B (100k) vào cart (không remove voucher)
[14:12] OBS: Tổng tiền hiển thị 260k, KHÔNG áp lại giảm giá cho sản phẩm mới
[14:13] Q: Voucher có tính lại theo subtotal mới không, hay chỉ tính 1 lần lúc apply?
[14:14] ACTION: Remove sản phẩm B, thêm lại sản phẩm B
[14:14] OBS: Lần này giảm giá tính đúng: 240k -> 192k
[14:15] Q: Vậy bug chỉ xảy ra khi ADD thêm item trong khi voucher đang active, không xảy ra khi remove-rồi-add-lại?
[14:17] ACTION: Thử lại với voucher khác (FIXED50 - giảm cố định 50k)
[14:17] OBS: Cùng hiện tượng - thêm item mới không được áp giảm giá cố định
[14:18] SEVERITY-GUESS: Cao, vì user sẽ trả nhiều tiền hơn họ nghĩ, và khó nhận ra vì UI không báo lỗi gì

Sau khi đưa vào prompt synthesis, AI trả về (đã được review và chỉnh severity theo business context):

### Finding 1: Voucher không tự tính lại khi thêm sản phẩm mới vào cart sau khi đã apply

- Category: Bug
- Severity: High — user bị tính sai tiền, không có cảnh báo, ảnh hưởng trực tiếp trust
  và có thể dẫn tới complaint/refund request
- Reproduction steps:
  1. Thêm sản phẩm A vào cart
  2. Áp voucher (đã test với cả % giảm và giảm cố định)
  3. Xác nhận giảm giá áp đúng cho sản phẩm A
  4. Thêm sản phẩm B vào cart MÀ KHÔNG remove voucher
  5. Quan sát: tổng tiền không áp giảm giá cho sản phẩm B, hoặc không tính lại đúng
- Observed behavior: Voucher dường như chỉ được tính toán một lần tại thời điểm apply,
  không re-calculate khi cart thay đổi (thêm item mới)
- Suspected root cause: Logic tính giảm giá có thể đang cache giá trị discount tại thời
  điểm apply thay vì tính lại theo subtotal hiện tại mỗi khi cart thay đổi
- Confidence: High — tái hiện được 2 lần với 2 loại voucher khác nhau, hiện tượng nhất quán

### Finding 2: Remove-rồi-add-lại sản phẩm khiến voucher tính lại đúng (khác hành vi so với add trực tiếp)

- Category: Needs more investigation
- Severity: Medium — không phải bug độc lập nhưng là clue quan trọng cho root cause của Finding 1
- Observed behavior: Khi remove item rồi add lại (thay vì add thêm item mới), discount
  được tính lại chính xác. Gợi ý rằng có một event/trigger khác nhau giữa hai luồng
  (có thể "add new line item" không trigger recalculation, còn "update existing line item"
  hoặc full re-render thì có)
- Confidence: Medium — chỉ test 1 lần theo hướng này, cần thêm test case xác nhận

Chú ý cách AI tách rõ hai finding dù chúng liên quan chặt tới nhau — điều này giúp dev dễ debug hơn vì Finding 2 chính là đầu mối kỹ thuật cho Finding 1.

Dùng AI Phát Hiện Pattern Xuyên Nhiều Session Exploratory Như Thế Nào?

Một session đơn lẻ chỉ cho bạn một mảnh của bức tranh. Giá trị thật của exploratory testing xuất hiện khi bạn nhìn nhiều session cùng lúc — pattern nào lặp lại, khu vực nào liên tục sinh bug, loại lỗi nào tái diễn dưới các hình thức khác nhau. Đây là việc con người rất khó làm bằng tay (vì trí nhớ không đủ để so sánh 15-20 session cách nhau vài tuần), nhưng AI làm được nếu bạn có archive đủ tốt.

Xây Dựng Session Archive

Trước khi phân tích pattern, bạn cần một nơi lưu tất cả session note và finding theo cấu trúc nhất quán. Cấu trúc tối thiểu tôi khuyên dùng:

/exploratory-sessions/
  2026-06-15-checkout-voucher/
    raw-notes.md
    findings.md
    session-meta.yaml   # feature area, tester, duration, env
  2026-06-22-billing-upgrade/
    raw-notes.md
    findings.md
    session-meta.yaml
  ...

File session-meta.yaml nên có ít nhất các trường:

date: 2026-06-15
tester: "Dat H."
feature_area: "Checkout / Voucher"
duration_minutes: 55
environment: "staging, feature_flag new_cart_v2=true"
finding_count: 2
highest_severity: "High"

Metadata này chính là "chỉ mục" giúp AI biết session nào liên quan tới session nào khi bạn hỏi về pattern theo feature area hoặc theo thời gian.

Mẹo: Đừng archive chỉ finding — giữ cả raw notes. Nhiều lần pattern thật sự chỉ lộ ra khi AI đọc lại raw notes của nhiều session (vì có những quan sát "không đủ để thành finding" ở mỗi session riêng lẻ, nhưng lặp lại đủ nhiều lần thì thành một pattern đáng chú ý).

Prompt Pattern: Cross-Session Pattern Analysis

Khi đã có archive, đây là prompt tôi dùng để phân tích pattern, thường chạy mỗi 2-4 tuần hoặc trước mỗi release lớn:

You are analyzing multiple exploratory testing sessions to find patterns
that aren't visible when looking at any single session alone.

I will provide findings.md and session-meta.yaml from N sessions below,
covering the period [date range].

[paste nội dung findings + metadata của các session, gộp theo thứ tự thời gian]

Analyze across all sessions and answer:

1. RECURRING ROOT CAUSES: Are there findings across different sessions/features
   that likely share the same underlying root cause (e.g. same kind of race
   condition, same kind of stale-cache issue, same kind of validation gap)?
   Group them even if they were logged under different feature areas.

2. FEATURE AREA HOTSPOTS: Which feature areas have the highest density of
   findings relative to how much they were tested? Call out areas that keep
   producing findings across multiple sessions.

3. BLIND SPOT SIGNALS: Are there recurring "Q:" hypotheses or "Needs more
   investigation" findings across sessions that were never followed up or
   resolved? List them as open threads.

4. SEVERITY TREND: Is the average severity of findings increasing, decreasing,
   or stable across the session timeline? Is that trend concentrated in a
   specific feature area?

5. TESTING BLIND SPOTS: Based on the feature areas and action types
   (ACTION lines) covered across sessions, what types of user flows or edge
   cases have NOT been explored at all in this period?

For each point, cite which sessions (by date) support the conclusion —
do not make claims without pointing to specific evidence.

Yêu cầu "cite which sessions" ở cuối là bắt buộc — nếu không, AI dễ đưa ra nhận định nghe hợp lý nhưng không kiểm chứng được, và bạn sẽ không biết tin đến đâu.

Đọc Hiểu Output Phân Tích Pattern

Một output thực tế (rút gọn) có thể trông như sau, từ 6 session trong 1 tháng của một sản phẩm SaaS:

1. RECURRING ROOT CAUSES:
   - "Stale cached value not recalculated after state change" xuất hiện ở:
     2026-06-15 (voucher không tính lại subtotal), 2026-06-29 (invoice
     preview không cập nhật sau khi đổi seat count), 2026-07-02 (dashboard
     KPI card không refresh sau khi đổi filter date range).
     -> Có khả năng đây là một pattern kiến trúc chung (thiếu invalidation
     logic khi state thay đổi), không phải 3 bug riêng lẻ.

2. FEATURE AREA HOTSPOTS:
   - "Billing / Upgrade flow" xuất hiện trong 4/6 session với ít nhất 1
     finding severity Medium+ mỗi lần, dù chỉ chiếm khoảng 20% tổng thời
     gian test. Density cao bất thường so với các khu vực khác.

3. BLIND SPOT SIGNALS:
   - Câu hỏi "Điều gì xảy ra nếu 2 request update cùng lúc" xuất hiện dạng
     Q: ở 3 session khác nhau (06-15, 06-22, 07-02) nhưng chưa từng có
     finding chính thức nào điều tra race condition trực tiếp.

4. SEVERITY TREND:
   - Severity trung bình tăng nhẹ trong 4 tuần gần nhất, tập trung ở Billing.

5. TESTING BLIND SPOTS:
   - Không có session nào explore luồng "downgrade plan" hoặc "cancel
     subscription" — toàn bộ 6 session tập trung vào upgrade/billing tăng.

Đây là loại insight mà nếu chỉ nhìn từng session riêng, bạn sẽ không bao giờ thấy — cả 3 root cause khác nhau (voucher, invoice, dashboard) đều là một dạng lỗi kiến trúc chung, và có một câu hỏi về race condition bị lặp lại 3 lần mà chưa ai chính thức điều tra.

Mẹo: Khi AI chỉ ra một "recurring root cause" xuyên nhiều feature, đừng log nó như 3 bug riêng — hãy tạo một ticket kỹ thuật riêng đề xuất điều tra root cause chung, kèm link tới cả 3 finding cụ thể làm bằng chứng. Cách này giúp team lead/dev lead nhìn thấy đây là vấn đề kiến trúc cần ưu tiên, không phải 3 bug lẻ tẻ ưu tiên thấp.

Theo Dõi Coverage Qua Nhiều Session Bằng Feature Area Map

Ngoài phân tích pattern lỗi, bạn cần một cách nhìn tổng quan xem khu vực nào đã được explore, khu vực nào chưa. Một feature area coverage map đơn giản:

Bảng này nên được cập nhật sau mỗi session (chỉ cần 1-2 dòng), và chính là input cho phần tiếp theo — dùng AI để tìm coverage debt.

Dùng AI Để Xác Định Coverage Debt

"Coverage debt" ở đây là các khu vực rủi ro cao nhưng lại ít hoặc chưa được explore. Prompt để AI giúp bạn ưu tiên session tiếp theo:

Here is our feature area coverage map for exploratory testing over the
last quarter:

[paste bảng feature area coverage map]

Additional context:
- Feature areas closely tied to revenue: Billing, Subscription
  (upgrade/downgrade/cancel), Checkout
- Feature areas recently changed by engineering (last 30 days):
  [liệt kê từ changelog/release notes]

Based on this, recommend the top 3 areas we should prioritize for the next
round of exploratory sessions. For each recommendation, justify using:
- Revenue/business risk
- Recency of code change (higher risk if recently modified and under-tested)
- Time since last exploration
- Any unresolved "Q:" hypotheses from past sessions in that area

Also flag if any area is being over-tested relative to its risk profile,
so we can reallocate testing time.

Với ví dụ coverage map trên, AI hầu như chắc chắn sẽ đề xuất "Subscription downgrade/cancel" là ưu tiên số 1 (chưa từng explore, gắn trực tiếp với revenue), và "Billing/Upgrade" ưu tiên tiếp theo để điều tra race condition đã bị nghi ngờ 3 lần nhưng chưa xác nhận.

Mẹo: Đưa coverage map và kết quả đề xuất của AI vào buổi retro/planning hàng tuần của team QA — nó biến exploratory testing từ hoạt động "ngẫu nhiên, tuỳ hứng" thành một hoạt động có định hướng dữ liệu, dễ giải thích với QA lead hoặc PM vì sao bạn chọn test khu vực này mà không phải khu vực khác.

Chuyển Đổi Exploratory Findings Thành Bug Report, Test Case, Và Coverage Update Như Thế Nào?

Finding đã synthesize xong chỉ là bước giữa. Giá trị cuối cùng nằm ở việc chuyển nó thành tài sản mà team dùng lại được: bug ticket dev có thể fix ngay, test case automation/regression có thể chạy lại, và coverage tracking phản ánh đúng thực tế.

Chuyển Đổi Finding Thành Bug Report

Từ finding đã synthesize ở phần trước, việc tạo bug report chuẩn để log vào Jira/Linear chỉ còn là format lại theo template của team. Prompt mẫu:

Convert the following exploratory testing finding into a bug report formatted
for our issue tracker (Jira). Use this template exactly:

Title: [concise, searchable]
Environment:
Steps to Reproduce:
Expected Result:
Actual Result:
Severity: [Critical/High/Medium/Low] - [one sentence reason]
Suspected Root Cause: [mark clearly as hypothesis]
Attachments needed: [what screenshot/log/video would help confirm this,
  based on what's missing from the finding]

Finding:
[paste finding]

Do not invent an "Expected Result" that isn't clearly implied by the finding
or standard product behavior — if expected behavior is ambiguous, say so
explicitly instead of guessing.

Điểm mấu chốt là dòng cuối — AI thường có xu hướng "đoán" expected result nghe hợp lý, nhưng nếu bug liên quan đến business logic đặc thù (như cách tính giảm giá), bạn — người hiểu domain — mới nên xác nhận expected result là gì, không phải AI đoán.

Chuyển Đổi Finding Thành Test Case

Một finding sau khi fix xong cần trở thành test case để tránh regression. Prompt:

Convert this confirmed bug finding into a formal test case suitable for our
regression suite. Use this format:

Test Case ID: [leave as TBD-<short-slug>]
Title:
Preconditions:
Test Steps: [numbered, precise enough for someone unfamiliar with the bug
  to execute without guessing]
Expected Result: [what should happen when the bug is fixed]
Test Data Needed:
Priority: [based on severity + how likely this scenario is in real usage]

Also generate 2 additional boundary/variation test cases that test the same
underlying logic but with different inputs (e.g. different voucher types,
different cart states) to make sure we cover the root cause broadly, not
just the exact scenario that was found.

Finding:
[paste finding]

Yêu cầu "2 additional boundary/variation test cases" là phần quan trọng nhất — vì một bug tìm ra qua exploratory thường chỉ là MỘT biểu hiện của một root cause rộng hơn. Nếu bạn chỉ viết test case đúng y kịch bản đã gặp, bạn để lại rất nhiều biến thể chưa được cover.

Mẹo: Với bug dạng "logic tính toán sai" (như ví dụ voucher ở trên), luôn yêu cầu AI generate thêm test case cho edge case về số lượng (0 item, 1 item, nhiều item), về loại input (giảm % vs giảm cố định), và về thứ tự thao tác (add trước/sau khi apply, remove rồi add lại) — đây là 3 chiều biến thiên thường sinh ra nhiều bug ẩn nhất trong logic pricing/discount.

Sinh Test Case Suite Từ Session Findings

Khi một session sinh ra nhiều finding liên quan (như ví dụ Finding 1 và Finding 2 ở trên), đừng tạo test case rời rạc — hãy yêu cầu AI tạo một suite có cấu trúc:

I have multiple related findings from one exploratory session about the
cart discount recalculation issue. Generate a structured test suite (not
just a flat list) that:

1. Groups test cases by the underlying behavior being verified (e.g.
   "Discount recalculation on cart mutation", "Discount recalculation
   consistency between add vs remove-and-readd")
2. Within each group, orders test cases from simplest to most complex
3. Marks which test cases are candidates for automation (deterministic,
   no manual judgment needed) vs which should remain manual/exploratory
   (requires human judgment about UX, e.g. "is the lack of warning message
   confusing to a real user")

Findings:
[paste tất cả finding liên quan từ session]

Việc phân loại "candidate for automation vs remain manual" ở bước 3 rất thực tế — không phải mọi test case sinh ra từ exploratory đều nên tự động hoá. Một số case (như "tổng tiền tính đúng sau khi thêm item") rất phù hợp automation. Nhưng case như "UI không cảnh báo gì khi có sai lệch" mang tính đánh giá UX, phù hợp hơn để giữ lại làm checklist cho exploratory session sau, không nhất thiết phải automate.

Cập Nhật Test Coverage Tracking

Sau khi finding đã thành bug report và test case, đừng quên vòng cuối: cập nhật lại coverage tracking (bảng feature area map ở phần trước, hoặc test management tool như TestRail/Xray nếu team dùng). Đây là bước hay bị bỏ qua nhất vì nó không "khẩn cấp" như việc log bug.

Prompt để AI hỗ trợ cập nhật nhanh:

Based on this session's findings and the new test cases generated, draft an
update to our feature area coverage map. Specifically:

- Update the "last explored" date for [feature area]
- Update the cumulative finding count and highest severity
- Note whether the new test cases generated should reduce the "risk" rating
  of this feature area going forward, or whether they only cover the found
  bug and the area still needs broader exploration

Current row for this feature area:
[paste dòng hiện tại trong coverage map]

New findings and test cases from this session:
[paste]

Mẹo: Đặt lịch cập nhật coverage map như một phần "definition of done" của mỗi session exploratory — nếu không, coverage map sẽ nhanh chóng lỗi thời và mất tác dụng định hướng ưu tiên cho phần trước (coverage debt).

Truyền Đạt Finding Cho Stakeholder

Bug report và test case dành cho dev/QA, nhưng PM và stakeholder cần một dạng tóm tắt khác — ngắn, tập trung vào impact, không cần chi tiết kỹ thuật. Prompt:

Summarize this exploratory testing session for a non-technical stakeholder
(Product Manager). Requirements:
- Max 150 words
- Lead with business impact, not technical detail
- Use plain language, no jargon like "race condition" or "cache invalidation"
  unless immediately explained in one clause
- End with a clear recommendation: what decision or action is needed from
  the PM (e.g. prioritize fix before next release, accept as known issue,
  need more investigation before deciding)

Session findings:
[paste findings]

Một bản tóm tắt tốt cho PM, dựa trên ví dụ voucher ở trên, có thể là:

Trong phiên test tuần này, chúng tôi phát hiện một lỗi khiến khách hàng có
thể bị tính SAI TIỀN khi thêm sản phẩm vào giỏ hàng sau khi đã áp mã giảm
giá — hệ thống không tự tính lại giảm giá cho sản phẩm mới thêm. Lỗi xảy ra
nhất quán với cả hai loại mã giảm giá đã test và không có cảnh báo nào cho
khách hàng, nghĩa là họ có thể trả nhiều tiền hơn dự kiến mà không biết.

Đề xuất: Ưu tiên fix trước release tới, vì lỗi ảnh hưởng trực tiếp đến trải
nghiệm thanh toán và có rủi ro về khiếu nại/hoàn tiền. Chúng tôi đã có test
case cụ thể để dev verify sau khi fix.

Mẹo: Luôn kèm một câu "recommendation" rõ ràng ở cuối summary cho stakeholder — PM bận rộn thường chỉ đọc phần cuối, và nếu bạn không đề xuất hành động cụ thể, họ sẽ phải hỏi lại bạn, làm mất thời gian của cả hai bên.

Tổng kết lại, việc document và synthesize findings từ exploratory testing với AI không phải là "chép note vào ChatGPT cho gọn". Nó là một quy trình có chủ đích: ghi note đúng cấu trúc ngay từ đầu, dùng AI để tổng hợp thành finding rõ ràng và có độ tin cậy được đánh giá minh bạch, dùng AI để tìm pattern xuyên nhiều session mà con người khó tự phát hiện, và cuối cùng chuyển hoá toàn bộ thành tài sản lâu dài cho team — bug report, test case, coverage map. Khi làm đúng, mỗi session exploratory không còn là một hoạt động "một lần rồi quên", mà trở thành một phần dữ liệu tích lũy giúp cả team hiểu rõ hơn sản phẩm của mình theo thời gian.