1000 Lỗi, Một Trang Google Sheet, và Năm Tiếng Đồng Hồ Tôi Sẽ Không Bao Giờ Lấy Lại Được
Mỗi lỗi (bug) đều có một câu chuyện riêng. Hầu hết đều bắt đầu bằng câu: "Nó vẫn chạy bình thường trên máy tôi mà."
Chúng tôi đang kiểm thử một tính năng nhập dữ liệu cho một công ty tìm kiếm khách hàng tiềm năng (lead generation). Tính năng này có vẻ đơn giản. Bạn nhấn nút nhập, tải lên một bảng tính, và hệ thống sẽ tải các liên hệ lên. Mọi người đều cho rằng nó đã hoạt động ổn.
Giả định đó chính là một cái bẫy.
Những người kiểm thử (testers) tồn tại là để phá vỡ giả định đó. "Happy path" (luồng xử lý lý tưởng) luôn lừa dối bạn.
Nếu chúng tôi sử dụng một tệp Excel sạch sẽ, việc nhập dữ liệu sẽ thành công. Chúng tôi đã có thể đi ăn trưa. Chúng tôi đã có thể phát hành tính năng đó. Nhưng một khách hàng sẽ phát hiện ra lỗi vào một sáng thứ Hai ngay trên môi trường production.
Vấn đề nằm ở Google Sheet.
Người dùng thực tế không sử dụng các tệp Excel sạch sẽ. Họ sử dụng những trang Google Sheet lộn xộn. Họ kỳ vọng hệ thống có thể xử lý được sự hỗn loạn của họ.
Khi chúng tôi tải dữ liệu Google Sheet lên, hệ thống đã thất bại. Chúng tôi thấy hơn 1.000 lỗi. Màn hình tràn ngập các thông báo lỗi. Cùng một nút bấm và cùng một kiểu dữ liệu đó đã gây ra sự sụp đổ hoàn toàn chỉ vì định dạng nguồn thay đổi.
Chúng tôi quay lại với Excel để kiểm thử thêm. Chúng tôi thử kết hợp các hàng hợp lệ và không hợp lệ. Hệ thống xử lý khá tốt. Nó bỏ qua các hàng lỗi và tiếp tục chạy.
Sau đó, chúng tôi thử nghiệm sự hỗn loạn của thế giới thực. Chúng tôi tải lên một tệp lớn với hàng trăm hàng. Hầu hết là dữ liệu rác. Chỉ có một vài hàng là dùng được.
Hệ thống đã bị sụp đổ hoàn toàn. Logic kiểm tra (validation logic) hoạt động tốt với vài hàng lỗi, nhưng nó đã "gục ngã" trước một núi dữ liệu rác.
Chúng tôi đã mất năm tiếng đồng hồ để tìm ra nguyên nhân gốc rễ. Chúng tôi nhìn chằm chằm vào màn hình, chạy lại các bài kiểm thử, và đổ lỗi cho các tệp tin, trình duyệt, và cả cà phê.
Năm tiếng đồng hồ đó vẫn còn là rẻ. Lựa chọn thay thế là một khách hàng mất cả buổi chiều và mất niềm tin vào sản phẩm của chúng tôi. Bạn trả giá cho các lỗi khi kiểm thử bằng thời gian. Bạn trả giá cho các lỗi trên môi trường production bằng khách hàng.
Tôi sẽ luôn chọn năm tiếng đồng hồ đó.
Một tester giỏi không hỏi xem một tính năng có hoạt động hay không. Một tester giỏi hỏi làm thế nào để phá vỡ nó.
Đừng suy nghĩ như một lập trình viên nữa. Hãy bắt đầu suy nghĩ như những kiểu người này:
- Người dùng lười biếng, người tải lên sai định dạng tệp.
- Người dùng gây hỗn loạn với các ô bị gộp (merged cells) và các hàng trống.
- Người dùng tải dữ liệu lớn với 4.000 bản ghi "bẩn" thay vì 10 bản ghi sạch.
- Kẻ gây rối, người luôn làm chính xác những gì họ không nên làm.
Phần mềm bị lỗi ở chính những đầu vào (inputs) mà bạn không ngờ tới.
Những tính năng "đơn giản" nhất thường là những tính năng nguy hiểm nhất. Nút nhập dữ liệu, hộp tìm kiếm và biểu mẫu liên hệ trông có vẻ vô hại. Nhưng thực tế không phải vậy.
Nếu một tính năng đã vượt qua "happy path", đừng dừng lại ở đó. Hãy là người đặt câu hỏi: "Chuyện gì sẽ xảy ra nếu tôi tải lên tệp tồi tệ nhất có thể tưởng tượng được?"
Sau đó, hãy đi làm việc đó ngay.
Optional learning community: https://t.me/GyaanSetuAi