Tiếng Việt: AI as an exploratory testing partner

Nếu automation là cách bạn hỏi hệ thống những câu bạn đã biết câu trả lời, thì exploratory testing (kiểm thử khám phá) là cách bạn hỏi hệ thống những câu bạn chưa biết câu trả lời. Đó là lý do sau hơn một thập kỷ automation-first, exploratory testing vẫn không biến mất — ngược lại, nó càng trở nên quan trọng khi tốc độ release tăng lên và automation chỉ bảo vệ được những gì đã được viết thành test case.

Vấn đề là: exploratory testing tốn nhiều năng lượng nhận thức (cognitive load) hơn bất kỳ hình thức test nào khác. Bạn phải vừa thực thi (execute), vừa quan sát (observe), vừa thiết kế test case tiếp theo trong đầu (design), vừa ghi chú lại (document) — cùng một lúc, liên tục, trong suốt một session có thể kéo dài 60-90 phút. Đây chính xác là loại công việc mà một AI/LLM assistant có thể gánh đỡ một phần, không phải bằng cách "test thay bạn", mà bằng cách trở thành một cặp não thứ hai (second brain) — giúp bạn scope session, gợi mở heuristic, và giữ track suy nghĩ khi bạn đang bận tay với sản phẩm.

Bài này không dạy lại exploratory testing là gì từ đầu — tôi giả định bạn đã từng chạy session, từng dùng charter, từng nghe qua SFDPOT hoặc CRUD heuristic. Thứ tôi muốn chia sẻ là cách biến AI thành một session partner thực sự: từ lúc lên kế hoạch, đến lúc áp dụng heuristic để không bỏ sót vùng nào, đến lúc ngồi test trực tiếp và cần một người "nói chuyện" cùng để không bị cạn ý tưởng.

Exploratory Testing Là Gì và AI Tạo Giá Trị Nhiều Nhất Ở Đâu?

Exploratory testing, theo định nghĩa của James Bach và Cem Kaner mà hầu hết QA senior đều đã thuộc, là kiểu test mà việc thiết kế test (test design), thực thi test (test execution), và học hỏi (learning) diễn ra đồng thời và liên tục nuôi lẫn nhau — thay vì tách biệt như trong scripted testing. Bạn không chạy theo một test case đã viết sẵn từ tuần trước; bạn chạy theo những gì màn hình vừa cho bạn thấy.

Điều tôi muốn làm rõ ngay từ đầu: AI không "làm exploratory testing" theo đúng nghĩa, vì bản chất exploratory testing cần một người có khả năng cảm nhận trực giác (tacit knowledge), phát hiện những thứ "trông có vẻ sai" mà không giải thích được ngay lý do. Đó là năng lực con người. Nhưng vòng lặp design → execute → learn ấy có rất nhiều điểm chèn (insertion points) mà một AI assistant biết ngữ cảnh (context) sản phẩm có thể tăng tốc đáng kể.

Điểm Nghẽn Thật Sự Trong Exploratory Testing

Tôi từng dẫn dắt một team QA 6 người làm exploratory testing cho một module thanh toán trong ứng dụng fintech. Điểm nghẽn không nằm ở việc "không biết test gì" — tester giỏi luôn có ý tưởng. Điểm nghẽn nằm ở ba chỗ cụ thể:

1. Thời gian ramp-up context: Mỗi session mới, tester phải đọc lại spec, đọc code liên quan (nếu có quyền), hiểu luồng nghiệp vụ, rồi mới bắt đầu nghĩ test idea. Việc này chiếm 30-40% thời gian của một session 90 phút.
2. Coverage blind spot: Khi đang tập trung cao độ vào một luồng (ví dụ: đổi phương thức thanh toán), tester dễ quên các heuristic dimension khác (security, performance, tương tác với module khác) vì não chỉ tập trung được một hướng tại một thời điểm.
3. Session documentation drag: Ghi chú lại những gì đã test, note lại bug, note lại ý tưởng chưa kịp thử — việc này giật gián đoạn dòng chảy tư duy (flow) liên tục.

