Tiếng Việt: Hands-on: AI-guided exploratory testing session

Bốn bài trước trong module này đã cho bạn từng miếng ghép: AI đóng vai trò gì trong exploratory testing, cách viết charter bằng prompt, cách AI giúp ghi chép và tổng hợp phát hiện, và cách ưu tiên vùng khám phá theo rủi ro. Bài này ghép tất cả lại thành một buổi kiểm thử thật, chạy đúng 90 phút, có timeline theo từng phút, có prompt thật, có output AI trả về thật (mô phỏng lại từ những buổi tôi đã chạy với các đội sản phẩm streaming).

Để bài viết bám sát thực tế, tôi dùng một tính năng cụ thể xuyên suốt: "Resume Playback Across Devices" (tiếp tục xem đồng bộ trên nhiều thiết bị) của một ứng dụng xem phim/truyền hình giả định tên VivuTV — chạy trên mobile (iOS/Android) và Smart TV/CTV (Connected TV, gồm Android TV, tvOS, các dòng TV có hệ điều hành riêng như Tizen/webOS). Tính năng: người dùng xem một tập phim trên điện thoại, tắt app giữa chừng, sau đó mở app trên TV — app phải tự động nhắc "Tiếp tục xem từ 12:34" và resume đúng vị trí, đúng phụ đề, đúng audio track đã chọn.

Đây là loại tính năng lý tưởng cho exploratory testing: logic đồng bộ qua nhiều thiết bị, phụ thuộc network, phụ thuộc trạng thái background/foreground, và có rất nhiều "đường tắt" mà test case viết sẵn không bao giờ lường hết. Người thực hiện buổi kiểm thử trong bài là Lan — QA Engineer senior, đã làm automation 5 năm, giờ muốn khai thác AI cho phần việc mà automation không làm tốt: tìm ra cái không ai nghĩ tới.

Chuẩn Bị Buổi Kiểm Thử Khám Phá Thế Nào — Charter, Context, Và Tooling?

Một buổi kiểm thử khám phá thất bại thường không phải vì tester thiếu kỹ năng, mà vì thiếu chuẩn bị: không rõ mục tiêu, không có đủ context để AI hỗ trợ đúng hướng, và công cụ ghi chép quá rời rạc khiến 30% thời gian session bị nuốt vào việc gõ lại thao tác vừa làm.

Bước 1: Thu Thập Input

Trước khi mở app, Lan dành 15 phút gom input — làm càng kỹ ở đây, session càng sắc. Danh sách input cần có:

• Feature spec / PRD của Resume Playback Across Devices (bản rút gọn 2 trang, không cần đầy đủ 20 trang gốc).
• Ticket lịch sử: các bug liên quan đến resume, sync, hoặc playback đã từng ghi nhận trong 2 release gần nhất.
• Kiến trúc kỹ thuật ở mức tổng quan: resume position được lưu ở đâu (server, local cache, hay cả hai), đồng bộ qua REST polling hay push (WebSocket/FCM), độ trễ đồng bộ kỳ vọng là bao nhiêu giây.
• Thiết bị thật có sẵn: 1 iPhone, 1 Android phone tầm trung (thường là nơi phát sinh bug nhiều nhất do phần cứng yếu), 1 Android TV box, 1 Smart TV Samsung (Tizen).
• Điều kiện mạng có thể giả lập: Wi-Fi ổn định, 4G, mạng chập chờn (dùng Charles Proxy hoặc Network Link Conditioner để throttle).

Lan gom các tài liệu này vào một thư mục rồi đưa cho AI (dán trực tiếp nội dung spec và danh sách bug lịch sử vào prompt, vì đa số công cụ AI hiện chưa tự đọc được file đính kèm nội bộ của công ty).

Mẹo: Đừng dán nguyên văn 20 trang PRD vào context window (bộ nhớ ngữ cảnh AI xử lý được trong một lần) — hãy tự tóm tắt trước thành 10-15 dòng gạch đầu dòng gồm: mục đích tính năng, luồng chính, ràng buộc kỹ thuật, và bug lịch sử. Context gọn giúp AI trả lời đúng trọng tâm hơn là khi phải tự lọc nhiễu từ văn bản dài dòng, và cũng tiết kiệm token đáng kể khi bạn cần hỏi qua lại nhiều vòng trong 90 phút.

