Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa hoàn thành một bộ 300 test case tự động cho ứng dụng ví điện tử. Tất cả đều xanh (pass). Bạn tự tin báo cáo "app ổn định, sẵn sàng release". Nhưng ngay tối hôm đó, một người dùng thật ở Đà Nẵng mở app trong lúc đang gọi điện, xoay ngang màn hình để chụp mã QR, rồi bị gián đoạn bởi một cuộc gọi đến — và app crash trắng màn hình. Không có test case nào của bạn miss được lỗi đó, vì đơn giản: không ai từng nghĩ tới kịch bản "vừa gọi điện vừa xoay màn hình vừa chụp QR".
Đây chính là lỗ hổng mà Exploratory Testing (kiểm thử thăm dò) được sinh ra để lấp. Scripted test — dù automation hay manual theo test case cố định — chỉ kiểm được những gì bạn đã nghĩ ra trước. Nhưng bug nguy hiểm nhất thường nằm ở những nơi bạn chưa từng nghĩ tới. Trên mobile, không gian "chưa nghĩ tới" này khổng lồ: hàng nghìn tổ hợp thiết bị, gián đoạn hệ thống (cuộc gọi, thông báo, hết pin), thao tác chạm phi tuyến tính, và người dùng thật luôn dùng app theo cách "không đúng sách".
Với vai trò QA mobile, exploratory testing không phải là "test lung tung cho vui". Nó là một kỹ năng có kỷ luật, có cấu trúc, có thể đo lường và báo cáo được — và Charter cùng Session là hai công cụ biến nó từ "mò mẫm ngẫu hứng" thành một hoạt động chuyên nghiệp. Bài này sẽ dạy bạn cách làm đúng.
Khái niệm cốt lõi
Exploratory Testing là gì (và không phải là gì)
Exploratory Testing là phương pháp kiểm thử trong đó việc học về sản phẩm, thiết kế test, và thực thi test diễn ra đồng thời. Tester khám phá app như một người dùng thật — nhưng với con mắt của một thám tử săn lỗi. Bạn quan sát hành vi, đặt giả thuyết ("điều gì xảy ra nếu...?"), thử nghiệm ngay lập tức, rồi điều chỉnh hướng dựa trên những gì vừa phát hiện.
Điểm mấu chốt phân biệt nó với scripted testing:
- Scripted test: viết trước → thực thi sau. Bạn biết chính xác từng bước và kết quả mong đợi. Tốt cho regression, cho tự động hóa, cho việc lặp lại.
- Exploratory test: thiết kế và thực thi cùng lúc. Bạn dùng trực giác + kinh nghiệm để đi theo "mùi bug" (bug scent).
Charter — la bàn cho một phiên thăm dò
Charter là một bản hướng dẫn ngắn gọn, thường chỉ 1–3 dòng, xác định mục tiêu và phạm vi của một phiên exploratory. Nó trả lời: phiên này khám phá cái gì, dùng công cụ/dữ liệu gì, và tìm loại thông tin gì.
Công thức charter kinh điển (theo James Bach & Elisabeth Hendrickson):
> Explore (khám phá khu vực nào) with (dùng nguồn lực/công cụ/dữ liệu gì) to discover (tìm loại thông tin/rủi ro gì)
Ví dụ charter cho một app giao đồ ăn:
> Explore luồng đặt món khi mạng chập chờn with Network Link Conditioner ở chế độ 3G kém + đơn hàng có 15 món to discover các lỗi mất dữ liệu giỏ hàng, double-charge, hoặc UI treo.
Charter tốt phải đủ hẹp để tập trung nhưng đủ rộng để còn chỗ khám phá. "Test toàn bộ app" là charter tồi (quá rộng). "Bấm nút Đặt hàng" là charter tồi (quá hẹp, chẳng khác gì test case). Charter tốt nằm ở giữa.
Session — đơn vị công việc có time-box
Session là một khoảng thời gian tập trung, không gián đoạn, thường 60–120 phút, dành để thực thi một (hoặc một nhóm) charter. Đây là khái niệm từ Session-Based Test Management (SBTM) — khung quản lý giúp exploratory testing trở nên đo đếm được.
Một session điển hình chia thời gian thành ba loại hoạt động (tỷ lệ TBS — Test/Bug/Setup):
- Test (T): thời gian thực sự khám phá và tìm bug.
- Bug (B): thời gian điều tra và ghi nhận bug đã tìm thấy.
- Setup (S): thời gian chuẩn bị (cài build, cấu hình thiết bị, tạo dữ liệu).
Heuristics — bộ công cụ tư duy để không bị "cạn ý"
Khó khăn lớn nhất của người mới làm exploratory là ngồi trước app 10 phút rồi... hết biết thử gì. Heuristics là các "gợi ý tư duy" giúp bạn luôn có hướng đi. Vài heuristic đặc biệt hợp với mobile:
- SFDIPOT / San Francisco Depot (Structure, Function, Data, Interfaces, Platform, Operations, Time): quét app qua 7 lăng kính.
- CRUD: với mỗi thực thể dữ liệu, thử Create – Read – Update – Delete.
- Goldilocks: thử giá trị quá nhỏ, quá lớn, và vừa đủ (ví dụ: tên 0 ký tự, tên 5000 ký tự).
- Interruptions (rất quan trọng trên mobile): cuộc gọi đến, thông báo, hết pin, khóa màn hình, chuyển app nền, xoay màn hình giữa chừng.
Tình huống thực tế
Ví dụ 1 — Ví điện tử MoMo giả định: bug "double-charge" khi mạng lag
Một đội QA tại một fintech ở TP.HCM (giả định dựa trên bối cảnh ví điện tử Việt Nam) chuẩn bị release tính năng thanh toán hóa đơn điện. Bộ automation 240 test case đều pass. QA lead quyết định thêm một session exploratory 90 phút với charter:
> Explore luồng thanh toán hóa đơn with mạng bị bóp còn 2G + thao tác bấm nút nhanh liên tục to discover lỗi giao dịch trùng và trạng thái UI không nhất quán.
Trong session, tester dùng Network Link Conditioner đặt độ trễ 3000ms, bấm nút "Thanh toán" rồi — vì màn hình chưa phản hồi — bấm thêm lần nữa (đúng như người dùng thật hay làm khi thấy app "đơ"). Kết quả: hệ thống ghi nhận 2 giao dịch trừ tiền cho cùng một hóa đơn. Bug này automation không bắt được vì test case luôn "bấm 1 lần rồi chờ đúng cách".
Bài học: chỉ 90 phút exploratory đã bắt được một lỗi có thể gây thiệt hại tài chính thật và khủng hoảng niềm tin người dùng — điều mà 240 test case "ngoan ngoãn" bỏ lọt. Nút cần có debounce + idempotency key, và team bổ sung một test case tự động mới cho kịch bản này.
Ví dụ 2 — App gọi xe Grab-style: crash khi gián đoạn giữa chừng
Một tester tại một startup gọi xe ở Đông Nam Á nhận charter khám phá theo heuristic Interruptions:
> Explore màn hình chọn điểm đến with các gián đoạn hệ thống (cuộc gọi đến, chuyển app, xoay màn hình) to discover mất trạng thái và crash.
Trong session 60 phút, tester đang nhập địa chỉ "123 Nguyễn Huệ" thì cố tình để một cuộc gọi đến, nhận cuộc gọi 5 giây, rồi quay lại app. App mất toàn bộ text đã nhập và reset về vị trí GPS mặc định. Chưa dừng lại, tester xoay ngang màn hình đúng lúc bản đồ đang load → app crash. Session sheet ghi 2 bug, kèm video màn hình và bước tái tạo.
Bài học: heuristic Interruptions là "mỏ vàng" bug trên mobile vì đó là bản chất của thiết bị di động — người dùng luôn bị ngắt quãng. Đây là khu vực automation rất khó phủ và thường bị bỏ quên trong test plan.
Ví dụ 3 — App học tiếng Anh: bug tiếng Việt trong exploratory không định hướng đúng
Một đội QA ở Hà Nội chạy exploratory nhưng mắc lỗi phổ biến: không có charter, ba tester cùng "test tự do" trong 3 giờ. Kết quả: cả ba đều tập trung vào màn hình đăng nhập (vì đó là thứ đầu tiên thấy), báo cáo trùng lặp 5 bug giống nhau, trong khi màn hình thanh toán gói học — khu vực rủi ro cao nhất — không ai chạm tới.
Lần sau, QA lead áp dụng SBTM: chia 4 charter riêng biệt (đăng nhập, học bài, thanh toán, hồ sơ), mỗi tester một charter, time-box 75 phút, debrief cuối buổi. Cùng 3 giờ đó, đội phủ được cả 4 khu vực và tìm ra một bug nghiêm trọng: nhập tên có dấu tiếng Việt "Nguyễn" vào ô coupon làm API trả lỗi 500.
Bài học: exploratory không có charter dễ biến thành "cả đội xúm vào một góc". Charter phân bổ giúp phủ rủi ro có chủ đích, không lãng phí và không trùng lặp.
Hướng dẫn từng bước
Đây là quy trình để bạn tự chạy một session exploratory chuyên nghiệp:
Bước 1 — Xác định vùng rủi ro và viết charter. Nhìn vào tính năng mới hoặc khu vực dễ vỡ, hỏi "chỗ nào đau nhất nếu lỗi?". Viết charter theo công thức Explore/With/To discover. Với sprint, hãy liệt kê 4–6 charter và ưu tiên theo rủi ro.
Bước 2 — Chuẩn bị setup và time-box. Cài đúng build, chọn thiết bị (ưu tiên real device cho exploratory vì cảm giác chạm và gián đoạn thật hơn emulator), chuẩn bị dữ liệu test. Đặt đồng hồ 60 hoặc 90 phút. Tắt Slack, để điện thoại chế độ không làm phiền — session cần sự tập trung liên tục.
Bước 3 — Khám phá theo heuristic, ghi chép song song. Bắt đầu đi theo charter. Khi bí ý, rút một heuristic ra (Interruptions, Goldilocks, CRUD...). Ghi lại mọi thứ: bạn thử gì, thấy gì, câu hỏi nảy ra. Dùng công cụ ghi màn hình (built-in screen recorder của iOS/Android) chạy nền suốt session — cực kỳ quý khi cần tái tạo bug.
Bước 4 — Điều tra bug ngay khi gặp. Thấy hành vi lạ, dừng lại xác định: nó tái tạo được không? Cần bước nào? Chụp screenshot/quay video, ghi device + OS version + build number. Nhưng đừng để đào một bug làm bạn quên charter — ghi lại rồi tiếp tục.
Bước 5 — Viết session sheet và debrief. Kết thúc time-box, tổng kết: charter, thời lượng, tỷ lệ T/B/S, danh sách bug, khu vực đã phủ, khu vực còn nợ (để sinh charter cho lần sau), và các câu hỏi mở cho dev/PM. Debrief 5–10 phút với lead để chia sẻ và định hướng tiếp.
Lỗi thường gặp & mẹo
- Nhầm exploratory với "test không cần chuẩn bị": nhiều người nghĩ exploratory là lười, không cần plan. Sai. Nó cần chuẩn bị tư duy (charter, heuristic) nhiều hơn scripted.
- Charter quá rộng hoặc quá hẹp: "test app" thì mất phương hướng; "bấm nút X" thì thành test case. Luyện viết charter vừa tầm là kỹ năng cần thời gian.
- Không time-box: session kéo dài 4 tiếng khiến bạn mệt, chất lượng quan sát giảm mạnh sau ~90 phút. Nghỉ giữa các session.
- Không ghi chép: tìm được bug nhưng không nhớ bước tái tạo = bug vô dụng với dev. Luôn bật screen recorder.
- Mẹo mobile: giữ sẵn một "danh sách gián đoạn" dán trên bàn (cuộc gọi, thông báo, hết pin, xoay màn hình, chuyển app nền, mất mạng giữa chừng, thay đổi múi giờ) — đây là nguồn bug đặc thù mobile mà scripted test hay bỏ.
- Mẹo cân bằng: exploratory bổ sung chứ không thay thế automation. Bug hay lặp lại tìm bằng exploratory nên được biến thành test case tự động cho regression.
- Đừng exploratory một mình mãi: thỉnh thoảng làm pair exploratory (2 người, 1 điều khiển 1 ghi chép) — góc nhìn kép bắt bug tốt hơn nhiều.
Bài tập thực hành
- Viết charter: Chọn một app mobile bạn đang dùng (ví dụ ứng dụng ngân hàng của bạn). Viết 4 charter theo đúng công thức Explore / With / To discover, mỗi charter nhắm một vùng rủi ro khác nhau. Đảm bảo không charter nào "quá rộng" hay "quá hẹp".
- Chạy một session có time-box: Đặt đồng hồ 60 phút, chọn 1 charter ở trên, bật screen recorder, và thực sự khám phá. Trong lúc làm, ép mình dùng ít nhất 2 heuristic (bắt buộc có Interruptions). Ghi chép song song.
- Viết session sheet: Sau session, viết biên bản gồm: charter, thời lượng, ước tính tỷ lệ Test/Bug/Setup, danh sách phát hiện (kể cả "không phải bug nhưng đáng ngờ"), khu vực chưa phủ, và 2 câu hỏi bạn muốn hỏi dev/PM.
- Chuyển hóa thành automation: Chọn 1 bug (hoặc kịch bản đáng lo) bạn tìm được, và mô tả cách bạn sẽ viết một test case tự động để bắt nó trong regression sau này.
Tóm tắt
Exploratory Testing là kiểm thử trong đó việc học, thiết kế và thực thi diễn ra đồng thời — giúp bắt những bug mà scripted test và automation bỏ lọt, đặc biệt trên mobile với vô số gián đoạn và tổ hợp thiết bị. Nó không phải test tùy hứng: nó có kỷ luật thông qua Charter (bản định hướng 1–3 dòng theo công thức Explore/With/To discover) và Session (khoảng thời gian tập trung có time-box 60–120 phút, quản lý bằng SBTM với session sheet và debrief). Heuristic — nhất là Interruptions, Goldilocks, CRUD — giúp bạn luôn có hướng khám phá. Ba tình huống trong bài cho thấy exploratory bắt được double-charge khi mạng lag, crash khi bị gián đoạn, và lỗi tiếng Việt trong ô coupon — những lỗi tốn kém mà test case cố định không thấy. Hãy nhớ: exploratory bổ sung cho automation, và mọi bug lặp lại tìm được nên được biến thành test tự động. Kỷ luật + trực giác + ghi chép — đó là công thức của một QA mobile giỏi khám phá.