AI giải quyết trực tiếp cả ba điểm này: nó đọc và tóm tắt context nhanh hơn con người, nó không bị "cognitive tunnel vision" nên có thể nhắc bạn những dimension bạn đang bỏ quên, và nó có thể ghi chú song song trong lúc bạn tập trung thao tác trên sản phẩm.

AI Tạo Giá Trị Ở Từng Giai Đoạn Như Thế Nào

Tôi chia một session exploratory testing thành 4 giai đoạn, và AI đóng vai trò khác nhau ở từng giai đoạn:

Những Gì AI Không Thay Thế Được Con Người

Cần nói thẳng: có ba năng lực mà AI hiện tại (và trong tương lai gần) không thay thế được trong exploratory testing.

Thứ nhất là oracle judgment — khả năng nhận ra "cái này trông sai" dựa trên trải nghiệm domain tích lũy qua nhiều năm, kể cả khi không có spec nào nói rõ đúng/sai. AI chỉ biết dựa trên văn bản đưa vào, nó không có trực giác về UX "cảm thấy chậm" hay animation "giật giật hơi khó chịu".

Thứ hai là tương tác trực tiếp với sản phẩm thật. Trừ khi bạn dùng AI agent có khả năng điều khiển browser/device (một chủ đề riêng, không phải trọng tâm bài này), AI text-based không tự bấm nút, không tự cảm nhận độ trễ, không tự thấy màu sắc bị lệch trên thiết bị thật.

Thứ ba là quyết định về rủi ro kinh doanh — việc gì đáng test kỹ, việc gì có thể bỏ qua vì rủi ro thấp, đây là quyết định cần hiểu ngữ cảnh kinh doanh, chính trị nội bộ, deadline, mà AI không có đủ thông tin (và không nên là người quyết định cuối).

Mẹo: Đừng giao cho AI vai trò "người phát hiện bug" — hãy giao vai trò "người mở rộng góc nhìn của bạn". Câu hỏi bạn nên hỏi AI không phải là "sản phẩm này có bug gì" (nó sẽ đoán và bịa), mà là "tôi đang test theo hướng X, có hướng nào tôi đang bỏ sót không". Cách đặt câu hỏi này giữ đúng vai trò cộng sự tư duy, tránh AI hallucination về bug không tồn tại.

Cách Dùng AI Để Lên Kế Hoạch và Xác Định Phạm Vi (Scope) Session Exploratory Testing?

Một session exploratory testing tốt luôn bắt đầu bằng một charter — một câu mô tả ngắn gọn "session này khám phá cái gì, với mục tiêu gì, trong khoảng thời gian nào". Charter mơ hồ ("test module thanh toán") dẫn đến session lan man; charter quá hẹp ("test nút Save có màu đúng không") thì lãng phí thời gian của một kỹ thuật vốn sinh ra để tìm cái bất ngờ.

AI đặc biệt hữu ích ở giai đoạn này vì việc soạn charter tốt đòi hỏi tổng hợp nhiều nguồn thông tin nhanh — điều LLM làm rất nhanh nếu bạn cho nó đủ input.

Các Input Thông Tin Cần Có Để Lên Kế Hoạch Session

Trước khi prompt AI, hãy chuẩn bị sẵn các input sau (copy-paste vào context, hoặc đính kèm file nếu tool của bạn hỗ trợ):

• Feature spec / PRD — mô tả nghiệp vụ, acceptance criteria nếu có.
• Ticket liên quan — bug cũ, feature request, ghi chú từ PM.
• Diff code hoặc PR description (nếu bạn có quyền truy cập) — giúp AI biết chính xác cái gì vừa thay đổi, tránh test tràn lan vào vùng không đổi.
• Kiến trúc hệ thống liên quan — ví dụ module này gọi tới service nào, có tích hợp bên thứ ba nào (payment gateway, SMS OTP...).
• Lịch sử bug của module tương tự — giúp AI ưu tiên vùng rủi ro cao.

Không có tất cả cũng không sao — nhưng có nhiều hơn thì charter và test idea được sinh ra sẽ cụ thể hơn nhiều, ít generic hơn.

Prompt Pattern: Session Scoping from a Feature Spec

Đây là prompt pattern tôi dùng thực tế khi lên charter cho một session mới. Cấu trúc gồm 4 phần: vai trò AI đóng, input, ràng buộc (constraint) thời gian/scope, và format output mong muốn.

You are an experienced exploratory testing coach helping me scope a test session.

CONTEXT:
- Feature: [paste feature spec / PRD summary here]
- What changed: [paste PR description or ticket summary]
- Related components: [list services/modules touched]
- Known risk areas: [paste any known bug history or fragile areas]

TASK:
Based on the context above, propose 5-8 exploratory testing charters for a
90-minute session block. Each charter must follow this format:

  Charter: Explore [target] with [resources] to discover [information/risk]

For each charter, also include:
- Estimated time (15/30/45/60 min)
- Priority (High/Medium/Low) based on risk and change surface
- One sentence on WHY this charter matters given the context

Group charters by testing mission (e.g., functional correctness, edge cases,
integration risk, negative/error handling). Do not propose charters for areas
that are clearly unchanged unless there's a strong regression risk rationale.

Một Output Scoping Tốt Do AI Hỗ Trợ Trông Như Thế Nào

Với một feature ví dụ "cho phép người dùng đổi phương thức thanh toán mặc định trong app", một output tốt từ prompt trên trông như thế này (rút gọn, minh họa):

Mission: Functional correctness
1. Charter: Explore switching default payment method between two valid
   saved cards to discover if the new default is correctly persisted
   and reflected across checkout flows.
   - Time: 30 min | Priority: High
   - Why: This is the core happy path and the most common user action.

Mission: Edge cases / boundary
2. Charter: Explore changing default payment method when the currently
   selected card is expired or has been flagged by the issuer to
   discover how the system handles invalid-state transitions.
   - Time: 20 min | Priority: High
   - Why: Card expiry during the update window is a realistic race
     condition not explicitly covered in the spec's acceptance criteria.

Mission: Integration risk
3. Charter: Explore the interaction between default payment method
   update and any in-flight subscription renewal to discover whether
   a renewal triggered mid-update uses the old or new default.
   - Time: 25 min | Priority: Medium
   - Why: PR touches the billing service; subscription renewal timing
     is a known fragile area per past incident history.

Điểm đáng chú ý: charter số 2 và 3 là những thứ một tester bận rộn dễ bỏ qua khi chỉ nhìn spec, vì spec thường chỉ mô tả happy path. AI, khi được cho đủ context về "known risk areas", có xu hướng lôi những case biên ra khá tốt — vì nó không bị thiên lệch bởi cách PM viết acceptance criteria.

Lặp Lại Để Tinh Chỉnh Scope Trong Lúc Lên Kế Hoạch

Đừng dừng ở output đầu tiên. Sau khi AI đề xuất charter, hãy phản hồi lại như bạn đang brainstorm với một đồng nghiệp:

Charter #3 is interesting but too broad for 25 minutes. Split it into
two more focused charters: one specifically about subscription renewal
timing, and one about refund/rollback behavior if the update fails
mid-transaction.

Vòng lặp phản hồi này — đề xuất, thu hẹp, đề xuất lại — thường chỉ tốn 3-5 phút nhưng tiết kiệm được rất nhiều thời gian "test lan man không biết dừng ở đâu" trong session thật.

Mẹo: Luôn yêu cầu AI giải thích "Why" cho từng charter. Nếu AI không đưa ra được lý do thuyết phục (chỉ nói chung như "để đảm bảo chất lượng"), đó là dấu hiệu charter đó là generic filler, không dựa trên context thật — bạn nên loại bỏ hoặc yêu cầu AI đào sâu hơn.

Cách Áp Dụng Testing Heuristic Như SFDPOT Với Sự Hỗ Trợ Của AI?

SFDPOT (Structure, Function, Data, Platform, Operations, Time) là một trong những heuristic coverage phổ biến nhất trong exploratory testing, cùng với các biến thể như FCC CUTS VIDS. Vấn đề thực tế không phải là "không biết heuristic" — hầu hết QA senior đọc qua Rapid Software Testing đều biết SFDPOT. Vấn đề là áp dụng nhất quán heuristic này cho một feature cụ thể, dưới áp lực thời gian, mà không rơi vào việc chỉ lặp lại checklist một cách hình thức.

Đây là chỗ AI tỏ ra hữu dụng rõ rệt: nó không mệt, không quên dimension nào, và có thể sinh ra một ma trận coverage (coverage matrix) cụ thể cho feature của bạn trong vài giây — thứ mà làm tay có thể tốn 20-30 phút brainstorm.

Ôn Lại SFDPOT (Như Một Lăng Kính Coverage, Không Phải Giới Thiệu Từ Đầu)

Nhắc lại ngắn để đồng bộ thuật ngữ trước khi vào ví dụ — không phải introduction từ đầu:

• Structure — cấu trúc code/UI/kiến trúc: những gì tạo nên sản phẩm (component, module, API, database schema).
• Function — sản phẩm làm được gì: các business logic, tính năng.
• Data — dữ liệu đi vào/ra: input, output, storage, format, encoding, giới hạn kích thước.
• Platform — mọi thứ sản phẩm phụ thuộc vào bên ngoài: OS, browser, device, network, phần cứng.
• Operations — cách người dùng thật sự sử dụng: use case thực tế, hành vi bất thường, thao tác song song.
• Time — yếu tố thời gian: timeout, timezone, đồng bộ hóa, race condition, thời điểm trong ngày/tháng.

Prompt Pattern: Generating SFDPOT Coverage Matrix for a Feature

You are a senior test strategist. Using the SFDPOT heuristic (Structure,
Function, Data, Platform, Operations, Time), generate a coverage matrix
for the following feature:

FEATURE: [paste feature description]
CONTEXT: [paste any relevant technical detail, e.g. tech stack,
integrations, known constraints]

For EACH SFDPOT dimension, list 3-5 concrete, specific test ideas
(not generic statements). Each idea must be phrased as a testable
question or scenario, not a vague category. Format as a markdown table
with columns: Dimension | Test Idea | Rationale (why this matters for
THIS feature specifically).

Avoid generic filler like "test on different browsers" — be specific to
the actual feature and its stated risks.

Chi tiết quan trọng trong prompt: câu "Avoid generic filler" là bắt buộc phải có. Nếu không nhắc, AI có xu hướng trả lời rất chung ("test performance", "test security") — những câu đúng về mặt heuristic nhưng vô dụng về mặt hành động cụ thể.

Ví Dụ Thực Tế: SFDPOT Cho Luồng Đổi Phương Thức Thanh Toán

Lấy tiếp ví dụ "đổi phương thức thanh toán mặc định" ở trên, đây là coverage matrix thực tế mà tôi dựng ra khi áp dụng prompt pattern này (đã rút gọn để vừa khuôn bài, session thật thường có nhiều hơn):

Nhìn vào bảng này, bạn sẽ thấy rõ giá trị: nếu chỉ brainstorm một mình trong lúc bận, dimension "Time" và "Operations" (concurrency) là hai dimension dễ bị bỏ quên nhất — vì chúng không nằm trong tư duy "click và xem kết quả" tự nhiên của con người khi test manual.

Dùng AI Để Mở Rộng Một Dimension Heuristic Cụ Thể Giữa Session

