Exploratory Testing(Kiểm thử khám phá)

Exploratory Testing (Kiểm thử thăm dò) là gì?

Exploratory Testing (Kiểm thử thăm dò) là một phương pháp kiểm thử mà trong đó tester vừa thiết kế các kịch bản kiểm thử vừa tiến hành thực thi chúng ngay trên hệ thống cùng một lúc, thay vì viết trước các Test Case chi tiết rồi mới chạy theo kịch bản cố định.

Nói một cách dễ hiểu, đây giống như việc bạn đi thám hiểm một khu rừng mới: Bạn vừa đi, vừa quan sát, vừa tự đặt câu hỏi và tìm đường dựa trên trực giác, kinh nghiệm và sự hiểu biết về phần mềm, thay vì cầm một tấm bản đồ (tài liệu Test Case) vạch sẵn từng bước.

Exploratory Testing (Kiểm thử khám phá) ra đời như một phương pháp kiểm thử hiện đại, nâng cao, đóng vai trò như một cách tiếp cận mang tính tự do, linh hoạt nhưng có định hướng rõ ràng.

• Định nghĩa & Bản chất: Exploratory Testing là một phương pháp kiểm thử mà trong đó người kiểm thử đồng thời học hỏi (Learning) về ứng dụng, thiết kế (Designing) kịch bản kiểm thử, và thực thi (Executing) các bài test cùng một lúc.

• Phương châm cốt lõi: Phương pháp này đặt con người, tư duy phản biện, kỹ năng, sự nhạy bén và kinh nghiệm của Kỹ sư QC làm trung tâm. Nó trả lời cho câu hỏi: “Phần mềm sẽ ứng xử thế nào khi đối mặt với những hành vi sử dụng bất ngờ, không có trong kịch bản chuẩn?”.

Đặc điểm cốt lõi của Exploratory Testing

• Học hỏi, thiết kế và thực thi song song: Quá trình tìm hiểu ứng dụng, viết ý tưởng test và bấm máy chạy diễn ra gần như đồng thời.

• Dựa trên kinh nghiệm và trực giác: Phụ thuộc rất nhiều vào kỹ năng, sự nhạy bén và tư duy phá hoại (mindset tìm lỗi) của Tester.

• Không cần kịch bản viết sẵn: Không tốn thời gian để soạn thảo hàng trăm trang Test Case cứng nhắc trước khi bắt đầu.

• Thường dùng phương pháp “Session-based Testing”: Chia thời gian kiểm thử thành các phiên (sessions) ngắn có mục tiêu rõ ràng (ví dụ: phiên 45 phút chuyên đi tìm lỗi giao diện trên trang thanh toán).

Khi nào nên sử dụng Exploratory Testing?

• Khi tài liệu yêu cầu thiếu hoặc không có: Dự án làm gấp, yêu cầu thay đổi liên tục hoặc tài liệu (SRS) mơ hồ, chưa kịp viết Test Case.

• Khi cần kiểm thử nhanh (Ad-hoc / Rapid testing): Cần đánh giá nhanh chất lượng của một phiên bản phần mềm trong thời gian ngắn.

• Bổ sung cho Scripted Testing: Dùng để tìm ra những lỗi ẩn giấu mà các bộ Test Case tiêu chuẩn (viết sẵn) dễ bị bỏ sót.

• Khi tester mới gia nhập dự án: Giúp họ tự do tương tác với ứng dụng để nhanh chóng nắm bắt luồng nghiệp vụ và cách vận hành của hệ thống.

Ưu và nhược điểm của Exploratory Testing

2. Bản chất lý luận:

• Triết lý cốt lõi: Exploratory Testing được định nghĩa chính thức bởi Cеміner (Cem Kaner) và James Bach là hoạt động kiểm thử đồng thời học hỏi ứng dụng, thiết kế kịch bản và thực thi các bài kiểm tra cùng một lúc.

