Exploratory Testing: Kỹ thuật tìm bug sáng tạo mà fresher tester thường bỏ qua
một tháng trước · 11 phút đọc
Scripted testing không đủ - đây là lý do
Mình nhớ lần đầu nhận task test tính năng đăng ký tài khoản. Mình viết test case đầy đủ: email hợp lệ pass, email sai format fail, bỏ trống báo lỗi. Chạy hết, xanh lá hết. Report: "Passed."
Một tuần sau, user phản hồi: nhập email chứa khoảng trắng ở đầu vẫn đăng ký được. Lỗi nhỏ thôi, nhưng gây ra hàng loạt vấn đề khi gửi email xác nhận. Bug đó không nằm trong test case nào của mình hết - vì mình không nghĩ tới.
Đây là giới hạn cốt lõi của scripted testing (kiểm thử theo kịch bản cố định): bạn chỉ tìm được những gì bạn đã biết mình cần tìm. Còn những thứ nằm ngoài kịch bản? Không ai nhìn tới.
Exploratory testing (kiểm thử khám phá) ra đời để lấp chỗ trống đó.
Scripted testing bỏ sót những gì nằm ngoài kịch bản - đây chính là điểm mù
Exploratory testing không có kịch bản viết sẵn. Bạn vừa thiết kế test, vừa thực thi, vừa học về hệ thống - tất cả diễn ra cùng lúc. Nghe có vẻ "loạn", nhưng thực ra có cấu trúc riêng của nó, mình sẽ giải thích ngay bên dưới.
Điều quan trọng cần hiểu: exploratory testing không thay thế scripted testing. Hai cái bổ sung cho nhau. Scripted testing đảm bảo những luồng quan trọng chạy đúng. Exploratory testing tìm những thứ không ai nghĩ tới.
Exploratory testing là gì - giải thích theo kiểu người thật
Nếu scripted testing giống như nấu ăn theo công thức từng bước, thì exploratory testing giống như vào bếp và thử nghiệm: bạn biết mình đang nấu món gì, biết nguyên liệu có sẵn, nhưng bạn tự quyết định thử kết hợp ra sao.
Định nghĩa chính thức từ James Bach - người tiên phong kỹ thuật này: exploratory testing là cách tiếp cận mà việc thiết kế test và thực thi test diễn ra đồng thời, bổ sung liên tục cho nhau.
Nói đơn giản hơn: bạn không ngồi viết hết test case trước rồi mới chạy. Bạn vừa dùng app, vừa đặt câu hỏi "Điều gì sẽ xảy ra nếu mình làm thế này?", rồi thử luôn.
Vừa khám phá vừa học - đó là điểm khác biệt của exploratory testing
Có 3 yếu tố cốt lõi:
Đồng thời: Thiết kế và chạy test cùng lúc, không tách rời.
Học liên tục: Mỗi action bạn làm dạy bạn thêm về hệ thống. Phát hiện ra cách filter hoạt động kỳ lạ? Bạn ngay lập tức thử thêm các case liên quan.
Có hướng dẫn (charter): Đây là phần nhiều fresher hiểu nhầm. Exploratory testing không phải "click bừa". Bạn có một charter - tức là mục tiêu rõ ràng cho session đó. Ví dụ: "Khám phá tính năng thanh toán của Shopee với các loại voucher khác nhau."
Cái charter đó giữ bạn tập trung, không lang thang vô định.
Phân biệt exploratory testing và scripted testing
Hai kỹ thuật này không đối lập, nhưng hiểu rõ điểm khác nhau giúp bạn biết khi nào dùng cái gì.
| Tiêu chí | Scripted Testing | Exploratory Testing |
|---|---|---|
| Kịch bản | Viết sẵn trước khi chạy | Thiết kế trong lúc chạy |
| Mục tiêu | Verify theo yêu cầu | Khám phá + tìm bug bất ngờ |
| Kết quả | Dự đoán được (pass/fail) | Không biết trước |
| Khi dùng | Regression, smoke test | Tính năng mới, UAT |
| Ghi chép | Kết quả từng bước | Notes + session log |
| Kinh nghiệm cần | Ít hơn | Nhiều tư duy phân tích hơn |
Trong thực tế dự án, bạn sẽ dùng cả hai. Buổi sáng chạy regression testing theo kịch bản cố định để đảm bảo tính năng cũ không vỡ. Buổi chiều dành 1-2 tiếng exploratory session cho tính năng mới dev vừa push lên.
Kết hợp cả hai kiểu testing mới bao phủ được nhiều loại bug nhất
Mình từng có teammate cứng đầu, chỉ làm scripted testing. Mỗi sprint anh ấy report "100% passed". Nhưng sau release lại có bug từ user. Vì anh ấy chỉ test những gì được liệt kê trong requirement - không ai nghĩ tới edge case nằm ngoài requirement đó.
Cách thực hiện một exploratory testing session
Có cấu trúc cụ thể cho một session - không phải "ngồi click bừa". Kỹ thuật phổ biến nhất là session-based exploratory testing (kiểm thử theo phiên có giới hạn thời gian).
Bước 1: Viết charter
Charter là mục tiêu của session. Format đơn giản:
Khám phá [tính năng/khu vực] để tìm [loại bug/rủi ro]
Ví dụ thực tế:
- "Khám phá tính năng upload ảnh profile để tìm bug liên quan đến file format và kích thước"
- "Khám phá flow thanh toán Shopee Pay để tìm lỗi khi mạng chậm hoặc ngắt kết nối"
- "Khám phá phần search trên Tiki để tìm input không được sanitize"
Charter không cần dài. 1-2 câu là đủ. Quan trọng là có hướng.
Bước 2: Đặt thời gian
Một session thường kéo dài 60-90 phút. Ngắn hơn thì không đủ khám phá. Dài hơn thì mất tập trung.
Mình hay dùng timer 75 phút. Không bị phân tâm bởi slack, không check email. Thời gian đó chỉ dành cho session.
75 phút tập trung hiệu quả hơn 3 tiếng vừa test vừa xem điện thoại
Bước 3: Chạy session và ghi chép liên tục
Đây là bước quan trọng nhất - và cũng là thứ fresher hay bỏ qua nhất.
Trong lúc test, ghi lại:
- Mình đã làm gì (action)
- Hệ thống phản hồi gì (observation)
- Câu hỏi nảy sinh (cần explore thêm)
- Bug tìm thấy (screenshot + steps)
Format ghi chép đơn giản, bạn dùng Notepad cũng được:
[10:05] Upload ảnh .heic (iPhone format) → hệ thống báo "Invalid format" nhưng vẫn upload lên
[10:08] Ảnh hiển thị broken trên trang profile
[10:12] Thử upload file .exe đổi tên thành .jpg → UPLOAD THÀNH CÔNG (??)
→ BUG: Server không validate file type thực sự, chỉ check extension
Ghi chép trong lúc test giúp bạn không quên bug, và sau session có đủ thông tin để viết bug report đầy đủ.
Bước 4: Debriefing sau session
Sau khi hết giờ, dành 10-15 phút tổng kết:
- Đã khám phá được những gì?
- Bug nào tìm được?
- Còn vùng nào chưa cover?
- Session tiếp theo cần focus vào đâu?
Nếu làm trong team, debriefing chung với QA lead giúp chia sẻ findings và lên kế hoạch tiếp.
Kỹ thuật explore thực tế - không phải click ngẫu nhiên
Exploratory testing hiệu quả dựa vào heuristics - tức là các nguyên tắc kinh nghiệm giúp bạn biết nên test cái gì tiếp theo. Có một số heuristics phổ biến mình hay dùng:
SFDIPOT là framework do James Bach đề xuất, giúp bạn explore từ nhiều góc độ:
- S - Structure: Kiểm tra cấu trúc dữ liệu. Input có giới hạn ký tự không? Database lưu kiểu gì?
- F - Function: Tính năng hoạt động đúng không? Happy path trước, rồi mới negative.
- D - Data: Boundary values, special characters, null, empty, rất dài, rất ngắn.
- I - Interface: UI hiển thị đúng trên các màn hình, browser, thiết bị?
- P - Platform: iOS vs Android, Chrome vs Firefox, Windows vs Mac.
- O - Operations: Điều gì xảy ra khi dùng lâu? Dùng nhiều tab? Nhiều user cùng lúc?
- T - Time: Timezone, date format, deadline, timeout.
SFDIPOT giúp bạn không bỏ sót góc độ nào khi explore
Mình thường in SFDIPOT ra, dán cạnh máy tính. Trong lúc session, khi không biết test cái gì tiếp theo, nhìn vào đó chọn một góc chưa cover.
Một số kỹ thuật input nhanh hay tìm được bug:
Với text field:
- Nhập khoảng trắng đầu/cuối chuỗi
- Emoji: 😂, ký tự tiếng Việt có dấu, ký tự đặc biệt:
<script>,'; DROP TABLE - Chuỗi cực dài (thử 10.000 ký tự)
- Chuỗi rỗng sau khi đã nhập rồi xóa hết
Với file upload:
- File 0 byte
- File đúng extension nhưng sai nội dung (đổi tên .exe thành .jpg)
- File vượt giới hạn size đúng 1 byte
- Upload cùng lúc nhiều file
Với network:
- Tắt mạng giữa chừng trong lúc submit
- Mạng chậm (Chrome DevTools có thể giả lập)
- Submit 2 lần nhanh liên tiếp (double submit)
Thấy nhiều không? Đừng lo. Bạn không cần nhớ hết ngay. Mình cũng mất vài tháng mới quen với các pattern này. Cứ bookmark lại và practice dần.
Ghi chép findings và viết bug report từ exploratory session
Bug tìm được trong exploratory session thường "kỳ lạ" và khó reproduce nếu không ghi chép kỹ ngay lúc đó. Đây là lý do nhiều fresher mất bug - tìm được rồi nhưng không nhớ cách reproduce chính xác.
Session note template đơn giản mình dùng:
=== EXPLORATORY SESSION ===
Charter: [mục tiêu session]
Thời gian: [bắt đầu] - [kết thúc]
Môi trường: [browser, OS, version app]
=== TIMELINE ===
[HH:MM] Action → Observation
[HH:MM] Action → Observation
→ BUG: [mô tả ngắn]
=== BUGS TÌM ĐƯỢC ===
1. [Tên bug] - [Severity]
Steps to reproduce:
Expected:
Actual:
Screenshot: [link]
=== CÒN CẦN EXPLORE ===
- [Vùng chưa test]
- [Câu hỏi chưa có câu trả lời]
Ghi chép ngay lúc test - không để đến cuối session mới viết lại
Khi chuyển từ session note sang bug report chính thức trên Jira hoặc TestRail, bạn đã có đủ thông tin rồi, chỉ cần format lại.
Một bug report từ exploratory session cần thêm phần "Cách tìm ra bug này" - tức là bạn đang test gì, với mục tiêu gì, thì phát hiện ra. Dev rất thích thông tin này vì giúp họ hiểu context, từ đó fix đúng gốc rễ hơn.
Ví dụ bug report hoàn chỉnh:
Tiêu đề: Upload file .exe đổi tên thành .jpg thành công
Environment: Chrome 120, macOS, Staging v2.3.1
Cách tìm ra: Đang explore tính năng upload ảnh profile,
kiểm tra xem server có validate file type thực sự không.
Steps to reproduce:
1. Mở trang profile settings
2. Click "Đổi ảnh đại diện"
3. Chuẩn bị file test.exe, đổi tên thành test.jpg
4. Upload file đó lên
5. Click Save
Expected: Hệ thống từ chối, báo lỗi "Invalid file type"
Actual: Upload thành công, ảnh hiển thị broken trên profile
Severity: High - Potential security risk
Screenshot: [đính kèm]
Bug report rõ ràng = dev fix nhanh. Bug report mơ hồ = dev hỏi lại = mất thêm 1-2 ngày. Mình luôn nhắc bạn mới: viết bug report như viết cho người không biết gì về cái bạn vừa làm.