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. Câu chuyện này bắt đầu bằng một lời nói dối: "Nó vẫn chạy tốt trên máy của tôi."
Chúng tôi đã 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). Nó có vẻ đơn giản. Bạn nhấn một nút, tải lên một tệp, và dữ liệu được tải vào.
Hầu hết mọi người đều mặc định rằng các tính năng này hoạt động ổn. Tester tồn tại là để chứng minh giả định đó là sai.
Luồng xử lý lý tưởng (happy path) là một cái bẫy.
Nếu bạn tải lên một tệp Excel "sạch", hệ thống sẽ vượt qua. Bạn đi ăn trưa. Bạn nghĩ công việc đã xong. Nếu bạn dừng lại ở đó, bạn sẽ tung ra một đoạn mã lỗi. Một khách hàng sẽ phát hiện ra lỗi đó vào một sáng thứ Hai khi hệ thống đang chạy thực tế (production).
Vấn đề nằm ở một trang Google Sheet.
Người dùng thực tế không sử dụng các tệp Excel ngăn nắp. Họ sử dụng những trang Google Sheet lộn xộn. Họ tạo ra sự hỗn loạn trong các bảng tính và kỳ vọng hệ thống phải xử lý được nó.
Khi chúng tôi tải lên một trang Google Sheet, hệ thống đã thất bại. Nó tạo ra hơn 1.000 lỗi. Cùng một dữ liệu và cùng một nút bấm đó đã gây ra sự sụp đổ hoàn toàn chỉ vì định dạng đã thay đổi.
Sau đó, chúng tôi kiểm tra chất lượng dữ liệu.
- Một vài dòng không hợp lệ? Hệ thống sẽ bỏ qua chúng và tiếp tục.
- Hàng trăm dòng lộn xộn? Hệ thống bị sập.
Logic kiểm tra (validation logic) hoạt động tốt với các lỗi nhỏ. Nhưng nó đã thất bại khi đối mặt với một núi dữ liệu rác.
Chúng tôi đã mất năm tiếng đồng hồ để gỡ lỗi (debug). Chúng tôi đổ lỗi cho tệp tin, trình duyệt và dữ liệu. Chúng tôi thậm chí còn đổ lỗi cho cả cà phê.
Năm tiếng đồng hồ đó vẫn còn là rẻ. Cái giá phải trả nếu không làm vậy còn cao hơn nhiều. Nếu khách hàng phát hiện ra lỗi này, họ sẽ mất niềm tin vào sản phẩm của bạn. Bạn trả giá cho các lỗi trong quá trình 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 chính khách hàng của mình.
Tôi thà trả giá bằng thời gian còn hơn.
Để tìm ra những lỗi thực sự, bạn phải thay đổi tư duy. Đừng hỏi liệu phần mềm có hoạt động hay không. Hãy hỏi làm thế nào để phá vỡ nó.
Đừng nghĩ như một lập trình viên nữa. Hãy bắt đầu nghĩ như:
- Một người dùng lười biếng, người tải lên sai định dạng tệp.
- Một người dùng hỗn loạn với các ô bị gộp (merged cells) và các dòng trống.
- Một 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.
- Một 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 thường hỏng vì những đầu vào (inputs) mà bạn không ngờ tới.
Những tính năng "đơn giản" lại là những thứ nguy hiểm nhất. Nút nhập dữ liệu và ô tìm kiếm trông có vẻ vô hại. Nhưng thực tế không phải vậy.
Lần tới, khi một tính năng vượt qua được luồng xử lý lý tưởng, 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.