Trong thế giới kiểm thử phần mềm, Exploratory Testing (kiểm thử khám phá) không chỉ là việc “nhấp chuột thử xem có lỗi không”. Nó là quá trình tư duy chủ động, khám phá có mục tiêu, và phân tích logic để tìm ra vấn đề mà các kịch bản kiểm thử định sẵn có thể bỏ lỡ.
Để làm được điều đó, tester cần hơn cả kỹ năng thao tác — họ cần tư duy phản biện (Critical Thinking). Đây là “vũ khí” giúp người kiểm thử nhìn sản phẩm không chỉ như người dùng thông thường, mà như một người đặt câu hỏi về mọi giả định, quy trình và hành vi.
Tư duy phản biện là khả năng:
Quan sát, phân tích, và đánh giá thông tin một cách khách quan.
Đặt câu hỏi “tại sao?”, “điều gì sẽ xảy ra nếu…?” thay vì chỉ chấp nhận những gì đang có.
Kết nối dữ liệu, bối cảnh và kinh nghiệm để đưa ra nhận định hợp lý.
Đối với một tester, điều này có nghĩa là không chỉ chạy test theo checklist, mà còn hiểu sâu về mục tiêu sản phẩm, hành vi người dùng, và các rủi ro tiềm ẩn.
Exploratory Testing là nơi tester vừa học, thiết kế test, vừa thực thi — tất cả diễn ra đồng thời. Không có kịch bản cố định, không có hướng dẫn chi tiết. Điều đó đòi hỏi người tester phải:
Đặt giả thuyết: “Tính năng này có thể hoạt động sai ở đâu?”
Tư duy ngược: “Nếu người dùng thao tác sai quy trình, điều gì sẽ xảy ra?”
Nhìn tổng thể: “Lỗi này có thể ảnh hưởng đến phần nào khác trong hệ thống?”
Phân tích nguyên nhân: “Tại sao lỗi xảy ra? Đây là vấn đề logic, giao diện hay dữ liệu?”
Nếu thiếu tư duy phản biện, tester rất dễ sa vào việc “click theo cảm tính”, còn với Critical Thinking, mỗi hành động kiểm thử đều có mục tiêu và giá trị rõ ràng.
Hãy rèn thói quen hỏi:
Mục tiêu thực sự của tính năng này là gì?
Ai sẽ sử dụng, và họ có thể thao tác sai ở đâu?
Điều gì sẽ xảy ra nếu nhập dữ liệu bất thường?
Câu hỏi tốt dẫn đến kiểm thử sâu sắc.
Đừng tin rằng “chức năng này chắc chắn hoạt động đúng” chỉ vì nó đã pass test trước đó.
Critical tester luôn kiểm tra lại — họ biết rằng mọi thứ đều có thể sai khi môi trường, dữ liệu, hoặc phiên bản thay đổi.
Khi gặp lỗi, thay vì chỉ log bug, hãy suy nghĩ:
“Nguyên nhân sâu xa là gì?”
“Lỗi này có thể gây ra lỗi khác không?”
Đây chính là tư duy phân tích nguyên nhân gốc (Root Cause Analysis).
Hãy thử nhìn hệ thống từ các vai trò khác nhau:
Người dùng cuối
Quản trị viên hệ thống
Developer
Business analyst
Mỗi góc nhìn sẽ gợi mở những hành vi và rủi ro mới.
Sau mỗi phiên Exploratory Test, hãy tự hỏi:
Mình đã giả định điều gì sai?
Có tình huống nào mình bỏ qua?
Nếu làm lại, mình sẽ khám phá theo hướng khác không?
Đây là cách rèn luyện tư duy phản biện liên tục.
Khi kiểm thử một ứng dụng thanh toán online, tester có thể làm theo checklist: nhập số tiền, nhấn “Pay”, kiểm tra thông báo thành công.
Nhưng tester có tư duy phản biện sẽ tự hỏi:
“Nếu người dùng mất kết nối mạng giữa lúc thanh toán thì sao?”
“Nếu server trả về lỗi chậm 5 giây, UI có hiển thị đúng không?”
“Nếu người dùng đổi ngôn ngữ ứng dụng ngay giữa giao dịch thì sao?”
Những câu hỏi “khó chịu” như vậy thường chính là nơi ẩn giấu các lỗi nghiêm trọng nhất.
Critical Thinking không phải là “chỉ trích” hay “nghi ngờ mọi thứ” — mà là nghĩ sâu, hỏi đúng, và kiểm chứng cẩn thận.
Khi kết hợp với Exploratory Testing, nó biến tester thành người tư duy như hacker, quan sát như người dùng, và phản biện như nhà phân tích.
Trong kỷ nguyên phát triển phần mềm nhanh, phức tạp và liên tục, tester có tư duy phản biện không chỉ tìm ra bug — họ giúp đội ngũ hiểu rõ hơn về chất lượng thật sự của sản phẩm.
You need to login in order to like this post: click here
YOU MIGHT ALSO LIKE
