Người kiểm thử với 10 chứng chỉ nhưng không thể tìm thấy một lỗi nào
Bạn có mọi chứng chỉ. ISTQB, ScrumMaster, Cloud và Security. Bản CV của bạn là một "bức tường" đầy rẫy các chữ viết tắt.
Nhưng bạn không thể viết nổi một bài kiểm thử nào tìm ra được một lỗi thực sự.
Tôi đã phỏng vấn một ứng viên vào quý trước. Họ chỉ nói về lý thuyết. Họ nhắc đến V-model và shift-left. Khi tôi yêu cầu họ cho xem một bài kiểm thử mà họ đã viết giúp phát hiện ra lỗi, họ chỉ im lặng.
Họ chưa bao giờ viết một bài kiểm thử nào làm hỏng được thứ gì đó. Họ chỉ viết những bài kiểm thử luôn luôn vượt qua (pass).
Chứng chỉ kiểm tra trí nhớ của bạn. Lỗi (bugs) kiểm tra tư duy của bạn.
Chứng chỉ cung cấp từ vựng và cấu trúc. Chúng giúp bạn vượt qua vòng sàng lọc của nhà tuyển dụng. Nhưng chúng không dạy bạn cách tìm ra các khiếm khuyết (defects).
Các câu hỏi thi tuân theo một giáo trình. Các ứng dụng thực tế thì không. Một biểu mẫu đăng nhập không có giáo trình. Nó có những trường hợp biên (edge cases) kỳ lạ, chẳng hạn như đồng hồ máy chủ bị lệch bốn phút hoặc các vấn đề về thời gian (timing issues) cụ thể.
Người kiểm thử có chứng chỉ thường làm theo danh sách kiểm tra (checklist). Họ viết các bài kiểm thử dựa trên yêu cầu và đánh dấu chúng là đạt (pass) hoặc không đạt (fail).
Người săn lỗi (bug hunter) coi việc kiểm thử như một cuộc điều tra. Họ bắt đầu với một giả thuyết. Họ cố gắng chứng minh rằng ứng dụng đang làm sai.
Hãy nhìn vào sự khác biệt trong tư duy.
Một bài kiểm thử tiêu chuẩn kiểm tra happy path:
- Đi đến phần sản phẩm.
- Thêm vào giỏ hàng.
- Nhập thông tin thẻ hợp lệ.
- Mong đợi xác nhận đơn hàng.
Bài kiểm thử này chứng minh rằng tính năng hoạt động tốt khi mọi thứ đều hoàn hảo. Nó sẽ không bao giờ tìm thấy lỗi.
Một bài kiểm thử của người săn lỗi luôn đầy sự nghi ngờ:
- Nhập số thẻ có lỗi đánh máy.
- Mong đợi một thông báo lỗi.
- Kiểm tra xem xác nhận đơn hàng có vô tình xuất hiện hay không.
Bài kiểm thử thứ hai giả định rằng ứng dụng sẽ thất bại. Nó đặt câu hỏi: "Nó sẽ hỏng ở đâu?"
Nhiều kiểm thử viên có lỗ hổng về kinh nghiệm, chứ không phải lỗ hổng trong CV. Bạn đã thấy các bài kiểm thử thất bại vì dữ liệu xấu hoặc môi trường bị sập. Nhưng bạn chưa thấy bài kiểm thử thất bại vì bạn tìm ra một lỗ hổng trong logic.
Hãy ngừng học để thi lấy các chứng chỉ mới. Hãy lấp đầy khoảng trống đó bằng cách viết những bài kiểm thử được thiết kế để làm hỏng hệ thống.
Hãy thử bài tập này: Chọn một tính năng. Dành một giờ để cố gắng làm hỏng nó.
Đối với tính năng tìm kiếm:
- Kiểm thử các truy vấn vô nghĩa.
- Kiểm thử các ký tự SQL injection.
- Kiểm thử các chuỗi rỗng.
Đối với tính năng tải tệp lên:
- Kiểm thử các tệp không có phần mở rộng.
- Kiểm thử các tệp có kích thước khổng lồ.
- Kiểm thử các tên tệp độc hại.
Tôi từng làm việc trong một hệ thống thanh toán với độ bao phủ (coverage) đạt 95%. Mọi bài kiểm tra đều vượt qua. Thế rồi, hệ thống bị thất thoát tiền trong môi trường production chỉ vì một lỗi làm tròn. Các bài kiểm tra của chúng tôi đã bao phủ các kịch bản thông thường (happy path), nhưng không ai nghĩ đến việc kiểm tra logic toán học.
Giờ đây, tôi bắt đầu mọi bài kiểm tra với một câu hỏi duy nhất: "Điều gì cần phải xảy ra để tính năng này thất bại một cách âm thầm?"
Đừng xây dựng một trang web portfolio. Đừng cập nhật LinkedIn của bạn.
Hãy viết một bài kiểm tra được thiết kế để thất bại. Nếu nó vượt qua, bạn đã có một sự đảm bảo về an toàn. Nếu nó thất bại, bạn đã tìm thấy một lỗi.
Hãy viết lại những gì bạn đã kiểm tra, cách bạn kiểm tra và những gì bạn tìm thấy. Đó mới là minh chứng thực sự cho khả năng tư duy của bạn.
Một bài kiểm tra nào bạn sẽ viết trong tuần này để chứng minh rằng bạn có thể tìm ra lỗi?
Cộng đồng học tập tùy chọn: https://t.me/GyaanSetuAi