Bước 2: Tạo Charter Cho Session

Charter là "kim chỉ nam" của buổi kiểm thử — không phải test case, mà là câu hỏi mở định hướng khám phá. Lan dùng prompt sau:

You are helping me plan a 90-minute exploratory testing session.

Feature: "Resume Playback Across Devices" in VivuTV streaming app.
- User watches on Device A, pauses/closes app, opens Device B, app should
  offer to resume at the last watched position (video timestamp, subtitle
  language, audio track).
- Sync mechanism: resume position is saved to server via REST call every
  10 seconds during playback and on pause/background; client polls server
  on app foreground.
- Known historical bugs (last 2 releases): resume position sometimes lags
  by 30-60s on poor network; subtitle language not restored on Android TV.

Devices available: iPhone 14 (iOS 17), Samsung A34 (Android 13),
Android TV box (Android TV 12), Samsung Smart TV (Tizen).
Network tools available: Charles Proxy for throttling/dropping connections.

Generate a session charter with:
1. A mission statement (1 sentence)
2. 4-6 risk areas to explore, ordered by likely impact
3. For each risk area, 2-3 guiding questions (not test steps)
4. Suggested time allocation across the 90 minutes

AI trả về một charter, Lan chỉnh sửa một vài chỗ dựa trên hiểu biết thực tế của mình (ví dụ: đẩy "network resilience" lên ưu tiên 1 vì đội dev vừa đổi cơ chế polling tuần trước), rồi chốt bản cuối:

SESSION CHARTER — Resume Playback Across Devices
Mission: Explore whether resume-across-device behaves correctly and
gracefully under real-world network and device-state conditions,
prioritizing scenarios most likely to break silently (no crash, no error,
just wrong behavior).

Risk areas (priority order):
1. Network resilience during sync (poor/intermittent connection)
2. Cross-device state consistency (subtitle, audio track, position)
3. Background/foreground and app-kill lifecycle edge cases
4. CTV-specific input/remote quirks affecting resume prompt
5. Concurrent playback on two devices at once

Time allocation:
- 0-20min: orientation + risk area 1 (network)
- 20-50min: deep dive risk area 1 continued + risk area 2
- 50-75min: risk area 3 + risk area 4 (CTV)
- 75-90min: coverage review, wrap-up notes

Bước 3: Chuẩn Bị Công Cụ

Không có gì phá session nhanh hơn việc vừa test vừa loay hoay tìm công cụ ghi chép. Lan chuẩn bị:

• Một cửa sổ chat AI mở song song (dùng Claude hoặc công cụ tương đương), đặt sẵn system context là charter ở trên, để không phải nhắc lại mỗi lần hỏi.
• Một file ghi chép session (markdown, hoặc dùng note-taking tool có timestamp tự động) — mọi quan sát được gõ vào đây theo mốc thời gian, kể cả cái tưởng như "không quan trọng".
• Charles Proxy cấu hình sẵn 3 profile: Wi-Fi ổn định (baseline), 4G throttled (2 Mbps, latency 300ms), mạng rớt gói ngẫu nhiên (packet loss 15%).
• Màn hình quay lại (screen recording) trên cả 2 thiết bị chính, để khi cần báo bug có bằng chứng ngay, không phải tái hiện lại.
• Một bảng risk-to-coverage kẻ sẵn 5 dòng (theo 5 risk area) để tick real-time mức độ đã khám phá.

Mẹo: Thiết lập AI chat với một "system prompt" cố định chứa charter và context kỹ thuật ngay từ đầu session, thay vì phải paste lại mỗi câu hỏi. Việc này giữ AI bám sát ngữ cảnh xuyên suốt 90 phút và giảm hẳn tình trạng AI trả lời chung chung như thể mới gặp lần đầu.

Dùng AI Như Một Đối Tác Đồng Hành Thời Gian Thực Trong Buổi Kiểm Thử Ra Sao?

