Kiểm thử luồng xác minh email là công việc tưởng nhỏ nhưng lại nằm ở đúng cửa vào của sản phẩm: nếu bước này hỏng, người dùng mới không bao giờ tới được phần còn lại. Bài này đi qua các bước của một luồng xác minh, liệt kê những trường hợp cần phủ, và chỉ ra vì sao trường hợp “thư không tới” lại quan trọng ngang với trường hợp thành công.
Luồng xác minh thư gồm những bước nào?
Một luồng xác minh điển hình bắt đầu khi người dùng nhập địa chỉ và gửi biểu mẫu. Hệ thống ghi lại địa chỉ ở trạng thái chưa xác minh, tạo một dấu hiệu nhận biết riêng cho lần xác minh này, rồi gửi một lá thư chứa liên kết kèm dấu hiệu đó tới địa chỉ vừa nhập.
Người dùng mở hộp thư, bấm liên kết, và trình duyệt quay lại hệ thống với dấu hiệu trong đường dẫn. Hệ thống đối chiếu dấu hiệu, kiểm tra xem nó còn hiệu lực và còn thuộc về tài khoản đang chờ hay không, rồi chuyển trạng thái sang đã xác minh. Từ đó người dùng được coi là chủ sở hữu thật của địa chỉ.
Cùng khuôn mẫu này còn xuất hiện ở hai chỗ khác: khi người dùng đổi địa chỉ thư trong phần cài đặt, và khi đổi mật khẩu. Cả hai đều cần một bước xác nhận qua thư, vì cả hai đều có thể bị lợi dụng nếu kẻ khác chiếm được phiên đăng nhập. Điểm chung là mọi luồng đều có một trạng thái trung gian, và trạng thái trung gian là nơi lỗi hay trú ngụ.
Cần kiểm thử những trường hợp nào?
Danh sách dưới đây là những trường hợp nên có mặt trong bộ kiểm thử của bất kỳ luồng xác minh nào.
- Đường thành công: nhập địa chỉ, nhận thư, bấm liên kết, tài khoản chuyển sang đã xác minh.
- Liên kết đã hết hạn: mở liên kết sau khi dấu hiệu hết hiệu lực, hệ thống phải báo rõ ràng và cho gửi lại thư.
- Bấm liên kết hai lần: lần thứ hai không được gây lỗi, không được tạo tài khoản thứ hai, và vẫn phải dẫn người dùng tới trạng thái đúng.
- Đổi trình duyệt hoặc thiết bị: mở liên kết trên máy khác với máy đã đăng ký. Kết quả phải hợp lý và giải thích được cho người dùng.
- Hai tài khoản dùng chung một địa chỉ: xác minh cho tài khoản thứ hai không được vô tình xác minh luôn tài khoản thứ nhất.
- Nhập sai địa chỉ: thư không tới nơi, và hệ thống phải cho sửa lại địa chỉ chứ không khóa người dùng ở trạng thái chờ.
- Yêu cầu gửi lại nhiều lần: phải có giới hạn, và thư cũ không được tiếp tục dùng được như thư mới nếu thiết kế của bạn chỉ cho phép một dấu hiệu tại một thời điểm.
Với mỗi trường hợp, hãy ghi lại hai thứ: màn hình người dùng nhìn thấy và trạng thái lưu trong hệ thống. Một luồng xác minh hỏng thường hỏng ở chỗ hai thứ này không còn khớp nhau.
Vì sao phải kiểm thử cả trường hợp thư không tới?
Vì đó là trường hợp xảy ra thường xuyên nhất ngoài đời thật. Thư có thể bị chặn ở bên nhận, có thể vào thư rác, có thể tới muộn hơn người dùng mong đợi, hoặc đơn giản là người dùng gõ nhầm một ký tự khi đăng ký. Nếu bạn chỉ thử đường thành công, bạn sẽ không biết sản phẩm của mình cư xử thế nào trong những lúc đó.
Một luồng tốt phải trả lời được ba câu hỏi. Thứ nhất, người dùng có được nói rõ ràng rằng thư đã được gửi và cần kiểm tra hộp thư hay không, thay vì nhìn màn hình trống rồi không biết làm gì. Thứ hai, có cách yêu cầu gửi lại và cách sửa lại địa chỉ hay không. Thứ ba, sau khi chờ quá lâu, hệ thống có cho phép bắt đầu lại hay không.
Trường hợp này cũng là chỗ dễ lộ lỗi bảo mật nhất. Nếu thông báo lỗi cho biết địa chỉ nào đã tồn tại trong hệ thống, kẻ xấu có thể dùng biểu mẫu đăng ký để dò xem một người nào đó có tài khoản hay không. Hãy kiểm thử cả những thông báo này, không chỉ kiểm thử đường thành công.
Vì sao phải thử bấm nhiều lần và đổi trình duyệt?
Bấm hai lần vào cùng một liên kết là chuyện rất bình thường: người dùng bấm xong không thấy phản hồi nên bấm lại, hoặc trình duyệt tải lại trang. Sản phẩm phải xử lý được việc này mà không tạo ra hai hành động. Cách kiểm tra đơn giản nhất là bấm liên kết hai lần liên tiếp và xem trạng thái tài khoản, số lượng bản ghi, và số thư được gửi lại.
Đổi trình duyệt cũng là tình huống thật: người dùng đăng ký trên máy tính rồi mở thư trên điện thoại. Liên kết vẫn phải hoạt động, vì dấu hiệu nằm trong đường dẫn chứ không nằm trong phiên đăng nhập. Nếu bạn phát hiện liên kết chỉ hoạt động trên đúng một trình duyệt, đó là dấu hiệu thiết kế đang trộn lẫn hai thứ không nên trộn.
Cuối cùng, hãy thử mở liên kết bằng một cửa sổ ẩn danh, tức là không có cookie nào cả. Trường hợp này mô phỏng người dùng đã xóa dữ liệu duyệt web, và nó thường phát hiện ra những chỗ mà hệ thống vô tình phụ thuộc vào phiên đăng nhập.
Dùng hộp thư tạm thời để thử luồng xác minh
Với những trường hợp không cần một hộp thư thật, công cụ email tạm thời của trang này cấp cho bạn một địa chỉ mới trong vài giây, đủ để chạy hết danh sách trường hợp ở trên mà không phải tạo tài khoản thư cho từng ca. Bạn có thể tạo nhiều địa chỉ khác nhau để tách riêng từng trường hợp, và mỗi ca kiểm thử có hộp thư của riêng nó.
Các hộp thư này chỉ dùng cho mục đích kiểm thử, không phải danh tính thật và không dùng để đăng ký những tài khoản bạn cần giữ. Khi luồng kiểm thử cần đọc thư rồi trích ra một dãy số, bài mã xác minh trong kiểm thử đầu-cuối nói tiếp phần đó.
Phần dành cho nhà phát triển
Phần lớn lỗi trong luồng xác minh đến từ chỗ dấu hiệu xác minh được thiết kế như một giá trị vĩnh viễn, trong khi nó phải là một giá trị dùng một lần có thời hạn. Vài điểm nên chốt khi viết:
- Dấu hiệu chỉ dùng được một lần. Sau lần dùng đầu tiên, nó phải bị vô hiệu, kể cả khi lần dùng đó thất bại giữa đường.
- Việc đối chiếu dấu hiệu phải kèm điều kiện về tài khoản và về mục đích. Một dấu hiệu sinh ra cho việc đổi mật khẩu không được dùng để xác minh địa chỉ.
- Thao tác xác minh phải chịu được việc gửi trùng. Người dùng bấm hai lần, gửi lại biểu mẫu, hoặc trình duyệt thử lại yêu cầu đều là chuyện thường.
- Mô hình trạng thái nên có ít nhất ba giá trị: chưa xác minh, đang chờ xác minh địa chỉ mới, và đã xác minh. Gộp chúng thành một cờ đúng sai sẽ khiến bạn không mô tả nổi trường hợp đổi địa chỉ.
- Khi dấu hiệu hết hiệu lực, thông báo cho người dùng phải kèm một đường thoát: gửi lại thư, hoặc nhập lại địa chỉ. Bế tắc là lỗi thiết kế chứ không phải lỗi nhỏ.
- Kiểm tra cả việc thay đổi địa chỉ khi tài khoản đã xác minh. Đây là trường hợp hay bị bỏ sót và cũng là trường hợp dễ tạo ra hai tài khoản trỏ về cùng một hộp thư.
Nếu bạn chạy kiểm thử tự động, hãy để mỗi ca tự tạo địa chỉ riêng thay vì dùng chung một hộp thư của nhóm. Kinh nghiệm này cũng đúng khi bạn chuyển sang thu thư ngay trong môi trường chạy tự động, như mô tả trong bài thu thư trong môi trường tích hợp liên tục.
Bước tiếp theo
Hãy lấy danh sách trường hợp ở trên và biến nó thành một bảng kiểm thử thật sự có người chịu trách nhiệm từng dòng. Nếu bạn cần một địa chỉ để bắt đầu ngay bây giờ, mở công cụ email tạm thời, tạo một hộp thư, và chạy thử trường hợp đầu tiên trước khi làm phần còn lại.