• Vòng lặp liên tục (Feedback Loop):

  • Quan sát hệ thống (Observe): Tương tác trực tiếp với giao diện, API hoặc luồng dữ liệu.

  • Phân tích logic (Think): Đặt câu hỏi: “Điều gì sẽ xảy ra nếu mình nhập dữ liệu này? Nếu mạng rớt ở bước này thì sao?”.

  • Hành động & Học hỏi (Act & Learn): Thực thi ngay lập tức, ghi nhận kết quả phản hồi và điều chỉnh chiến lược kiểm thử cho bước tiếp theo.

• Phân biệt Exploratory Testing với Ad-hoc Testing: Nhiều người lầm tưởng kiểm thử khám phá giống với Ad-hoc Testing (kiểm thử ngẫu nhiên không mục đích). Thực tế hoàn toàn trái ngược: Ad-hoc Testing là việc bấm máy vô định hình không có phương pháp, trong khi Exploratory Testing là một quá trình có cấu trúc tư duy cực kỳ chặt chẽ, có mục tiêu rõ ràng và được quản lý bằng các phương pháp khoa học.

3. Mô hình quản lý :

Để biến việc “khám phá” trở thành một hoạt động chuyên nghiệp có thể đo lường và báo cáo được cho cấp quản lý, Jon Bach và Michael Bolton đã phát triển mô hình Session-Based Test Management (SBTM). Một phiên kiểm thử khám phá chuẩn mực diễn ra qua các cấu phần sau:

1. Test Charter (Sứ mệnh kiểm thử): Mỗi phiên kiểm thử không được lan man mà phải xoay quanh một sứ mệnh cụ thể. Ví dụ: “Khám phá các điểm yếu về bảo mật và phân quyền trên module Quản lý tài khoản người dùng” hoặc “Kiểm tra độ bền vững của giỏ hàng khi người dùng liên tục thao tác thay đổi số lượng sản phẩm và ngắt kết nối internet”.

2. Time-boxing (Giới hạn thời gian khắt khe): Mỗi phiên kiểm thử (Session) thường được khống chế trong khoảng thời gian từ 60 đến 120 phút tập trung cao độ. Giới hạn này giúp bộ não của kiểm thử viên luôn ở trạng thái tỉnh táo, sắc sảo nhất, tránh sự mệt mỏi dẫn đến bỏ sót lỗi.

3. Session Sheet (Nhật ký phiên): Trong suốt quá trình khám phá, QC ghi chép lại:

   • Thời gian thực hiện

   • Các khu vực đã đi qua (Area tested)

   • Các lỗi phát hiện được (Bugs)

   • Các câu hỏi hoặc rủi ro mới phát sinh (Issues/Risks)

4. Session Debriefing (Tổng kết và Báo cáo): Sau khi kết thúc phiên, QC trình bày kết quả ngắn gọn cho Test Lead hoặc Project Manager, từ đó quyết định xem có cần mở rộng phiên khám phá đó hay không.

4. Các kỹ thuật và heuristics nâng cao trong kiểm thử khám phá :

Để quá trình khám phá không bị bế tắc, một kỹ sư QC giàu kinh nghiệm thường áp dụng các nguyên tắc kinh nghiệm (Heuristics) và mô hình gợi nhớ:

• Mô hình SFDPO (Product Elements): Khám phá ứng dụng dưới 5 góc độ:

  • Structure (Cấu trúc): Mã nguồn, phần cứng, tệp tin hệ thống.

  • Function (Chức năng): Những gì hệ thống làm được.

  • Data (Dữ liệu): Cách hệ thống lưu trữ, xử lý và hiển thị thông tin.

  • Platform (Nền tảng): Trình duyệt, hệ điều hành, thiết bị.

  • Operations (Vận hành): Ai sẽ sử dụng hệ thống và sử dụng như thế nào.

• Kỹ thuật “Touring” (Các chuyến tham quan ứng dụng): Giả lập vai trò của các đối tượng khác nhau để khám phá hệ thống (ví dụ: Tourist Tour – lướt qua mọi ngóc ngách giao diện; Bad-Neighbor Tour – cố tình tìm cách làm sập ứng dụng; Money Tour – tập trung vào mọi luồng liên quan đến tiền bạc, thanh toán).

5. Lợi ích chiến lược, thách thức và cạm bẫy cần tránh khi triển khai:

• Lợi ích tối thượng:

  • Phát hiện lỗi độc nhất (Unique Bugs): Tìm ra những lỗi mà kịch bản chuẩn hoàn toàn bỏ sót.

  • Tối ưu thời gian bắt đầu: Không cần đợi viết xong hàng ngàn Test Cases mới được bắt đầu test sản phẩm.

  • Kích thích tư duy sáng tạo: Giúp kiểm thử viên thấu hiểu sâu sắc bản chất hệ thống thay vì làm việc máy móc.

• Thách thức & Cạm bẫy:

  • Khó khăn trong việc đo lường tiến độ chính xác (do không đếm số lượng Test Cases hoàn thành).

  • Đòi hỏi kiểm thử viên phải có năng lực chuyên môn cao, am hiểu sâu rộng về nghiệp vụ và kiến trúc phần mềm.

6. Cảm nhận, chiêm nghiệm :

• Thông qua việc nghiên cứu và thực hành Exploratory Testing, em nhận thức sâu sắc rằng nghề kiểm thử phần mềm không phải là một công việc lặp đi lặp lại đơn điệu, mà là một hành trình thám hiểm tri thức đầy thú vị.

• Kết hợp hài hòa giữa Scripted Testing (đảm bảo kỷ luật quy trình) và Exploratory Testing (đảm bảo sự nhạy bén sáng tạo) chính là chìa khóa tối thượng giúp một kỹ sư QC nâng tầm năng lực chuyên môn, bảo vệ tuyệt đối chất lượng sản phẩm và mang lại trải nghiệm hoàn hảo nhất cho người dùng cuối.

Vu Do

Xem tất cả bài viết của tác giả

Bài viết khác

Test Automation(Kiểm thử tự động)

1.Test Automation (Kiểm thử tự động) là gì? Trong các dự án phát triển phần mềm truyền thống trước đây, toàn bộ quy trình kiểm thử (Testing) đều được thực hiện thủ công (Manual Testing) bởi con người. Các kiểm thử viên trực tiếp thao tác trên giao diện, nhập dữ liệu, kiểm tra kết […]

Đọc thêm

Logging – Monitoring – CI/CD

Logging, Monitoring và CI/CD là gì? Vai trò trong phát triển Backend 1. Tổng quan Khi xây dựng một ứng dụng Backend, viết code và chạy được chương trình mới chỉ là bước đầu. Khi ứng dụng được đưa vào sử dụng, lập trình viên còn cần biết ứng dụng đang hoạt động như thế […]

Đọc thêm

Redis & Caching là gì?

Redis & Caching là gì? Hướng dẫn sử dụng Redis trong Go 1. Caching là gì? Vì sao cần cache khi đã có database? Caching (bộ nhớ đệm) là kỹ thuật lưu tạm dữ liệu thường được truy cập để có thể lấy lại nhanh chóng khi cần, thay vì phải thực hiện lại toàn […]

Đọc thêm

Background Jobs & Queues

1. Background Jobs & Queues là gì? Trong một ứng dụng backend, không phải công việc nào cũng cần hoàn thành ngay trong lúc xử lý HTTP request. Ví dụ, khi người dùng đăng ký tài khoản, hệ thống có thể cần: Lưu thông tin người dùng vào database. Gửi email xác nhận. Gửi thông […]

Đọc thêm

Saga Pattern

Saga Pattern là gì? Quản lý Transaction trong kiến trúc Microservices 1. Saga Pattern là gì? Saga Pattern là một mẫu thiết kế được sử dụng để quản lý các nghiệp vụ phân tán gồm nhiều bước xử lý, trong đó mỗi bước có thể thực hiện một local transaction tại một service hoặc Database […]

Đọc thêm

Two-Phase Locking (2PL)

Two-Phase Locking (2PL) là gì? Cơ chế khóa hai pha trong Database 1. Two-Phase Locking (2PL) là gì? Two-Phase Locking (2PL — khóa hai pha) là một giao thức quản lý khóa trong Database, quy định cách một transaction được phép lấy và giải phóng lock trong quá trình thực thi. Khi nhiều transaction cùng […]

Đọc thêm