Đây là phần lõi của bài — timeline thật, prompt thật, note thật. AI không tự bấm nút trên thiết bị (đó vẫn là việc của Lan), nhưng đóng vai trò brainstorm biến thể kiểm thử, phản biện giả thuyết, và giúp diễn giải log/network trace nhanh hơn tự đọc.

Phút 0–20: Định Hướng Theo Charter Và Vùng Rủi Ro Đầu Tiên

00:00 — Lan mở app trên iPhone, xem video khoảng 90 giây ở tập 3 của một series, rồi tắt app hoàn toàn (swipe kill, không chỉ background). Mở app trên Android TV. App hiện prompt "Tiếp tục xem từ 01:32" — đúng như kỳ vọng ở điều kiện Wi-Fi ổn định. Ghi log baseline: PASS — baseline resume chính xác trên Wi-Fi ổn định, độ trễ đồng bộ ~3s.

00:08 — Lan hỏi AI để mở rộng biến thể trước khi lặp lại dưới điều kiện mạng xấu:

Baseline resume worked fine on stable Wi-Fi (3s sync delay). Before I move
to poor-network testing, what are 5 variations of "pause point" I should
try that are more likely to expose off-by-one or rounding bugs in resume
position tracking? Think about timestamps that are edge cases for a
system saving position every 10 seconds.

AI trả về (đã được Lan rút gọn lại trong note):

1. Pause exactly at a 10s save boundary (e.g. 00:10, 00:20) — check for
   race between save-tick and pause event.
2. Pause during a mid-segment ad break (if pre-roll/mid-roll ads exist) —
   resume position might anchor to ad time instead of content time.
3. Pause within the first 5s of playback — server may not have received
   any save yet, check fallback behavior (resume from 0 vs no prompt).
4. Pause at the very last few seconds of an episode — check if it
   triggers "next episode" resume instead of re-watching the same one.
5. Pause, then seek backward locally, then close immediately — check
   whether the last SAVED position or the last SEEKED position wins.

Đây chính là giá trị của AI trong exploratory testing: không tự nó biết đúng sai, nhưng nó liệt kê biến thể có hệ thống nhanh hơn não người đang vừa test vừa nghĩ. Lan chạy thử case số 5 ngay — và phát hiện: seek lùi về 00:45 rồi tắt app trong vòng 2 giây, khi mở lại trên TV app resume ở vị trí 01:30 (vị trí trước khi seek) — tức là local seek chưa được save kịp trước khi app bị kill. Ghi bug candidate #1.

00:18 — Lan tick vào bảng coverage: risk area 1 (network resilience) — chưa chạm network xấu, nhưng đã có 1 bug ứng viên liên quan timing save.

Phút 20–50: Kiểm Thử Khả Năng Chịu Lỗi Mạng (Network Resilience)

00:20 — Chuyển sang Charles Proxy, áp profile "4G throttled" cho điện thoại. Xem video 40 giây, sau đó bật thêm "packet loss 15%" trong lúc video đang chạy, rồi pause và tắt app.

00:24 — Mở app trên Android TV (đang ở mạng ổn định). Prompt resume hiện ra sau 9 giây trễ (so với baseline 3s) — chấp nhận được, nhưng Lan muốn biết ngưỡng nào là bất thường, nên hỏi AI:

On a mobile client with 15% packet loss and throttled 4G, the resume
sync took 9s to reflect on a second device (vs 3s baseline). The app
doesn't show any loading/pending indicator during that gap — the resume
prompt on the TV either shows the old timestamp or nothing until sync
completes. From a UX-risk standpoint, at what delay threshold does this
become a real problem, and what's the most likely failure mode if the
user acts before sync completes (e.g. opens TV app and immediately
presses play before the correct resume position has propagated)?

AI phản hồi:

There isn't a universal "safe" threshold, but for resume-across-device
UX, most streaming products treat anything beyond ~5-8s as noticeable
lag that risks user distrust ("did it save my progress?").

Most likely failure mode if the user acts before sync completes: the TV
client resumes from the LAST KNOWN position it already had cached
(stale), not the true last position — meaning the user could lose
progress silently, with no error shown. This is a "silent data
staleness" risk rather than a crash risk, which is exactly the kind of
bug that slips through scripted regression because it requires precise
timing between two devices to reproduce.