Trong lúc đang chạy session thật, nếu bạn cảm thấy một dimension cụ thể cần đào sâu hơn (ví dụ vừa phát hiện có vẻ có race condition ở Operations), bạn không cần quay lại toàn bộ ma trận — chỉ cần prompt nhắm đúng dimension:

I just observed that clicking "Save" twice quickly on the payment
method update button seems to trigger two API calls. Expand ONLY the
Operations dimension with 5 more test ideas specifically probing
concurrency and rapid repeated user actions for this feature.

Cách prompt hẹp và có ngữ cảnh quan sát thực tế (không phải giả định) này giúp AI sinh ra ý tưởng bám sát vấn đề thật, thay vì lặp lại ý tưởng chung đã có trong ma trận ban đầu.

Ngoài SFDPOT: Các Heuristic Khác AI Có Thể Áp Dụng

SFDPOT không phải heuristic duy nhất, và một cộng sự AI tốt nên được yêu cầu áp dụng heuristic khác tùy tình huống:

Mẹo: Đừng chỉ dùng một heuristic cho mọi session. Luân phiên giữa SFDPOT, CRUD, và Error Guessing theo từng loại feature — AI áp dụng heuristic nào cũng nhanh như nhau, nên chi phí "thử heuristic khác xem có ra ý tưởng mới không" gần như bằng không. Nếu ma trận SFDPOT đã cạn ý tưởng mới, thử ngay Error Guessing dựa trên bug log cũ, thường ra được góc nhìn khác hẳn.

Cách Dùng AI Như Một Cộng Sự Tư Duy Thời Gian Thực Trong Lúc Chạy Session Exploratory?

Đây là phần khác biệt nhất so với việc dùng AI để lên kế hoạch trước session: dùng AI trong lúc đang test, như một đồng nghiệp ngồi cạnh bạn, theo dõi màn hình qua lời bạn kể, và phản hồi ngay khi bạn cần một ý tưởng mới hoặc một góc nhìn khác.

Điểm mấu chốt cần hiểu: AI không nhìn thấy màn hình của bạn (trừ khi bạn dùng tool có khả năng chụp screenshot/computer-use, một use case nâng cao hơn). Trong phần lớn trường hợp thực tế, bạn đang "tường thuật" (narrate) những gì bạn thấy cho AI bằng text, và AI phản hồi dựa trên tường thuật đó. Kỹ năng tường thuật hiệu quả — súc tích, đủ thông tin, đúng lúc — chính là kỹ năng mới mà exploratory tester cần luyện khi làm việc với AI.

Thiết Lập Context Cộng Tác Thời Gian Thực

Trước khi bắt đầu session, hãy "mở" một context session riêng cho AI (một cửa sổ chat/agent session dài, không tắt giữa các charter) và seed (khởi tạo) nó với thông tin cố định để không phải lặp lại:

We are starting a live exploratory testing session.

Charter: [paste the charter for this session]
My role: I will narrate what I do and observe. You act as a thinking
partner — suggest next test ideas, flag things I might be missing,
and help me phrase bug notes clearly when I ask.

Ground rules:
- Keep responses short (2-4 sentences) unless I ask for a list.
- When I describe an observation, ask ONE clarifying question if the
  behavior seems ambiguous, otherwise suggest 1-2 follow-up test ideas.
- Do not assume something is a bug unless I say so — just flag it as
  "worth double-checking" if it seems off based on the spec.
- Track a running list of things I say I want to revisit later.

Đặt "ground rules" này ngay từ đầu quan trọng hơn bạn nghĩ — nếu không, AI có xu hướng trả lời dài dòng, làm gián đoạn flow, hoặc tự tin tuyên bố "đây là bug" dựa trên suy đoán thiếu context.

Các Kiểu Tương Tác Giữa Session

Có bốn kiểu tương tác tôi dùng lặp lại nhiều nhất trong session thật:

1. Tường thuật quan sát, xin follow-up idea:

I just changed the default payment method from Card A to Card B.
The UI updated instantly, but when I refreshed the page, it briefly
showed Card A as default for about half a second before switching
to Card B. What should I dig into next?

AI phản hồi tốt sẽ hỏi lại điều gì đó như: "Is that half-second flash consistent on every refresh, or intermittent? Also worth checking: does this happen on a slow network throttle, since it might indicate the UI is rendering cached state before the fresh API response arrives."

2. Xin biến thể input nhanh khi đang gõ:

I'm about to test the promo code field. Give me 8 input variations to
try quickly — mix of valid, boundary, and malicious-looking inputs.

3. Nhờ cấu trúc hóa bug note ngay khi vừa phát hiện:

Turn this into a bug report draft: clicked save twice fast on payment
method update, saw two POST requests in network tab, second one
returned 409 but UI still showed success toast. Chrome, staging env.

AI trả về bug report có Title, Steps to Reproduce, Expected/Actual, Severity gợi ý — bạn chỉ cần review và paste vào Jira, tiết kiệm thời gian đáng kể so với tự gõ giữa lúc đang tập trung test.

4. Xin điểm danh lại coverage khi cảm thấy "hình như tôi đang lặp":

I've spent 20 minutes on this charter, mostly around happy-path card
switching. Remind me which SFDPOT dimensions I haven't touched yet
for this charter.

Quản Lý Dòng Chảy Tư Duy — Biết Khi Nào Nên Hỏi AI

Rủi ro lớn nhất khi dùng AI real-time là nó phá vỡ flow — trạng thái tập trung sâu là thứ làm exploratory testing hiệu quả. Nguyên tắc tôi áp dụng: chỉ tương tác với AI ở các điểm chuyển tiếp tự nhiên (natural transition point) — sau khi hoàn thành một luồng thao tác, trước khi bắt đầu luồng mới, hoặc ngay khi vừa quan sát điều gì bất thường. Không tương tác AI trong khi đang thao tác nhiều bước liên tiếp trên UI — lúc đó hãy để tay và mắt tập trung hoàn toàn vào sản phẩm.

Một dấu hiệu bạn đang lạm dụng AI quá mức trong session: nếu bạn thấy mình gõ nhiều hơn là click/thao tác trên sản phẩm, bạn đã trượt từ "exploratory testing có AI hỗ trợ" sang "chat với AI về sản phẩm" — hai việc khác nhau, và chỉ việc đầu tiên tạo ra giá trị test thật.

AI Thời Gian Thực Theo Từng Chuyên Môn

Tùy loại sản phẩm, cộng sự AI phát huy giá trị khác nhau:

• API/backend-heavy feature: AI giỏi gợi ý payload biến thể, edge case về status code, và giải mã response error nhanh hơn bạn tự đọc doc.
• UI/UX-heavy feature: AI hữu ích để gợi ý accessibility check (contrast, keyboard navigation, screen reader label) mà tester thường quên vì không phải chuyên môn chính.
• Data-heavy feature (báo cáo, dashboard): AI tốt trong việc gợi ý các biến thể dataset (rỗng, một dòng, số âm, số quá lớn, ký tự đặc biệt trong tên) để test tính đúng đắn của phép tính hiển thị.
• Integration-heavy feature (gọi bên thứ ba): AI hữu ích để brainstorm failure mode của dependency (timeout, response chậm, response sai format) — những case khó test trực tiếp nhưng cần nghĩ tới trước khi báo cáo "đã test kỹ".

Mẹo: Cuối mỗi session, luôn dành 3 phút cuối cùng để hỏi AI một câu duy nhất: "Based on everything I told you in this session, what's the single riskiest thing I have NOT verified yet?" Câu hỏi này ép AI tổng hợp lại toàn bộ cuộc trò chuyện thay vì trả lời rời rạc theo từng lúc, và thường bật ra đúng một gap quan trọng mà cả bạn và AI đều thấy hợp lý để đưa vào charter cho session tiếp theo.