Hãy hỏi bất kỳ kỹ sư QA nào về nơi những lỗi khó chịu nhất ẩn náu, và họ sẽ nói với bạn cùng một điều: không phải ở đường đi thuận lợi cho một người dùng, mà ở khoảng không gian giữa những người dùng. Hai người đăng ký ngay cùng một khoảnh khắc. Một email lời mời gửi đến nhầm người. Một quản trị viên và một thành viên chỉ có quyền đọc cùng tải một trang, và một trong hai người thấy thứ mà lẽ ra họ không được thấy. Không điều nào trong số đó tái hiện được khi bạn kiểm thử một mình với địa chỉ email của chính mình, vì trong cơ sở dữ liệu bạn chỉ luôn là một người dùng.

Các sản phẩm thực tế vốn có bản chất nhiều người dùng — nhóm, không gian làm việc, vai trò, lời mời, giới thiệu, tenant. Để kiểm thử những luồng đó một cách trung thực, bạn cần vài hộp thư riêng biệt, có thể nhận thư cùng lúc. Đây là nơi một hộp thư dùng một lần lặng lẽ trở thành một trong những công cụ hữu ích nhất trong bộ đồ nghề của người kiểm thử, và đó là một trường hợp sử dụng chẳng liên quan gì đến việc trốn tránh thư rác.

Vì sao một hộp thư thật (hay một Gmail QA dùng chung) là không đủ

Vấn đề với địa chỉ của chính bạn rất đơn giản: nó đã tồn tại trong hệ thống. Bạn không thể mô phỏng "một người dùng hoàn toàn mới chưa từng được thấy trước đây" khi bản ghi của bạn đã có trong cơ sở dữ liệu, và bạn chắc chắn không thể là ba người dùng mới khác nhau cùng lúc. Các nhóm thường quay sang một tài khoản Gmail QA dùng chung và dựa vào địa chỉ có dấu cộng — [email protected], [email protected] và cứ thế. Nó hoạt động cho đến khi không còn hoạt động: khá nhiều ứng dụng loại bỏ hoặc chuẩn hóa thẻ +, một số từ chối thẳng thừng, và ngay cả khi được chấp nhận, mọi tin nhắn vẫn rơi vào một hộp thư mà sau đó bạn phải gỡ rối để tìm ra "người dùng" nào đã nhận cái gì.

Để kiểm thử nhiều người dùng thực sự, bạn muốn những hộp thư thực sự tách biệt — địa chỉ tách biệt, hộp thư tách biệt, không có trạng thái dùng chung. Đó chính xác là thứ bạn có được khi mở vài tab.

Hộp thư dùng một lần phù hợp ở đâu trong QA

Mỗi tab trên temp mail là một hộp thư hoàn toàn độc lập với địa chỉ riêng, duy nhất của nó. Mở ba tab và bạn có ba người dùng thật để gửi đến và nhận từ — không tạo tài khoản, không có hộp thư dùng chung phải dọn dẹp sau đó, và vì mỗi địa chỉ được tạo mới, không có trạng thái sót lại từ lần chạy thử hôm qua làm mờ kết quả hôm nay. Khi bạn xong việc, mọi thứ tự động xóa sau một giờ, nên bạn không tích lũy một nghĩa địa các tài khoản kiểm thử gắn với email cá nhân của mình.

Những kịch bản nhiều người dùng thực sự đáng kiểm thử

Đây là những luồng mà việc có vài hộp thư đang hoạt động cạnh nhau sẽ mang lại lợi ích — những luồng lặng lẽ hỏng trong môi trường sản xuất vì trước khi phát hành không ai dễ dàng tái hiện được chúng:

• Lời mời vào nhóm và không gian làm việc: Người dùng A tạo một không gian làm việc và mời B và C. Mỗi lời mời phải đến đúng địa chỉ với một liên kết hoạt động, được tạo an toàn, và việc chấp nhận nó phải đưa mỗi người vào đúng không gian làm việc với đúng vai trò. Theo dõi cả ba hộp thư cùng lúc và bạn sẽ phát hiện ngay một lời mời đi sai đường.
• Vai trò và quyền: Đăng ký một chủ sở hữu, một quản trị viên, và một thành viên chỉ đọc như ba người dùng riêng biệt. Rồi xác nhận mỗi người thấy — và không thể thấy — đúng những gì vai trò của họ cho phép. Lỗi phân quyền là vô hình cho đến khi bạn thực sự đăng nhập với tư cách người dùng có quyền thấp hơn, lý tưởng là cùng lúc với người có quyền cao hơn. Bảng tổng hợp về Ủy quyền của OWASP là một danh sách kiểm tra tốt cho những gì cần dò xét ở đây.
• Xử lý tài khoản trùng lặp: Đăng ký hai tài khoản với các địa chỉ khác nhau, rồi thử dùng lại một trong số đó. Ứng dụng có phát hiện bản trùng theo cách bạn mong đợi không? Còn cùng một địa chỉ nhưng viết hoa thường khác nhau, hoặc có một dấu chấm thừa ở cuối thì sao? Các địa chỉ mới làm cho những trường hợp biên này trở nên cực kỳ dễ thiết lập.
• Luồng giới thiệu và thưởng lời mời: Người giới thiệu thường chỉ được ghi công sau khi người được giới thiệu đăng ký và xác minh. Bạn cần hai hộp thư thật để theo dõi cả hai phía kích hoạt — lời mời gửi đi, và phần thưởng đến (hoặc đúng là không đến) một khi người dùng thứ hai hoàn thành luồng.
• Cô lập đa tenant: Tạo tài khoản trong hai tổ chức riêng biệt và xác nhận rằng dữ liệu của một tenant không bao giờ rò rỉ sang màn hình, thông báo, hay email của tenant kia — đúng loại lỗi mà hướng dẫn của NIST về đa tenant trên đám mây đặc biệt chỉ ra. Một địa chỉ đi lạc vào hộp thư sai thường là dấu hiệu hữu hình đầu tiên của một lỗi cô lập dữ liệu.
• Đăng ký đồng thời: Đăng ký vài người dùng trong cùng một giây để làm lộ ra các tình huống tranh chấp (race condition) trong việc tạo token, xung đột ràng buộc duy nhất, và độ trễ hàng đợi khiến một số email xác minh đến muộn hơn hẳn so với những email khác.
• Giới hạn chỗ ngồi và gói: Lấp đầy một gói đến mức giới hạn chỗ ngồi bằng các người dùng khác nhau, rồi thử thêm một người nữa. Giới hạn đó phải giữ được — và lỗi mà người dùng thừa gặp phải phải rõ ràng, không phải một lỗi 500.
• Phân phát thông báo: Kích hoạt một hành động trong một tài khoản và xác nhận đúng những đồng đội — và chỉ họ — nhận được email thông báo. Rất dễ vô tình gửi email cho tất cả mọi người, hoặc chẳng ai cả.

Một quy trình làm việc giúp mọi thứ trong tầm kiểm soát

Mẹo thực tế là đối xử với mỗi tab như một nhân vật có tên trong bài kiểm thử của bạn. Mở một tab cho mỗi người dùng và quyết định trước ai là ai — Chủ sở hữu, Quản trị viên, Thành viên — rồi sao chép từng địa chỉ vào lần đăng ký của riêng nó. Sắp xếp các tab để bạn có thể thấy chúng chỉ trong một cái liếc. Vì việc gửi thư thực tế là tức thời, bạn sẽ thấy lời mời đến ngay khoảnh khắc bạn gửi nó, điều này làm cho nhân và quả trở nên rõ ràng theo cách mà việc kiểm tra định kỳ một hộp thư dùng chung không bao giờ làm được.

Ghi lại địa chỉ ngẫu nhiên nào ánh xạ tới vai trò nào bên cạnh các bước kiểm thử của bạn — các địa chỉ được tạo ra, không phải chọn, nên một ghi chú nhanh giúp tránh nhầm lẫn về sau. Và phần thưởng: ngay khoảnh khắc một email xuất hiện ở tab sai, bạn đã bắt được một lỗi định tuyến hoặc cô lập tại chỗ, từ lâu trước khi nó biến thành một phiếu hỗ trợ.

Cần kiểm tra gì khi thư đến

Nhận được email chỉ mới là một nửa. Khi một tin nhắn đến, hãy dành vài giây để thực sự xác minh nó:

• Đúng người nhận: Lời mời có đến đúng địa chỉ được mời — và không đến bất cứ nơi nào khác không?
• Đúng liên kết: URL chấp nhận hoặc xác minh có trỏ đến đúng môi trường và mang đúng ngữ cảnh không gian làm việc và vai trò không, chứ không phải một liên kết sản xuất được mã hóa cứng?
• Đúng trạng thái kết quả: Sau khi chấp nhận, người dùng mới có ở đúng tổ chức với đúng những quyền mà vai trò của họ nên có không?
• Hiển thị: Email có trông đúng trong một hộp thư thật không — nút bấm được, tên người nhận được điền, không còn placeholder "Chào {{firstName}}" sót lại?
• Cô lập: Email của một người dùng có bao giờ nhắc đến dữ liệu của người dùng khác do nhầm lẫn không? Đó là một dấu hiệu đáng báo động nên truy tìm.
• Thời gian: Mọi thứ nên đến trong vài giây. Độ trễ nhất quán chỉ ra một vấn đề hàng đợi hoặc DNS mà người dùng thật của bạn cũng sẽ cảm nhận được.

Dữ liệu kiểm thử sạch, miễn phí

Một lợi ích bị đánh giá thấp: mỗi địa chỉ dùng một lần bắt đầu trống rỗng và biến mất sau một giờ, nên mỗi lần chạy bắt đầu từ một trạng thái sạch đã biết. Một bài kiểm thử bắt đầu từ "hộp thư đảm bảo trống, người dùng hoàn toàn mới" là một bài kiểm thử bạn thực sự có thể tin tưởng và chạy lại mà không phải băn khoăn liệu phần sót lại của tuần trước có làm lệch kết quả hay không. Khả năng lặp lại là một nửa của QA tốt, và bạn có được nó ở đây mà không phải dọn dẹp gì cả.

Tốt nhất cho các đợt kiểm thử khám phá và hồi quy trước khi phát hành

Cách tiếp cận này thực sự tỏa sáng trong lúc kiểm thử khám phá và đợt hồi quy thủ công trước một lần phát hành. Trong vài phút bạn có thể dựng nên một dàn người dùng nhỏ, thực tế — một chủ sở hữu, vài thành viên, một người được mời từ bên ngoài — và đi qua sản phẩm theo cách một nhóm thực sự sẽ làm, quan sát các email kích hoạt khi bạn thao tác. Đây là thứ gần nhất với "dùng ứng dụng như năm người khác nhau cùng lúc" mà không cần cung cấp năm hộp thư thật. Nếu bạn cũng đang kiểm thử các phần dành cho một người dùng, các hướng dẫn của chúng tôi về kiểm thử xác minh email và các luồng đặt lại mật khẩu kết hợp một cách tự nhiên với bài này.

Nơi cần thành thật về các giới hạn

Một vài điều đáng nói thẳng, vì giả vờ khác đi chỉ làm phí thời gian của bạn. Một số ứng dụng chặn các tên miền email dùng một lần đã biết ngay khi đăng ký — nếu biểu mẫu đăng ký của bạn từ chối địa chỉ đó, thì đó là chính sách của riêng ứng dụng, và với những bài kiểm thử cụ thể đó bạn có thể cần một tên miền nội bộ nằm trong danh sách cho phép thay thế. Đây cũng là một quy trình thủ công, khám phá: bạn đang điều khiển một trình duyệt, không gọi một API, nên nó bổ trợ cho các bài kiểm thử email đầu-cuối tự động trong CI chứ không thay thế chúng. Và trước khi bạn phát hành, hãy làm một đợt cuối với một hộp thư thật như Gmail hay Outlook — những đặc điểm về khả năng gửi đến và hành vi của thư mục spam chỉ tự lộ ra khi đối diện với các nhà cung cấp thật.

Bản ngắn gọn

Kiểm thử một hộp thư tìm ra các lỗi một người dùng. Những lỗi thực sự đến được môi trường sản xuất sống trong các khoảng trống giữa những người dùng — lời mời, vai trò, tenant, giới hạn, và tranh chấp. Hộp thư dùng một lần cho phép một người kiểm thử đóng vai cả một nhóm cùng lúc, với trạng thái sạch trong mỗi lần chạy, trong khoảng thời gian gần như chỉ để mở vài tab. Hãy vào temp-email.ai, mở một tab cho mỗi người dùng, và bắt đầu kiểm thử những kịch bản thực sự quan trọng.