Suggested probe: intentionally race the two actions — pause on device A,
then immediately (within 1-2s) open device B and press Play before
waiting for any sync indicator.

00:31 — Lan thực hiện đúng race condition trên. Kết quả: trên Android TV, nhấn Play ngay lập tức resume từ vị trí cũ hơn 47 giây so với vị trí thật vừa pause trên điện thoại — không có cảnh báo, không loading state. Đây là bug nghiêm trọng hơn bug #1, vì xảy ra cả trên network throttled bình thường, không cần packet loss cực đoan. Ghi bug candidate #2 — mức độ: Cao. Silent data staleness, không có error, không loading indicator.

00:40 — Lan lặp lại với "packet loss 15%" áp cho phần polling (không phải lúc save) để xem app có retry hay không. AI được hỏi thêm để đề xuất cách phân biệt lỗi network với lỗi logic:

I want to isolate whether the 47-second staleness bug is a network
retry/timeout issue or a client-side caching logic issue. What's a quick
diagnostic test I can run with Charles Proxy to tell the difference?

Try this: set network to fully stable (no throttle, no packet loss) but
insert an artificial 8-10s delay on ONLY the GET /resume-position
endpoint (not the save endpoint). If the TV client still resumes from a
stale cached position instead of waiting for or re-fetching the fresh
value, that confirms client-side caching logic is the root cause, not
network flakiness — the client is trusting a local cache without
invalidating it on foreground, regardless of network condition.

Lan làm đúng vậy — chỉ delay riêng endpoint GET resume-position, giữ network sạch hoàn toàn. Bug vẫn xảy ra. Kết luận: đây là lỗi logic client-side (cache không được invalidate khi app foreground), không phải lỗi do mạng. Đây là thông tin then chốt giúp dev fix đúng chỗ, tránh mất thời gian đổ oan cho hạ tầng mạng.

Mẹo: Khi AI đề xuất một giả thuyết ("có thể là network" hay "có thể là logic client"), luôn thiết kế một thí nghiệm tối thiểu để tách biến — thay đổi đúng một yếu tố mỗi lần. AI giỏi đề xuất thí nghiệm cách ly biến số nhanh hơn khi bạn đang bị cuốn vào việc tái hiện bug, nhưng người quyết định thí nghiệm nào đáng chạy vẫn là bạn.

Phút 50–75: Mobile Layout Và Các Vùng Rủi Ro Còn Lại

00:50 — Chuyển sang risk area 3 và 4: lifecycle app và các quirk đặc thù CTV. Lan hỏi AI để mở rộng góc nhìn về hành vi bàn phím điều khiển TV (remote) — một khu vực cô ít kinh nghiệm hơn vì chủ yếu làm mobile QA trước đây:

I'm now testing the resume prompt specifically on Android TV and Tizen
Smart TV, navigated via a physical remote (D-pad, no touch). What are
common exploratory angles specific to CTV remote navigation that mobile
testers often overlook when testing a "Resume/Start Over" confirmation
dialog?

A few CTV-specific angles worth probing:
1. Default focus element on the resume dialog — does "Resume" or "Start
   Over" get default D-pad focus? Wrong default focus is a common but
   easy-to-miss usability bug, and on some TVs it varies by remote type
   (voice remote vs basic remote).
2. Focus trap: can the user D-pad away from the dialog into background
   content without dismissing it, leaving an inconsistent state?
3. Long-press / repeat key behavior — rapid repeated "select" presses
   while the dialog is loading; does it register multiple resume
   requests?
4. Back button behavior — does pressing Back on the dialog cancel
   resume, exit the app, or silently do nothing?
5. Voice remote edge case — saying "resume" or "play" via voice search
   while the dialog is showing; does voice intent bypass the dialog
   state entirely?

00:58 — Lan test lần lượt. Case 3 (nhấn lặp nút select khi dialog đang loading) tạo ra hiện tượng: app gửi 2 request resume liên tiếp, dẫn đến hai session playback song song trong 1-2 giây trước khi một session bị kill — không crash nhưng có giật hình rõ rệt. Ghi bug candidate #3 — mức độ: Trung bình, ảnh hưởng trải nghiệm, không mất dữ liệu.

