Tác giả
Form là thứ tester gặp nhiều nhất. Đăng ký, đăng nhập, tạo đơn, sửa thông tin, tìm kiếm — gần như mọi chức năng đều có một form ở giữa.
Nó cũng là chỗ lỗi tụ nhiều nhất, vì phần "chạy được" thì rất nhanh xong: gõ vào, bấm gửi, chạy. Phần còn lại — nhập sai thì sao, để trống thì sao, nhập quá dài thì sao — mới chiếm hầu hết công sức, và là phần hay bị làm cho có.
Đây là tám nhóm kiểm tra, xếp theo thứ tự nên chạy.
Chạy checklist là phần thực hiện — nhóm việc thứ ba trong bốn nhóm việc của một tester. Ba nhóm còn lại ở Manual testing là gì.
Vì sao thứ tự quan trọng
Chạy theo thứ tự này thì lỗi chặn đường xuất hiện sớm. Test sâu vào nhóm 5 rồi mới phát hiện form không gửi được là mất công vô ích — mọi kết quả trước đó phải kiểm lại sau khi lỗi chặn được sửa.
1. Đường đi đúng
Chạy trước tiên, vì nếu nó không chạy thì bảy nhóm sau chưa cần bắt đầu.
- Nhập đúng hết mọi ô, gửi thành công
- Dữ liệu lưu xuống đúng như đã nhập — mở lại xem, đừng chỉ tin thông báo
- Có thông báo thành công, và thông báo nói rõ điều gì đã xảy ra
- Sau khi gửi, người dùng được đưa tới đúng chỗ
Gạch đầu dòng thứ hai đáng nhấn: thông báo "Lưu thành công" không chứng minh dữ liệu đã lưu đúng. Mở lại bản ghi và đối chiếu từng ô.
2. Ô bắt buộc
- Để trống từng ô bắt buộc rồi gửi — phải bị chặn
- Để trống tất cả rồi gửi — phải bị chặn
- Thông báo lỗi chỉ rõ ô nào thiếu, không chỉ nói "vui lòng nhập đầy đủ"
- Ô không bắt buộc để trống vẫn gửi được
Nhóm này nhanh và gần như luôn ra lỗi ở lần test đầu của một form mới.
3. Kiểu dữ liệu
- Ô số: nhập chữ
- Ô số: nhập số âm, số thập phân, số
0 - Ô ngày: ngày không tồn tại (30/02), ngày trong quá khứ, ngày rất xa trong tương lai
- Ô email: chuỗi không có
@, có hai@, có dấu cách ở giữa - Ô điện thoại: nhập chữ, nhập dấu cách giữa các số, nhập dấu
+ở đầu
Ô ngày và ô điện thoại là hai chỗ ra lỗi nhiều nhất trong nhóm này, vì cả hai đều có nhiều cách viết hợp lệ mà lập trình viên thường chỉ nghĩ tới một cách.
4. Giá trị ở biên
Nhóm cho ra nhiều lỗi nhất so với công bỏ ra.
- Đúng số ký tự tối thiểu, và thiếu một ký tự
- Đúng số ký tự tối đa, và thừa một ký tự
- Chuỗi rỗng, và chuỗi chỉ gồm dấu cách
- Một ký tự duy nhất
Lý do nhóm này hiệu quả: lỗi lập trình ở biên thường là viết dấu lớn hơn thay vì lớn hơn hoặc bằng. Một ký tự lệch, và giới hạn sai đúng một đơn vị. Không ai phát hiện được điều đó bằng cách nhập một giá trị ở giữa.
Nếu chỉ có thời gian cho một nhóm, chọn nhóm này.
5. Ký tự đặc biệt và tiếng Việt
Nhóm này quan trọng riêng với sản phẩm tiếng Việt, và tài liệu nước ngoài không nói tới.
- Chữ có dấu ở mọi ô chữ — kiểm cả lúc lưu, lúc hiện lại, và lúc xuất ra file
- Chữ có dấu trong ô sẽ thành đường dẫn hoặc tên file
- Ký tự đặc biệt:
< > & " ' - Emoji
- Dấu cách ở đầu và cuối — có bị tự xoá không, và có nên bị xoá không
Gạch đầu dòng thứ nhất có ba chỗ kiểm chứ không phải một, và chỗ thứ ba là chỗ hay vỡ nhất. Chữ hiện đúng trên web nhưng thành ký tự lạ khi xuất Excel là lỗi rất phổ biến, vì hai chỗ đó dùng cách mã hoá chữ khác nhau.
Nhóm ký tự < > & " ' không chỉ là chuyện hiển thị. Chúng là ký tự có ý nghĩa đặc biệt trong HTML, nên nếu hệ thống xử lý sai thì hậu quả có thể là lỗ hổng, không chỉ là chữ hiện lệch.
6. Cách người dùng thật hay làm
- Bấm nút gửi hai lần liên tiếp, thật nhanh — có tạo hai bản ghi không
- Bấm Back của trình duyệt giữa luồng, rồi quay lại
- Tải lại trang khi đang nhập nửa chừng
- Dán nội dung từ Word vào — thường mang theo định dạng ẩn
- Điền form bằng tính năng tự động điền của trình duyệt
- Đi hết form chỉ bằng bàn phím, dùng Tab — thứ tự Tab có hợp lý không
Gạch đầu dòng đầu tiên là lỗi hay gặp và hậu quả thật: hai đơn hàng, hai lần trừ tiền. Nó xảy ra vì người dùng bấm lần đầu, không thấy phản hồi ngay, và bấm lại.
Gạch đầu dòng cuối là chuyện tiếp cận. Có người dùng bàn phím vì không dùng được chuột, và thứ tự Tab nhảy lộn xộn khiến form không dùng nổi.
7. Giao diện và thông báo
- Thông báo lỗi hiện gần ô bị lỗi, không chỉ ở đầu trang
- Nội dung đã nhập có được giữ lại sau khi báo lỗi
- Ô nhập dài quá thì chữ có tràn ra ngoài không
- Xem trên màn hình điện thoại
- Phóng to trang lên 200% — bố cục có vỡ không
Gạch đầu dòng thứ hai đáng để tranh luận nếu bị coi là lỗi nhỏ. Một form dài mà mất hết nội dung sau khi báo lỗi là lý do người dùng bỏ giữa đường — hậu quả thật, không phải chuyện thẩm mỹ.
8. Những thứ ở dưới bề mặt
- Chặn ở phía trình duyệt có được chặn lại ở phía máy chủ không
- Mất mạng giữa lúc gửi
- Phiên đăng nhập hết hạn rồi mới bấm gửi
Gạch đầu dòng đầu tiên là mục quan trọng nhất trong cả checklist.
Nếu form chỉ kiểm tra ở phía trình duyệt, người ta gửi thẳng yêu cầu tới máy chủ và mọi quy tắc biến mất — nhập được số âm, chuỗi dài vô hạn, ký tự bất kỳ. Đây không phải lỗi giao diện. Đây là lỗ hổng, và nó không thể phát hiện được bằng cách test qua giao diện.
Cách kiểm: gửi yêu cầu trực tiếp bằng một công cụ gọi API, với đúng giá trị mà form không cho nhập.
Cách dùng checklist này cho đúng
Đừng chạy hết tám nhóm cho mọi form. Sẽ không ai làm nổi, và làm cho có thì vô nghĩa.
Cách dùng: đọc qua cả tám nhóm, chọn nhóm nào có rủi ro thật với form đang có trước mặt.
Form đăng ký tài khoản của người dùng bên ngoài thì nhóm 8 quan trọng nhất — nó là cửa vào hệ thống. Form tìm kiếm nội bộ cho nhân viên thì nhóm 5 và 6 đáng đầu tư hơn, vì rủi ro bảo mật thấp mà rủi ro dữ liệu tiếng Việt cao.
Hai nhóm nên chạy bất kể form gì: nhóm 1 và nhóm 4. Một cái vì không chạy được thì không cần test tiếp; một cái vì nó rẻ và hiệu quả nhất.
Nói lại một câu
Checklist không thay được việc nghĩ. Nó chỉ đảm bảo bạn không bỏ sót nhóm nào vì đang nghĩ dở.
Đọc qua tám nhóm, chọn cái đáng, ghi lại cái đã bỏ và vì sao. Câu cuối quan trọng: bỏ có ý thức là quyết định, bỏ vì quên là sơ hở.
