Mở đầu — vì sao bài này quan trọng
Nếu bạn từng nghe ai đó nói "exploratory testing chỉ là click loạn xạ, không có kế hoạch", thì bài này sẽ thay đổi hoàn toàn cách bạn nhìn nhận. Ở cấp độ cơ bản, exploratory testing (kiểm thử khám phá) thường bị hiểu lầm là kiểu "vọc thử cho vui". Nhưng ở cấp độ nâng cao — cấp độ mà một QA Lead cần làm chủ — exploratory testing là một kỹ thuật có kỷ luật cao, có thể đo lường được, có thể báo cáo cho stakeholder, và trong nhiều trường hợp còn tìm ra bug quan trọng nhanh hơn cả bộ test case scripted đã viết sẵn.
Vì sao một QA Leader lại cần bài này? Bởi vì trong thực tế, phần lớn các defect nghiêm trọng lọt ra production không nằm trong test case đã viết. Chúng nằm ở những "vùng mù" (blind spot) mà không ai nghĩ tới khi thiết kế test case. Test scripted rất giỏi kiểm tra những gì bạn đã biết cần kiểm tra, nhưng nó gần như vô dụng với những gì bạn chưa biết mình chưa biết. Đó chính là địa hạt của exploratory testing nâng cao.
Với vai trò lãnh đạo QA, thách thức lớn nhất không phải là "làm sao explore", mà là "làm sao biến hoạt động tưởng chừng ngẫu hứng này thành một quy trình có cấu trúc, có bằng chứng, có thể lên lịch, và có thể giải trình với sếp". Bài này tập trung vào các kỹ thuật nâng cao — đặc biệt là Session-Based Test Management (SBTM) — để bạn làm được đúng điều đó.
Khái niệm cốt lõi
Từ exploratory ngẫu hứng đến exploratory có kỷ luật
Exploratory testing đúng nghĩa là quá trình mà người kiểm thử đồng thời học về sản phẩm, thiết kế test, và thực thi test — cả ba diễn ra song song, không tách rời. Điều làm nên đẳng cấp "nâng cao" là bạn thêm vào đó cấu trúc quản lý để hoạt động này không bị trôi nổi.
Khác biệt cốt lõi giữa người mới và người nâng cao nằm ở ba chữ: trách nhiệm giải trình (accountability). Người mới explore xong không nói được mình đã cover cái gì, mất bao lâu, tìm được gì. Người nâng cao thì có đầy đủ bằng chứng. Đó là lý do SBTM ra đời.
Session-Based Test Management (SBTM)
SBTM được Jonathan Bach (cùng anh trai James Bach) tiên phong vào đầu những năm 2000, chính là để giải quyết bài toán "làm sao quản lý exploratory testing như một hoạt động chuyên nghiệp". Bốn trụ cột của SBTM:
1. Session — phiên kiểm thử được đóng khung thời gian (time-boxed). Một session điển hình kéo dài 60–90 phút, không bị gián đoạn. Con số này không phải ngẫu nhiên: đủ dài để đi sâu vào một vùng chức năng, nhưng đủ ngắn để giữ sự tập trung cao độ và dễ ước lượng, lên lịch. Nếu bạn bị ngắt quãng giữa chừng (họp, trả lời chat), phiên đó không còn được tính là một session "chuẩn".
2. Charter — bản giao nhiệm vụ. Charter là "mission statement" ngắn gọn định nghĩa phạm vi và mục tiêu của session. Một charter tốt thường theo mẫu: "Explore [khu vực nào] với [công cụ/dữ liệu gì] để phát hiện [loại vấn đề gì]". Ví dụ: "Explore luồng thanh toán bằng thẻ quốc tế với các mệnh giá tiền tệ khác nhau để phát hiện lỗi làm tròn và hiển thị". Charter đủ hẹp để tập trung, nhưng đủ rộng để tester tự do khám phá bên trong nó.
3. Session Report / Session Sheet — biên bản phiên. Đây là điểm biến exploratory từ "vô hình" thành "có bằng chứng". Mỗi session sinh ra một biên bản gồm: charter, người thực hiện, thời gian, các khu vực đã đụng tới, bug tìm được, câu hỏi/issue phát sinh, và ghi chú.
4. Debrief — buổi tổng kết ngắn. Sau session, tester ngồi lại với lead (thường 5–10 phút) để review biên bản. James Bach đặt tên cho quy trình debrief này là PROOF: Past (đã làm gì), Results (kết quả), Obstacles (vướng mắc gì), Outlook (còn gì cần làm), Feelings (cảm nhận về chất lượng/rủi ro khu vực đó).
Metrics của SBTM: TBS breakdown
SBTM cho phép đo lường thời gian bằng cách chia mỗi session thành ba loại hoạt động, gọi là TBS:
- T — Test design and execution: thời gian thực sự kiểm thử.
- B — Bug investigation and reporting: thời gian điều tra và ghi nhận bug (khi gặp bug thì tester phải dừng test để đào sâu).
- S — Session setup: thời gian chuẩn bị môi trường, dữ liệu, công cụ.
Các heuristic nâng cao dẫn đường cho session
Explore không có nghĩa là mò mẫm vô định. Người nâng cao dùng heuristic — các quy tắc kinh nghiệm — để định hướng. Vài heuristic kinh điển:
- SFDIPOT (San Francisco Depot) của James Bach — quét sản phẩm theo 7 khía cạnh: Structure, Function, Data, Interfaces, Platform, Operations, Time.
- CRUD — với mọi thực thể dữ liệu, thử Create/Read/Update/Delete và các tổ hợp bất thường của chúng.
- Goldilocks — thử giá trị "quá nhỏ, quá lớn, vừa đủ" (số âm, số 0, số cực lớn, chuỗi rỗng, chuỗi dài 10.000 ký tự).
- Tours (do Whittaker đề xuất) — "đi tour" sản phẩm theo các chủ đề: Money Tour (theo dấu dòng tiền), Landmark Tour (đi qua các tính năng nổi bật), Back Alley Tour (khám phá các tính năng ít dùng nhất — nơi bug hay ẩn nấp).
Tình huống thực tế
Tình huống 1: Fintech Việt Nam — session tìm ra lỗi làm tròn tiền
Một công ty fintech tại TP.HCM (giả định tên VietPay) chuẩn bị release tính năng ví đa tiền tệ. Bộ test case scripted gồm 320 case đã pass 100%, team QA tự tin release. Nhưng QA Lead quyết định chèn thêm hai session exploratory 90 phút trước ngày go-live, với charter: "Explore chuyển đổi và hiển thị số dư đa tiền tệ với các mệnh giá lẻ (VND, JPY, KWD) để phát hiện lỗi làm tròn."
Điểm mấu chốt ở đây: JPY không có phần thập phân, còn KWD (dinar Kuwait) có tới 3 chữ số thập phân, trong khi VND cũng không dùng phần lẻ. Không một test case scripted nào cover trường hợp KWD vì nó nằm ngoài "danh sách tiền tệ dự kiến" mà BA đã liệt kê. Trong session, tester dùng heuristic Goldilocks nhập số dư 1.234 KWD và phát hiện hệ thống làm tròn thành 1.23, gây thất thoát 0.004 dinar mỗi giao dịch — về lý thuyết nhỏ, nhưng với hàng chục nghìn giao dịch là con số thật.
Biên bản session ghi rõ: TBS = 55/30/5 phút (test/bug/setup), 1 bug critical, 2 câu hỏi mở về chuẩn ISO 4217. Debrief PROOF giúp lead quyết định hoãn release 3 ngày.
Bài học: Test scripted chỉ phủ những gì requirement liệt kê. Exploratory với charter đúng heuristic phủ được vùng mù mà chính requirement bỏ sót.
Tình huống 2: E-commerce — biến "vọc app" mơ hồ thành báo cáo cho CEO
Một sàn thương mại điện tử ở Đông Nam Á (giả định ShopFast) có văn hóa "test nhanh cho kịp sprint". Mỗi lần release, manager hỏi "test tới đâu rồi?" thì team chỉ trả lời chung chung "đang test, thấy ổn". CEO không tin, đội dev cũng không phục.
QA Lead mới về áp dụng SBTM. Thay vì báo cáo mơ hồ, mỗi sprint team chạy 12 session, mỗi session có charter và session sheet. Cuối sprint, lead tổng hợp: "Tuần này team đã hoàn thành 12 session (18 giờ test thuần), cover 8 khu vực chức năng, TBS trung bình 70/20/10, tìm 14 bug (3 critical). Khu vực 'checkout với voucher chồng voucher' có tỷ lệ B (bug investigation) cao bất thường 45% — đề xuất thêm session và siết review code khu vực này."
Lần đầu tiên, ban lãnh đạo nhìn thấy exploratory testing dưới dạng số liệu và bằng chứng, không còn là hoạt động "cảm tính". Niềm tin vào QA tăng vọt, và team được cấp thêm ngân sách.
Bài học: SBTM không chỉ giúp tìm bug — nó giúp exploratory testing có thể giải trình với người không làm kỹ thuật. Đây chính là kỹ năng lãnh đạo.
Tình huống 3: Startup — Back Alley Tour cứu một release
Một startup SaaS về quản lý phòng gym (giả định GymOne) có team chỉ 2 QA. Họ không đủ người viết test case đầy đủ. QA Lead dùng chiến thuật Tours: mỗi ngày một tester chạy một session theo một tour khác nhau. Đến lượt Back Alley Tour (khám phá tính năng ít dùng nhất), tester để ý tính năng "xuất báo cáo doanh thu ra Excel" — thứ mà gần như không ai test vì rất ít khách dùng.
Kết quả: khi dữ liệu có ký tự tiếng Việt có dấu trong tên hội viên, file Excel xuất ra bị lỗi encoding thành ký tự rác. Đây là loại bug nằm ngoài mọi test case, chỉ lộ ra khi có người cố tình đi vào "ngõ hẻm" của sản phẩm.
Bài học: Với team nhỏ, exploratory testing có heuristic (như Tours) cho ROI cực cao — cover diện rộng với nguồn lực tối thiểu.
Hướng dẫn từng bước
Bước 1 — Xây dựng danh sách charter. Trước một đợt test, ngồi lại brainstorm các charter dựa trên heuristic (SFDIPOT, CRUD, Tours). Mỗi charter là một câu ngắn về khu vực + công cụ + loại vấn đề cần tìm. Ưu tiên charter theo rủi ro (bài về Risk-Based Testing đã dạy cách xếp hạng — dùng chính output đó ở đây).
Bước 2 — Phân bổ và lên lịch session. Vì mỗi session ~90 phút, bạn ước lượng được: một tester làm được tối đa 3–4 session chất lượng mỗi ngày (phần thời gian còn lại dành cho họp, debrief, nghỉ). Đây là cơ sở để lập kế hoạch nguồn lực chính xác.
Bước 3 — Thực thi session không gián đoạn. Tắt thông báo, đặt trạng thái "đang test" trên chat. Vừa test vừa ghi note liên tục (dùng công cụ như session sheet template, hoặc phần mềm chuyên dụng). Khi gặp bug, chuyển sang chế độ điều tra (tính vào B), rồi quay lại test.
Bước 4 — Viết session report ngay khi kết thúc. Điền charter, TBS breakdown, bug, câu hỏi mở, khu vực đã cover. Đừng để đến hôm sau — ký ức phai rất nhanh.
Bước 5 — Debrief theo PROOF. Ngồi với lead 5–10 phút. Buổi debrief không phải để "kiểm tra" tester, mà để chia sẻ tri thức, phát hiện charter mới, và điều chỉnh hướng test cho session sau.
Bước 6 — Tổng hợp và báo cáo. Cộng dồn số session, giờ test, TBS trung bình, phân bố bug theo khu vực. Đây là dữ liệu bạn đưa vào báo cáo release và trình bày với stakeholder.
Lỗi thường gặp & mẹo
Lỗi 1 — Charter quá rộng hoặc quá hẹp. "Test toàn bộ app" thì vô nghĩa, còn "test nút Login màu xanh" thì quá vụn. Mẹo: charter tốt là thứ có thể explore trong đúng một session 90 phút.
Lỗi 2 — Không ghi note trong lúc test. Nhiều tester nghĩ "để test xong rồi nhớ lại". Không được. Bug hay nhất thường xuất hiện ở phút 20, và đến phút 80 bạn sẽ quên mất mình đã làm gì để tái hiện nó. Mẹo: bật màn hình quay video song song để có bằng chứng tái hiện bug.
Lỗi 3 — Bỏ qua debrief vì "bận". Debrief là nơi tri thức được chuyển giao và metric được chuẩn hóa. Bỏ debrief là bỏ đi 50% giá trị của SBTM. Mẹo: gộp debrief nhiều session vào một khung 30 phút cuối ngày.
Lỗi 4 — Dùng SBTM để thay thế hoàn toàn scripted testing. Sai. Exploratory nâng cao bổ sung cho scripted, không thay thế. Compliance, regression tự động hóa vẫn cần script. Mẹo: dùng exploratory cho vùng rủi ro cao/mơ hồ, dùng scripted cho vùng ổn định/cần lặp lại.
Lỗi 5 — Không đo TBS. Nếu bỏ TBS, bạn mất khả năng phát hiện vấn đề môi trường (S cao) hay điểm nóng bug (B cao). Mẹo: chuẩn hóa session sheet template có sẵn 3 ô T/B/S để tester chỉ việc điền.
Mẹo lãnh đạo: Hãy pair một tester giỏi domain với một tester giỏi kỹ thuật trong cùng charter (paired exploratory) khi test khu vực cực kỳ rủi ro — hai góc nhìn khác nhau thường lật được những viên đá mà một người bỏ sót.
Bài tập thực hành
- Viết 5 charter cho tính năng "giỏ hàng" của một app thương mại điện tử, mỗi charter dựa trên một heuristic khác nhau (CRUD, Goldilocks, Money Tour, Back Alley Tour, SFDIPOT-Data). Mỗi charter đúng một câu.
- Chạy thử một session 60 phút trên bất kỳ ứng dụng nào bạn có (web/app), theo một charter tự chọn. Trong lúc test, ghi session note liên tục và bấm giờ để đo TBS. Kết thúc, viết một session report hoàn chỉnh.
- Tự debrief theo PROOF: viết ra 5 dòng — Past, Results, Obstacles, Outlook, Feelings — cho session vừa chạy. Sau đó tự hỏi: nếu là lead, bạn sẽ đề xuất charter tiếp theo nào?
- Thiết kế template session sheet cho team của bạn (có thể bằng Google Sheets), gồm các ô: charter, tester, thời lượng, TBS, bug list, open questions, notes. Chia sẻ với một đồng nghiệp và nhờ họ dùng thử một lần.
Tóm tắt
Exploratory testing nâng cao không phải là "test tự do vô kỷ luật" — nó là một hoạt động có cấu trúc, đo lường được và giải trình được, mà cốt lõi là Session-Based Test Management (SBTM) do Jonathan Bach tiên phong. Bốn thành phần bạn phải nhớ: Session (time-box 60–90 phút, không gián đoạn), Charter (định nghĩa scope và mission), Session Report (biến hoạt động vô hình thành bằng chứng, kèm TBS breakdown), và Debrief theo mô hình PROOF.
Sức mạnh thật sự của kỹ thuật này là phủ được "vùng mù" mà test scripted bỏ sót — như lỗi làm tròn KWD của VietPay hay lỗi encoding tiếng Việt của GymOne. Đồng thời, SBTM cho phép QA Leader báo cáo exploratory testing bằng số liệu, xây dựng niềm tin với stakeholder như trường hợp ShopFast.
Với vai trò lãnh đạo, hãy nhớ: dùng heuristic (SFDIPOT, CRUD, Goldilocks, Tours) để dẫn đường cho session, ưu tiên charter theo rủi ro, và luôn kết hợp — không thay thế — exploratory với scripted testing. Khi bạn làm chủ được điều này, exploratory testing sẽ trở thành một trong những vũ khí tìm bug sắc bén và tiết kiệm nhất trong kho công cụ QA của bạn.