01:05 — Case default focus (case 1): trên remote giọng nói của Android TV, focus mặc định rơi vào "Start Over" thay vì "Resume" — ngược với hành vi trên remote thường. Đây là kiểu bug tinh vi mà automation script (thường giả lập sự kiện, không giả lập đúng loại remote thật) gần như không bao giờ bắt được. Ghi bug candidate #4.

01:12 — Quay lại risk area 3 (lifecycle), test kịch bản: mở app, để idle (không tương tác) đủ lâu cho hệ điều hành background app (khoảng 20 phút mô phỏng nhanh bằng cách force-stop qua Developer Options), rồi mở lại. Vị trí resume đúng — không có bug ở nhánh này. Ghi PASS, cập nhật coverage.

Phút 75–90: Rà Soát Coverage Và Kết Thúc Session

01:15 — Còn 15 phút, Lan dùng AI để soát lại nhanh: những gì đã làm, những gì charter đề ra nhưng chưa chạm tới, và độ ưu tiên cho lần sau.

Here's my coverage so far against the charter (paste risk areas +
what's tested). Given remaining 15 minutes, which single risk area or
scenario would you prioritize to test next, and why, versus documenting
what I already have?

AI (dựa trên context đã tích lũy suốt session) trả lời:

You've covered network resilience deeply (2 real bugs) and CTV remote
navigation lightly (2 bugs found in ~15min — this area is clearly
richer than expected). Risk area 5 (concurrent playback on two devices
at once) is untouched and was rated priority 5, but given how much
staleness/race-condition behavior you already found in area 1, there's
a reasonable chance area 5 shares the same root cause (cache not
invalidated on foreground) rather than being an independent risk.

Recommendation: spend remaining time documenting thoroughly (bugs are
only valuable if reproducible from notes) rather than opening a new
risk area with 15 minutes left. A rushed 10-minute probe into
concurrent playback risks a "maybe bug" you can't reproduce later,
which costs more debrief time than it saves.

Lan làm theo — dùng 12 phút còn lại để bổ sung chi tiết tái hiện cho 4 bug candidate (bước chính xác, thiết bị, điều kiện mạng, video timestamp minh chứng), và note lại risk area 5 là "chưa test — nghi vấn liên quan cùng root cause với bug #2, nên gộp vào regression khi bug #2 được fix" — một quan sát quan trọng để không lãng phí công sức test trùng lặp sau này.

Mẹo: Luôn dành ít nhất 10-15% thời gian session (ở đây là ~10 phút trong 90) chỉ để hỏi AI "tôi nên tiếp tục khám phá hay nên dừng lại ghi chép?" — phản xạ tự nhiên của tester giỏi là luôn muốn thử thêm một biến thể nữa, nhưng bug không ghi lại đầy đủ thì coi như chưa từng tìm ra.

Debrief Và Tổng Hợp Kết Quả Với AI Sau Buổi Kiểm Thử Thế Nào?

Session kết thúc không có nghĩa là công việc kết thúc. Note thô trong 90 phút thường lộn xộn, viết tắt, thiếu ngữ cảnh cho người không có mặt lúc test. Đây là lúc AI phát huy giá trị thứ hai: biến note hiện trường thành tài liệu người khác đọc hiểu được.

Bước 1: Dán Toàn Bộ Session Notes Vào AI

Lan copy toàn bộ file note (bao gồm cả timestamp, cả những dòng PASS, cả suy nghĩ dở dang) dán vào AI với prompt:

Below is my raw exploratory testing session notes for "Resume Playback
Across Devices" (90-minute session, charter attached above). Synthesize
this into:
1. A list of distinct bugs found, each with: title, severity guess,
   steps to reproduce, device/network conditions, root cause hypothesis
   if determinable from notes.
2. Coverage summary against the original charter's 5 risk areas
   (fully covered / partially covered / not covered).
3. Open questions that need dev/PM input before filing tickets.

[paste raw notes here]

Bước 2: Rà Soát Và Xác Thực Bản Tổng Hợp

