Exploratory testing là cách kiểm thử không theo kịch bản viết sẵn: tester vừa dùng phần mềm vừa suy nghĩ để quyết định thử gì tiếp theo. Cách này giúp tìm lỗi mà test case dễ bỏ sót và đánh giá độ dễ dùng, nên thường chạy song song với test theo kịch bản. Đây cũng là kỹ thuật dễ luyện tập cho người mới, không cần công cụ hay kiến thức lập trình.
Exploratory testing là gì?
Trong kiểm thử theo kịch bản, tester làm theo từng bước đã viết sẵn rồi so sánh kết quả với mong đợi. Exploratory testing đi theo hướng khác: thiết kế test, chạy test và học về sản phẩm diễn ra cùng lúc. Tester dùng điều vừa quan sát được để chọn bước tiếp theo. Một bài về xu hướng QA nhận định rằng cách này giúp phần mềm không chỉ chạy đúng chức năng mà còn trực quan, dễ dùng. [1] kualitee
Một phiên khám phá diễn ra thế nào
Một phiên (session) thường gồm các bước:
- Đặt mục tiêu ngắn, ví dụ “khám phá chức năng đặt hàng, tìm chỗ dễ lỗi”.
- Giới hạn thời gian, thường 30 đến 90 phút.
- Vừa dùng vừa ghi chú: đã thử gì, gặp lỗi nào, nảy sinh câu hỏi nào.
- Thử những thao tác “lạ” mà người dùng thật có thể làm: nhập dữ liệu bất thường, bấm liên tục, quay lại giữa chừng, đổi kích thước màn hình, mất mạng giữa lúc thao tác.
- Tổng kết: ghi lại lỗi, điều học được và quyết định có cần phiên tiếp theo không.
Khi gặp lỗi, hãy ghi lại các bước tái hiện ngay lúc đó, vì chỉ vài phút sau bạn có thể không nhớ chính xác mình đã bấm gì. Nếu thấy một khu vực có nhiều lỗi, đó thường là dấu hiệu nên dành thêm thời gian cho khu vực ấy.
Một thói quen hữu ích là viết mục tiêu thành một câu ngắn theo mẫu “khám phá X bằng Y để tìm Z”, ví dụ “khám phá giỏ hàng bằng số lượng bất thường để tìm lỗi tính toán”. Cách này giữ phiên tập trung mà không biến nó trở lại thành kịch bản. Sau phiên, hãy dành vài phút xem lại ghi chú: khu vực nào có vẻ vững, khu vực nào mong manh, và bạn chưa kịp thử gì.
Khi nào nên dùng, và giới hạn
Cách này đặc biệt hiệu quả khi tài liệu yêu cầu thiếu hoặc mơ hồ, khi cần tìm lỗi nhanh mà chưa kịp viết test case, hoặc khi cần đánh giá trải nghiệm người dùng, thứ mà kịch bản khó bao quát. Một nguồn khuyên ưu tiên khu vực rủi ro cao và kết hợp exploratory testing thủ công với phần test đã tự động hóa. [2] ambalait
Cũng cần biết giới hạn của nó. Kết quả phụ thuộc vào kinh nghiệm và sự tò mò của người test: hai người cùng khám phá một chức năng có thể tìm ra những lỗi khác nhau. Nếu không ghi chú, rất khó lặp lại đúng những gì đã làm, và khó chứng minh với người khác rằng một khu vực đã được kiểm tra. Vì vậy exploratory testing nên đi kèm test theo kịch bản chứ không thay thế hoàn toàn.
Bối cảnh: vì sao kỹ thuật này được nhắc nhiều
Nhiều người mới chỉ chạy theo test case có sẵn. Khi yêu cầu đổi nhanh hoặc tài liệu thiếu, cách này dễ bỏ sót lỗi ở những tình huống không ai viết ra. Trong khi đó, định nghĩa chất lượng đang rộng hơn: kiểm thử hiện thường bao gồm cả kiểm tra khả năng tiếp cận (accessibility) và thiết kế bao trùm. [3] Những khía cạnh này khó nằm hết trong kịch bản viết trước, nên cần người test biết quan sát và đặt câu hỏi. tsg-training
Xu hướng “shift-left” (kiểm thử sớm hơn) cũng làm exploratory testing hữu ích hơn. Khi tester tham gia từ đầu, họ thường phải test những tính năng chưa có tài liệu đầy đủ.
Ý nghĩa với người mới vào nghề
Exploratory testing phù hợp để bắt đầu vì mấy lý do:
- Không cần công cụ hay lập trình. Bạn chỉ cần một ứng dụng và một cuốn sổ ghi chú.
- Rèn tư duy của tester. Bạn học cách đặt câu hỏi “nếu người dùng làm thế này thì sao?”, kỹ năng nền tảng cho mọi hướng đi sau này, kể cả automation.
- Có thể luyện ngay trên ứng dụng quen thuộc. Ứng dụng đặt đồ ăn, ngân hàng hay mạng xã hội đều dùng được.
- Dễ tạo sản phẩm để chia sẻ. Báo cáo một phiên khám phá, gồm lỗi tìm thấy và điều học được, là chất liệu tốt cho bài blog hoặc hồ sơ cá nhân.
Một cách luyện đơn giản: chọn một chức năng nhỏ, đặt đồng hồ 30 phút, chỉ ghi lại ba thứ: đã thử gì, thấy gì lạ, còn muốn thử gì. Ví dụ với chức năng đăng ký tài khoản, bạn có thể thử email thiếu ký tự “@”, mật khẩu rất dài, bỏ trống từng ô, dán ký tự đặc biệt, hoặc bấm nút đăng ký hai lần liên tiếp. Sau vài phiên, bạn sẽ nhận ra những kiểu lỗi hay lặp lại. Những sai lầm thường gặp của người mới là chỉ test luồng chính, quên ghi chú và dừng lại sau lỗi đầu tiên. Hãy coi lỗi đầu tiên là một manh mối chứ không phải điểm kết thúc: lỗi thường tập trung thành cụm, nên hãy tìm quanh đó những vấn đề liên quan.
Exploratory testing cũng là một kỹ thuật dựa trên kinh nghiệm có trong giáo trình ISTQB Foundation. Vì vậy, học nó vừa giúp ích cho công việc hằng ngày, vừa là bước đệm nếu sau này bạn muốn lấy chứng chỉ.
Nguồn tham khảo
- Kualitee, “The Future of QA: Trends That Will Shape Software Testing in 2026”: https://www.kualitee.com/blog/qa-testing/qa-trends-in-2026/
- Ambala IT, “Software QA Testing in 2026: Best Practices, Tools & Strategies for Web and Mobile Apps”: https://ambalait.com/blogs/software-qa-testing-in-2026-best-practices-tools-strategies-for-web-and-mobile-apps
- TSG Training, “Top Software Testing & QA Trends for 2026”: https://tsg-training.co.uk/?p=130041
Đọc thêm (đối chiếu với giáo trình chính thức): ISTQB, Certified Tester Foundation Level Syllabus v4.0.1: https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf