Exploratory Testing là gì? Phân biệt Exploratory, Scripted và Ad-hoc Testing

Trong quá trình kiểm thử phần mềm, không phải mọi lỗi đều có thể được phát hiện bằng các test case viết sẵn. Đây chính là lúc Exploratory Testing (Kiểm thử Thăm dò) phát huy vai trò quan trọng. Việc hiểu đúng Exploratory Testing là gì, cũng như phân biệt rõ với Scripted Testing và Ad-hoc Testing, sẽ giúp QA lựa chọn đúng phương pháp kiểm thử trong từng bối cảnh, đặc biệt trong môi trường Agile và các dự án thay đổi liên tục.

Exploratory Testing là gì?

Exploratory Testing (Kiểm thử khám phá) là phương pháp kiểm thử phần mềm linh hoạt, nơi Tester đồng thời thiết kế và thực thi test case trong cùng một phiên làm việc. Thay vì tuân theo kịch bản kiểm thử cố định, Tester dựa vào kiến thức, kinh nghiệm và trực giác để khám phá ứng dụng như một người dùng thực tế.

Mục tiêu của Exploratory Testing là phát hiện các lỗi ẩn mà phương pháp Scripted Testing (kiểm thử theo kịch bản) có thể bỏ sót. Tester tự do điều hướng qua các chức năng, thử nghiệm các tình huống bất thường và tìm kiếm những điểm yếu trong ứng dụng mà không bị giới hạn bởi test case định sẵn.

>> Xem thêm: UI testing là gì?

Ưu, Nhược điểm của Kiểm thử Thăm dò

Như mọi phương pháp, kiểm thử thăm dò cũng có những điểm mạnh và điểm yếu riêng. Việc hiểu rõ các ưu nhược điểm này giúp đội ngũ QA áp dụng một cách hiệu quả nhất.

Ưu điểm

• Phát hiện lỗi (bug) nghiêm trọng và bất ngờ: Đây là lợi ích lớn nhất. Nhờ sự tự do khám phá, tester có thể thực hiện những thao tác phức tạp hoặc không theo logic thông thường, qua đó phát hiện ra những lỗi mà kịch bản dựng sẵn không bao giờ lường tới.
• Hữu ích khi tài liệu kiểm thử sơ sài: Khi tài liệu yêu cầu (requirements) hoặc đặc tả (specifications) không đầy đủ, không rõ ràng hoặc đã lỗi thời, exploratory testing là cứu cánh. Tester có thể bắt đầu kiểm thử ngay lập tức mà không cần chờ đợi test case chi tiết.
• Phản hồi nhanh trong môi trường Agile: Trong các sprint ngắn của mô hình Agile, việc chờ đợi viết xong test case đầy đủ có thể làm chậm tiến độ. Kiểm thử thăm dò cho phép QA cung cấp phản hồi gần như tức thì cho lập trình viên, giúp sửa lỗi nhanh hơn.
• Phát huy tối đa kỹ năng và kinh nghiệm kiểm thử: Phương pháp này khuyến khích sự sáng tạo, trực giác và tư duy phản biện của QA Engineer, biến công việc kiểm thử từ “thực thi theo kịch bản” thành “điều tra và khám phá”.
• Tạo ra ý tưởng mới cho kịch bản kiểm thử: Những phát hiện trong quá trình kiểm thử thăm dò có thể được dùng để tạo ra các test case mới, bổ sung vào bộ kiểm thử hồi quy (Regression testing) trong tương lai.

Nhược điểm

• Phụ thuộc nhiều vào kỹ năng của tester: Chất lượng của phiên kiểm thử phụ thuộc gần như hoàn toàn vào kinh nghiệm, kiến thức về hệ thống và khả năng của người thực hiện.
• Khó tái hiện lỗi: Nếu tester không ghi chép cẩn thận, việc tái hiện lại các bước gây ra lỗi có thể trở nên khó khăn, gây trở ngại cho lập trình viên trong việc sửa lỗi.
• Khó đo lường độ bao phủ (coverage): Rất khó để xác định chính xác những phần nào của ứng dụng đã được kiểm thử và mức độ sâu đến đâu, không giống như việc đánh dấu “passed/failed” trên các test case có sẵn.
• Không phù hợp cho các dự án dài hạn nếu chỉ dùng một mình: Đối với các hệ thống lớn cần kiểm thử hồi quy thường xuyên, việc chỉ dựa vào exploratory testing là không đủ và cần kết hợp với Automation testing.

Quy trình Kiểm thử Thăm dò

Nhiều người lầm tưởng Exploratory Testing là kiểm thử ngẫu nhiên (ad-hoc testing), nhưng thực tế nó có quy trình và kỹ thuật riêng để đảm bảo tính hiệu quả. Một trong những phương pháp phổ biến nhất để cấu trúc hóa kiểm thử thăm dò là Session-Based Testing (Kiểm thử theo phiên).

