Exploratory Testing là gì? Tại sao những Tester giỏi nhất lại ít phụ thuộc vào Test Case?
Last updated: October 28, 2025 Xem trên toàn màn hình
- 01 Mar 2021
Ý nghĩa và bài học rút ra từ truyện thầy bói xem voi 518 - 03 Feb 2020
Chất lượng là gì? Đẳng cấp là gì? Cùng tìm hiểu toàn diện từ góc nhìn chuyên gia. 492 - 01 Apr 2023
Bí quyết đàm phán tạo ra giá trị từ câu chuyện Chia Cam 492 - 12 Apr 2023
Phương pháp 6 chiếc mũ tư duy là gì? Vận dụng trong điều hành cuộc họp hiệu quả 480 - 17 Mar 2020
Mô hình “Service Gaps Model” quản lý và cải thiện chất lượng dịch vụ 410 - 11 Sep 2024
Mindset, skillset, toolset là gì? 393 - 07 Aug 2019
Câu chuyện thanh gỗ ngắn và bài học kinh doanh cho Doanh nghiệp 381 - 23 Jun 2024
Người trí tuệ không tranh cãi ĐÚNG/SAI 371 - 30 Jul 2021
14 Nguyên Tắc Quản Lý Của Deming Là Gì? 371 - 18 Jun 2021
Cost of Quality - Chi phí cho chất lượng sản phẩm là gì? 301 - 10 Aug 2019
Tại sao tôi chọn công thức "Work Smart" mà không phải "Work Hard"? 226 - 14 Dec 2021
Kano Model Analysis là gì? 207 - 11 Sep 2022
Từ truyện “Thầy bói xem voi” tới quản trị bằng Tư Duy Hệ Thống 203 - 28 Jul 2021
Checklist là gì? Tầm quan trọng của checklist trong công việc 153 - 05 Dec 2022
Hỏi 5 lần (5 WHYs) – Kỹ thuật "đào" tận gốc cốt lõi vấn đề 147 - 23 Sep 2024
Lỗi FUBAR trong phần mềm là gì? 125 - 11 May 2025
Từ điển kỹ thuật trong quản lý tài nguyên truy cập hệ thống (System Access Resource Management) 86 - 02 Aug 2022
BVP (Billable Viable Product) là gì? 71 - 30 Aug 2024
Friction points (điểm ma sát) là gì? 40 - 08 Sep 2025
Tâm Lý Phản Kháng (Reactance): Vì Sao Càng Cấm, Người Ta Càng Muốn Làm? 34 - 20 Apr 2025
“3-point messaging rule” là gì? 28 - 13 Sep 2025
Vanity Metrics: Follower tăng vọt nhưng doanh thu đứng yên 23 - 09 Jul 2025
False Dilemma và Valid Dilemma: Hai "đường biên" trong chiến lược Quản trị chất lượng và Kiểm thử phần mềm 20 - 19 Sep 2025
Luật chống ôm đồm (WIP limits): Làm ít hơn và chất hơn 18 - 11 Sep 2025
📚 Từ điển thuật ngữ về DevOps 16
Exploratory Testing (Kiểm thử khám phá) là một phương pháp kiểm thử phần mềm trong đó người kiểm thử vừa học về hệ thống, vừa thiết kế và thực hiện các ca kiểm thử cùng lúc. Nói cách khác, đây là cách kiểm thử dựa vào tư duy, kinh nghiệm và sự sáng tạo của con người, thay vì chỉ tuân theo kịch bản có sẵn như trong kiểm thử thủ công truyền thống.
Đặc điểm chính
- Không dựa vào test case cố định: Người kiểm thử không làm theo các bước định sẵn, mà chủ động khám phá ứng dụng, tìm hiểu cách nó hoạt động và phát hiện lỗi tiềm ẩn.
- Tập trung vào học và điều tra: Trong quá trình kiểm thử, tester liên tục học hỏi về hệ thống, từ đó điều chỉnh hướng kiểm thử linh hoạt.
- Phát hiện lỗi thực tế và bất ngờ: Phương pháp này thường tìm ra lỗi mà kịch bản kiểm thử tự động không phát hiện được, đặc biệt là lỗi về logic, giao diện hoặc trải nghiệm người dùng.
Ưu điểm
- Nhanh chóng và tiết kiệm thời gian thiết kế test case.
- Linh hoạt, thích hợp cho ứng dụng mới, chưa ổn định hoặc thiếu tài liệu.
- Khai thác tối đa trí tuệ, trực giác và kinh nghiệm của tester.
Hạn chế
- Khó đo lường mức độ bao phủ kiểm thử (test coverage).
- Phụ thuộc nhiều vào năng lực cá nhân của người kiểm thử.
- Khó lặp lại chính xác các bước để tái hiện lỗi (nếu không ghi chép cẩn thận).
Ví dụ
Khi kiểm thử một ứng dụng thương mại điện tử mới, thay vì theo kịch bản “Đăng nhập → Thêm sản phẩm → Thanh toán”, tester có thể tự do thử các hành vi không ngờ tới như:
- Thêm sản phẩm khi chưa đăng nhập.
- Thay đổi ngôn ngữ trong lúc thanh toán.
- Nhấn “Back” khi đang ở bước cuối cùng.
Những hành động này giúp phát hiện các tình huống rủi ro và lỗi thực tế trong quá trình sử dụng.
So sánh Exploratory Testing và Scripted Testing
| Tiêu chí | Exploratory Testing | Scripted Testing |
|---|---|---|
| Cách tiếp cận | Linh hoạt, khám phá | Theo kịch bản cố định |
| Kế hoạch kiểm thử | Không định trước chi tiết | Có kế hoạch, test case rõ ràng |
| Phù hợp với | Giai đoạn đầu, khi yêu cầu chưa rõ | Giai đoạn sau, khi hệ thống ổn định |
| Ưu điểm chính | Phát hiện lỗi ẩn, trải nghiệm người dùng tốt hơn | Dễ đo lường, dễ tái hiện lỗi |
❓ FAQ về Exploratory Testing
1. Exploratory Testing khác gì so với Manual Testing?
Cả hai đều là kiểm thử thủ công, nhưng điểm khác biệt chính là Exploratory Testing không có kịch bản cố định. Trong khi Manual Testing tuân theo các bước và kết quả mong đợi đã được xác định trước, Exploratory Testing cho phép tester vừa học, vừa thử nghiệm và điều chỉnh chiến lược kiểm thử linh hoạt dựa trên những gì họ phát hiện trong quá trình test.
2. Khi nào nên sử dụng Exploratory Testing?
Phương pháp này đặc biệt hiệu quả khi:
- Dự án mới bắt đầu và chưa có tài liệu hoặc test case hoàn chỉnh.
- Hệ thống đang thay đổi nhanh, ví dụ trong giai đoạn prototyping hoặc sprint ngắn.
- Cần đánh giá trải nghiệm người dùng (UX) và phát hiện lỗi thực tế.
- Muốn xác minh tính ổn định của bản build mới trong thời gian ngắn.
3. Ai nên thực hiện Exploratory Testing?
Thông thường, QA tester có kinh nghiệm sẽ đảm nhận vai trò này. Tuy nhiên, developer, business analyst hoặc product owner cũng có thể tham gia, vì mục tiêu chính của phương pháp này là hiểu sâu hơn về sản phẩm và phát hiện vấn đề từ góc nhìn người dùng thật.
4. Làm sao để ghi lại kết quả khi kiểm thử khám phá?
Mặc dù Exploratory Testing mang tính linh hoạt, người kiểm thử nên ghi chú cẩn thận những bước đã thực hiện, chẳng hạn:
- Hành động cụ thể (nhấn nút, nhập dữ liệu, chuyển trang, v.v.)
- Kết quả mong đợi và kết quả thực tế
- Các lỗi hoặc hành vi bất thường phát hiện được
- Các công cụ như TestRail, Xray, hoặc Miro Board cũng có thể hỗ trợ ghi chép phiên kiểm thử.
5. Exploratory Testing có thể kết hợp với Automation Testing không?
Có. Trên thực tế, đây là cặp đôi bổ trợ hoàn hảo.
- Kiểm thử tự động (Automation) đảm bảo kiểm tra hồi quy nhanh và chính xác.
- Exploratory Testing giúp tìm ra lỗi mới, bất thường hoặc trải nghiệm không mong muốn mà automation không thể dự đoán.
Khi kết hợp cả hai, đội kiểm thử vừa đạt độ bao phủ kỹ thuật, vừa đảm bảo tính thực tế trong trải nghiệm người dùng.
6. Có công cụ nào hỗ trợ Exploratory Testing không?
Mặc dù phương pháp này thiên về con người, vẫn có những công cụ giúp ghi lại, chụp màn hình, hoặc ghi video quá trình test như:
- Session-based Test Management (SBTM)
- Test & Feedback (Azure DevOps extension)
- Rapid Reporter
- PractiTest
Các công cụ này giúp lưu lại bằng chứng và báo cáo test một cách chuyên nghiệp, đặc biệt trong môi trường Agile.
7. Làm sao để đo lường hiệu quả của Exploratory Testing?
Bạn có thể đánh giá dựa trên các chỉ số:
- Số lượng lỗi phát hiện được (và mức độ nghiêm trọng).
- Phạm vi chức năng đã được khám phá.
- Mức độ hiểu biết của tester về hệ thống sau mỗi phiên test.
- Ngoài ra, phản hồi từ developer và người dùng cuối cũng là chỉ số quan trọng thể hiện chất lượng của quá trình kiểm thử khám phá.
8. Exploratory Testing khác gì so với Ad-hoc Testing?
Dù cả hai đều không tuân theo test case cố định, nhưng chúng khác nhau ở mức độ tổ chức và mục tiêu:
| Tiêu chí | Exploratory Testing | Ad-hoc Testing |
|---|---|---|
| Mục tiêu | Khám phá hệ thống một cách có chủ đích để học và đánh giá chất lượng sản phẩm. | Thử nghiệm ngẫu hứng, nhằm phát hiện lỗi nhanh trong thời gian ngắn. |
| Cấu trúc & ghi chép | Có kế hoạch tổng thể, thường theo session-based (phiên kiểm thử được giới hạn thời gian và có mục tiêu rõ). | Không có kế hoạch cụ thể, ít hoặc không ghi chép lại các bước. |
| Người thực hiện | Thường là tester có kinh nghiệm, biết cách thiết kế và ghi lại quan sát. | Bất kỳ ai (kể cả developer hoặc người dùng thử nghiệm) đều có thể thực hiện. |
| Kết quả đầu ra | Có báo cáo, nhật ký (log) rõ ràng giúp tái hiện lỗi và cải thiện sản phẩm. | Lỗi có thể phát hiện nhanh nhưng khó tái tạo và khó theo dõi. |
| Tính chuyên nghiệp | Là một phương pháp kiểm thử được công nhận và có kỹ thuật cụ thể. | Mang tính tự phát và không chính thức, thường dùng để “soi nhanh” trước khi release. |
Tóm lại:
- Exploratory Testing là “ngẫu hứng có chiến lược” – tester vừa học, vừa khám phá, vừa phân tích.
- Ad-hoc Testing là “ngẫu hứng hoàn toàn” – thử nhanh để xem có lỗi rõ ràng nào không.
Cả hai đều hữu ích trong các giai đoạn khác nhau của dự án: Ad-hoc phù hợp để tìm lỗi nhanh, còn Exploratory phù hợp để hiểu sâu và đánh giá toàn diện chất lượng sản phẩm.
9. Session-Based Exploratory Testing là gì?
Session-Based Exploratory Testing (SBTM) là một phương pháp tổ chức kiểm thử khám phá (Exploratory Testing) theo phiên làm việc có cấu trúc rõ ràng. Thay vì kiểm thử ngẫu nhiên, tester thực hiện các “phiên kiểm thử” (sessions) được giới hạn về thời gian, mục tiêu và phạm vi, đồng thời ghi chép lại quá trình để đảm bảo có thể đo lường và tái hiện.
Các yếu tố chính của SBTM gồm:
-
Charter (mục tiêu phiên kiểm thử):
Mỗi session bắt đầu bằng một “charter” – mô tả mục tiêu, phạm vi và vấn đề cần kiểm tra (ví dụ: “Kiểm tra quy trình thanh toán khi người dùng thay đổi ngôn ngữ”). -
Time-box (giới hạn thời gian):
Mỗi session thường kéo dài từ 60 đến 120 phút, giúp tester tập trung cao độ và tránh lan man. -
Notes (ghi chú & log):
Tester ghi lại chi tiết các hành động, kết quả, lỗi và nhận xét trong quá trình kiểm thử. -
Debrief (báo cáo sau phiên):
Sau mỗi session, tester và lead QA thảo luận kết quả, đánh giá giá trị tìm được và quyết định hướng kiểm thử tiếp theo.
Lợi ích của phương pháp SBTM:
- Giúp kiểm soát tốt hơn quá trình kiểm thử khám phá mà vẫn giữ được tính linh hoạt.
- Tăng khả năng lặp lại và đo lường hiệu quả kiểm thử.
- Hỗ trợ việc báo cáo minh bạch và chuyên nghiệp trong môi trường Agile hoặc DevOps.
- Tạo nền tảng tốt để phối hợp giữa các tester trong nhóm.
Ví dụ:
Giả sử bạn đang kiểm thử một ứng dụng ngân hàng. Một phiên kiểm thử có thể có:
- Charter: Kiểm tra quy trình chuyển tiền giữa hai tài khoản khác ngân hàng.
- Time-box: 90 phút.
- Kết quả: 3 lỗi UI, 1 lỗi hệ thống không xử lý được khi người dùng nhập ký tự đặc biệt trong phần “Nội dung chuyển tiền”.
Tóm lại: Session-Based Exploratory Testing là cách giúp biến quá trình “khám phá tự do” trở nên có tổ chức, có mục tiêu và dễ báo cáo hơn, đồng thời vẫn phát huy tối đa tính sáng tạo và kinh nghiệm của tester.









Mới cập nhật