AI trả về một bản tổng hợp có cấu trúc — nhưng Lan không chấp nhận nguyên văn. Cô đọc kỹ từng mục, đối chiếu với note gốc và với ký ức thực tế của mình, vì AI có thể suy diễn quá xa từ note ngắn gọn (ví dụ AI ghi "root cause: network timeout" cho bug #2 trong khi thực tế Lan đã tự tay cách ly và xác định là lỗi cache client-side — AI không có mặt lúc Lan làm thí nghiệm cách ly biến, chỉ đọc lại note). Lan sửa lại phần root cause cho đúng, và bỏ một "bug" AI liệt kê nhưng thực ra là quan sát PASS bị AI hiểu lầm do note viết tắt mơ hồ.

Mẹo: Luôn coi bản tổng hợp của AI là bản thảo (draft), không phải bản final — đặc biệt phần "root cause hypothesis". AI tổng hợp dựa trên câu chữ trong note, không có trải nghiệm giác quan (nhìn màn hình giật, cảm nhận độ trễ) mà chỉ người trực tiếp test mới có; luôn để người test là người chốt câu chữ cuối cùng về nguyên nhân.

Bước 3: Tạo Debrief Document

Sau khi validate, Lan yêu cầu AI format lại thành debrief document gửi cho team — dev, PM, và QA lead:

Format the validated findings into a debrief document with sections:
Executive Summary (3 sentences max), Bugs Found (table), Coverage Map,
Recommendations for Next Session, Automation Candidates. Keep tone
factual, no speculation beyond what's marked as hypothesis.

Kết quả (rút gọn phần bảng bug để minh họa cấu trúc):

Bước 4: File Bug Report

Từ bảng trên, Lan yêu cầu AI soạn nội dung ticket chi tiết cho từng bug (theo template Jira của team: Summary, Steps to Reproduce, Expected/Actual, Environment, Severity, Evidence link), rồi tự tay đính kèm video quay màn hình đã chuẩn bị từ trước, và tự điền lại phần Severity theo đánh giá nghiệp vụ của mình (AI đề xuất severity dựa trên mô tả kỹ thuật, nhưng đánh giá tác động kinh doanh — ví dụ bug #2 ảnh hưởng đến uy tín "app nhớ đúng vị trí xem" là lời hứa cốt lõi của tính năng — cần con người có hiểu biết sản phẩm quyết định).

Bước 5: Cập Nhật Coverage Map

Cuối cùng, Lan cập nhật coverage map dài hạn (không chỉ của session này) — một bảng theo dõi qua nhiều session để biết vùng nào của tính năng đã được khám phá kỹ, vùng nào còn mù:

RESUME PLAYBACK — CUMULATIVE COVERAGE MAP (update after session 3)
1. Network resilience during sync       — Đã khám phá kỹ (2 sessions)
2. Cross-device state consistency       — Khám phá một phần
3. Background/foreground lifecycle      — Khám phá một phần
4. CTV-specific input/remote quirks     — Khám phá một phần (mới, giàu bug)
5. Concurrent playback hai thiết bị     — CHƯA khám phá — nghi vấn liên quan bug #2

Mẹo: Duy trì coverage map như một tài liệu sống qua nhiều session, không phải file dùng một lần rồi bỏ — đây là thứ giúp bạn (và cả người quản lý QA) trả lời câu hỏi "chúng ta đã test kỹ tính năng này chưa, hay chỉ mới test những gì dễ nghĩ tới" mà không cần nhớ lại từng buổi test rời rạc.

Buổi Kiểm Thử Khám Phá Có AI Đồng Hành Nên Tạo Ra Những Actionable Outputs Nào?

Một buổi exploratory testing giỏi nhưng không tạo ra output rõ ràng thì giá trị chỉ nằm trong đầu người test — mất đi ngay khi họ nghỉ phép hoặc chuyển team. Phần này chốt lại: sau khi buổi kiểm thử của Lan kết thúc, cái gì phải nằm trên bàn, ai đọc, và dùng để làm gì.

Bộ Artifact Cần Có

Soạn Risk Memo

Không phải ai đọc kết quả session cũng quan tâm chi tiết kỹ thuật "cache invalidation on foreground". PM và stakeholder cần bản dịch sang rủi ro kinh doanh. Lan dùng prompt:

Translate the bug findings below into a one-page risk memo for a
non-technical product stakeholder. Focus on: what could go wrong for
real users, how likely/severe, and what decision we're asking them to
make (e.g. delay launch, ship with known issue, prioritize fix order).
Avoid technical jargon like "cache invalidation" — describe user impact
instead.

[paste bug table]

AI trả về bản diễn giải kiểu: "Bug #2 nghĩa là: nếu người dùng chuyển từ điện thoại sang TV ngay lập tức (trong vài giây) khi mạng chậm, họ có thể bị đưa về một điểm xem cũ hơn thực tế tới gần 1 phút, mà không có bất kỳ cảnh báo nào — với một tính năng mà lời hứa cốt lõi là 'nhớ đúng vị trí bạn đang xem', đây là rủi ro trực tiếp đến lòng tin người dùng, dù tần suất xảy ra chỉ trong tình huống chuyển thiết bị gấp gáp." Lan review lại, chỉnh vài từ cho khớp văn hóa công ty, rồi gửi.

Soạn Charter Cho Session Tiếp Theo

Risk area 5 (concurrent playback) chưa được test và risk area 2, 3 mới "khám phá một phần" — đây là input để sinh charter cho session kế tiếp, không phải bắt đầu lại từ đầu:

Based on this session's findings and the updated coverage map, draft a
charter for the NEXT 60-minute session. Prioritize risk area 5
(concurrent playback) given its suspected shared root cause with bug #2,
and include a deliberate regression check once bug #2's fix ships.

Automation Backlog

Không phải mọi bug tìm được qua exploratory testing nên ở lại dạng "chỉ test tay mãi mãi". Lan rà lại 4 bug và hỏi AI đâu là ứng viên tốt để viết script tự động hồi quy:

Of these 4 bugs, which are good candidates for automated regression
tests (stable repro steps, deterministic conditions) versus which should
stay as manual exploratory checks (because they depend on human judgment
or non-deterministic timing)? Explain the reasoning for each.

AI phân loại: bug #2 và #3 có điều kiện lặp lại xác định (delay endpoint cụ thể, spam key với tốc độ cụ thể) — phù hợp viết script. Bug #4 (focus mặc định trên voice remote) và bug #1 (race seek/kill trong 2 giây) phụ thuộc timing tinh vi và loại thiết bị remote thực tế — Lan quyết định giữ ở dạng checklist thủ công định kỳ, vì tự động hóa timing-sensitive UI focus trên nhiều loại remote thực tế sẽ tốn công hơn giá trị thu lại.

Truyền Đạt Giá Trị Session Theo Thời Gian

Một buổi test không tự chứng minh giá trị — quản lý và stakeholder cần thấy pattern theo thời gian, không chỉ một bug report đơn lẻ. Sau vài session, Lan duy trì một bảng ngắn gửi hàng tháng cho QA lead:

Session date | Feature | Bugs found | Severity cao | Giờ đầu tư | Est. giờ automation tiết kiệm nếu không có session

Đây không phải để "khoe thành tích" mà để trả lời câu hỏi quản lý luôn hỏi ngầm: exploratory testing có AI hỗ trợ có đáng thời gian bỏ ra không, so với chỉ chạy automation suite? Với case VivuTV ở trên: 90 phút, 4 bug, trong đó 1 bug mức Cao ảnh hưởng trực tiếp lời hứa sản phẩm — nếu không có session này, khả năng cao bug #2 chỉ lộ ra sau khi khách hàng thật complain, tốn kém hơn nhiều so với 90 phút của một buổi test.

Mẹo: Khi báo cáo giá trị exploratory testing lên quản lý, đừng chỉ đếm số bug — gắn kèm mức độ nghiêm trọng và kịch bản "nếu không tìm ra sớm thì hậu quả gì". Một session tìm ra 1 bug nghiêm trọng như "silent data staleness" ảnh hưởng lời hứa cốt lõi sản phẩm có giá trị hơn nhiều session tìm ra 10 bug cosmetic nhỏ — và con số thô "4 bugs/session" một mình không nói lên điều đó.