Quy trình này thường bao gồm 5 bước cốt lõi:

1. Tạo Điều lệ Kiểm thử (Test Charter): Đây là một bản tuyên bố nhiệm vụ rõ ràng cho phiên kiểm thử. Nó xác định mục tiêu, phạm vi và những gì cần khám phá. Một charter tốt sẽ trả lời các câu hỏi: “Tôi sẽ kiểm thử phần nào của ứng dụng?”, “Với mục tiêu gì?”.
2. Thiết lập Timebox (Giới hạn thời gian): Mỗi phiên kiểm thử được giới hạn trong một khoảng thời gian không bị gián đoạn, thường là từ 60 đến 120 phút. Timebox giúp tester tập trung cao độ và đảm bảo tiến độ công việc.
3. Thực thi và Ghi chép (Execution & Note-taking): Trong suốt phiên, tester tập trung vào việc khám phá ứng dụng theo charter đã định. Quan trọng nhất là phải ghi chép lại mọi thứ: các khu vực đã kiểm tra, các giả thuyết, câu hỏi nảy sinh và đặc biệt là các lỗi tìm thấy cùng với các bước tái hiện. Các công cụ hỗ trợ exploratory testing như qTest Explorer có thể giúp ghi lại màn hình và các thao tác một cách tự động.
4. Đánh giá kết quả (Review Results): Sau khi hết thời gian, tester xem lại các ghi chép của mình. Lỗi được ghi nhận trên hệ thống quản lý, và các ghi chú khác được tổng hợp lại.
5. Báo cáo và Thảo luận (Debriefing): Tester sẽ có một buổi trao đổi ngắn với quản lý hoặc các thành viên khác trong nhóm (developer, BA). Mục đích là để chia sẻ những phát hiện, thảo luận về các rủi ro tiềm ẩn và xác định xem có cần thêm các phiên kiểm thử nào khác không.

Khi nào là áp dụng Exploratory Testing trong thực tế?

Với kinh nghiệm đào tạo và làm việc trên nhiều dự án thật tại các đối tác lớn như CMC, Kaopiz, LG, CodeStar Academy nhận thấy kiểm thử thăm dò phát huy hiệu quả tối đa trong các bối cảnh sau:

• Trong môi trường Agile và Scrum: Khi các tính năng mới được phát triển liên tục trong các sprint ngắn, exploratory testing giúp cung cấp phản hồi nhanh chóng về chất lượng mà không cần chờ đợi tài liệu chi tiết. Đây là một phần không thể thiếu của agile testing.
• Khi cần tìm hiểu nhanh về sản phẩm: Đối với một tester mới tham gia dự án hoặc khi một module hoàn toàn mới được giới thiệu, kiểm thử thăm dò là cách hiệu quả nhất để học hỏi và khám phá hệ thống.
• Bổ sung cho Automation Testing: Kiểm thử tự động rất giỏi trong việc kiểm tra hồi quy các luồng đã biết, nhưng lại “mù” trước những lỗi bất ngờ. Exploratory testing lấp đầy khoảng trống đó bằng sự thông minh và sáng tạo của con người.
• Kiểm tra các hệ thống phức tạp hoặc di sản (Legacy): Với các hệ thống cũ, tài liệu thường thiếu hoặc không còn chính xác. Kiểm thử thăm dò là phương pháp thực tế duy nhất để đánh giá chất lượng.
• Kiểm thử trải nghiệm người dùng (Usability testing): Bằng cách đóng vai người dùng cuối và khám phá ứng dụng một cách tự do, tester có thể dễ dàng phát hiện các vấn đề liên quan đến UI (User Interface) và UX (User Experience).

Exploratory Testing khác gì Scripted Testing và Ad-hoc Testing?

Để thực sự hiểu exploratory testing là gì, điều quan trọng là phải phân biệt nó với hai khái niệm thường bị nhầm lẫn: Scripted Testing và Ad-hoc Testing.

Exploratory Testing không chỉ là kiểm thử tự do, mà là một phương pháp kiểm thử có mục tiêu, giúp QA phát hiện những lỗi ẩn mà kịch bản sẵn có khó bao phủ. Khi hiểu và phân biệt đúng Exploratory Testing với Scripted Testing và Ad-hoc Testing, Tester sẽ lựa chọn được phương pháp phù hợp trong từng giai đoạn dự án.

Đối với những ai muốn theo đuổi nghề QA/Tester, việc thực hành Exploratory Testing là kỹ năng không thể thiếu. Khóa học Tester tại CodeStar Academy sẽ giúp bạn rèn luyện tư duy kiểm thử và áp dụng hiệu quả vào dự án thực tế. Đăng ký ngay hôm nay để nhận được những ưu đãi tốt nhất!