“Email đã đến” không phải là kết quả kiểm thử đủ.
Một tin nhắn đăng ký có thể tới hộp thư với người nhận sai, liên kết đã hết hạn, bố cục di động bị hỏng, tên máy chủ sản xuất, hoặc tiêu đề không có nghĩa trong ngôn ngữ khác. Kiểm thử email tốt theo toàn bộ hành trình người dùng và để lại đủ bằng chứng để chẩn đoán lỗi.
Hộp thư tạm thời hữu ích ở đây vì mỗi lần chạy có thể bắt đầu với một địa chỉ sạch. Hộp thư nên có thể loại bỏ; kết quả kiểm thử không nên.
Xây dựng ma trận nhỏ, có chủ đích
Bắt đầu với các luồng có thể chặn người dùng:
- xác minh tài khoản mới;
- đặt lại mật khẩu;
- lời mời nhóm hoặc không gian làm việc;
- xác nhận thay đổi email;
- liên kết đăng nhập hoặc mã một lần;
- cảnh báo bảo mật sau hành động nhạy cảm.
Đối với mỗi luồng, kiểm thử đường đi hạnh phúc, một chứng chỉ đã hết hạn hoặc đã được sử dụng lại, và một lỗi phía người nhận. Điều này bắt được nhiều lỗi thực tế hơn so với việc gửi hàng chục tin nhắn cùng một đường đi hạnh phúc.
Sử dụng một hộp thư cho mỗi kịch bản
Việc tái sử dụng một địa chỉ duy nhất tạo ra sự mơ hồ. Một tin nhắn đặt lại cũ có thể bị nhầm lẫn với tin mới nhất, và các kiểm thử song song có thể tiêu thụ liên kết của nhau.
Tạo một địa chỉ duy nhất cho mỗi trường hợp kiểm thử hoặc mỗi lần chạy. Ghi lại nó cùng với số bản dựng, môi trường, ngôn ngữ, và kịch bản. Nếu kiểm thử thất bại, địa chỉ sẽ trở thành một phần của bằng chứng và có thể được kiểm tra trước khi thời gian lưu trữ hết hạn.
Không sử dụng địa chỉ khách hàng thực trong môi trường staging. Điều này gây rủi ro gửi tin nhắn không mong muốn, làm ô nhiễm phân tích, và khiến việc dọn dẹp tự động khó khăn.
Khẳng định phong bì trước nội dung
Trước khi nhấp bất kỳ thứ gì, hãy xác minh:
- Tin nhắn đã được gửi tới đúng địa chỉ được tạo cho kiểm thử này.
- Tên miền người gửi là tên miền mong đợi cho môi trường.
- Tiêu đề xác định hành động mà không tiết lộ dữ liệu nhạy cảm.
- Chỉ có số lượng tin nhắn dự kiến đã đến.
- Thời gian gửi muộn hơn thời điểm hành động kích hoạt nó.
Những kiểm tra này bắt các vấn đề định tuyến và trùng lặp trước khi bộ phân tích nội dung ẩn chúng.
Kiểm thử nội dung như người dùng nhìn thấy
Mở tin nhắn trên cả viewport hẹp và rộng. Kiểm tra rằng hành động chính hiển thị, phần dự phòng văn bản thuần hiểu được, và các địa chỉ hoặc URL dài không làm phá vỡ bố cục.
Đối với luồng dựa trên mã, xác minh rằng mã mới nhất hoạt động một lần và thất bại sau khi sử dụng. Đối với luồng dựa trên liên kết, xác nhận tên máy chủ và môi trường trước khi mở. Một tin nhắn staging trỏ tới production là một rào cản phát hành ngay cả khi liên kết hoạt động về mặt kỹ thuật.
Cũng kiểm tra các chi tiết ít hấp dẫn hơn: hành vi trả lời, thông tin liên hệ hỗ trợ, cách diễn đạt thời gian hết hạn, ngôn ngữ, và tên tài khoản hoặc không gian làm việc hiển thị trong tin nhắn.
Các trường hợp tiêu cực có giá trị
Các kiểm thử tiêu cực hữu ích bao gồm:
- yêu cầu mã thứ hai và xác nhận mã đầu tiên bị vô hiệu hoá;
- mở liên kết đã hết hạn;
- mở cùng một liên kết hai lần;
- thay đổi trạng thái tài khoản trước khi sử dụng tin nhắn;
- mời một địa chỉ đã thuộc về một thành viên;
- nhập địa chỉ không hỗ trợ hoặc sai định dạng;
- trì hoãn việc giao nhận đủ lâu để vượt qua thời gian hết hạn.
Các kiểm thử này phơi bày các điều kiện tranh chấp và thông báo lỗi gây hiểu lầm mà một kiểm tra hộp thư đơn giản sẽ không bao giờ phát hiện.
Tách lỗi sản phẩm khỏi độ trễ giao nhận
Khi một tin nhắn bị thiếu, lưu lại các dấu thời gian cho hành động người dùng, hàng đợi ứng dụng, chuyển giao nhà cung cấp, và thời gian tin nhắn đến hộp thư khi các tín hiệu này có sẵn. Một ảnh chụp màn hình hộp thư trống chỉ chứng minh rằng tin nhắn không hiển thị tại thời điểm đó.
Sử dụng chuỗi chẩn đoán trong Email Xác minh Không Đến: Tìm Bước Bị Lỗi trước khi tạo một vấn đề mơ hồ “email bị lỗi”.
Những gì nên tự động hoá
Tự động hoá các hợp đồng ổn định:
- tạo một địa chỉ duy nhất;
- kích hoạt hành động sản phẩm;
- poll với thời gian chờ có giới hạn và backoff;
- khớp người gửi và tiêu đề mong đợi;
- đọc tin nhắn phù hợp mới nhất;
- xác thực mã hoặc liên kết với sản phẩm;
- lưu lại bằng chứng thất bại hữu ích;
- dọn dẹp.
Giữ việc xem xét trực quan, chất lượng bản sao, và hành vi khách hàng bất thường trong một vòng kiểm tra thủ công tập trung. Tự động hoá tốt ở việc lặp lại, không phải ở vị giác.
Tự động hoá API Hộp thư tạm thời Đáng tin cậy bao gồm phía API, bao gồm poll và dọn dẹp.
Báo cáo thất bại hữu ích
Một báo cáo mà các nhà phát triển có thể hành động chứa kịch bản, môi trường, địa chỉ, thời gian kích hoạt, người gửi mong đợi, các tin nhắn quan sát được, thời gian poll cuối cùng, trạng thái phản hồi, và ảnh chụp màn hình hoặc trích đoạn thân tin đã được làm sạch. Không bao giờ đính kèm bí mật sống hoặc liên kết xác minh có thể tái sử dụng vào một vấn đề công khai.
Mục tiêu không phải chứng minh email không đáng tin cậy. Mục tiêu là xác định hợp đồng nào đã thất bại và để lại một con đường có thể tái tạo để sửa chữa.