1) Chuẩn bị trước khi test

1.1. Mục tiêu & phạm vi

• Signup: đăng ký bằng email + mật khẩu, hoặc email-only (magic link), hoặc social + xác minh email bổ sung.
• OTP: mã 4/6 số, link xác minh, hoặc combo (link + OTP dự phòng).
• Resend: gửi lại OTP, đổi email, hủy yêu cầu cũ.
• Khóa bảo vệ: rate limit, chống spam, captcha (nếu có).
• Trạng thái tài khoản: verified/unverified, pending, blocked, duplicate.

1.2. Dữ liệu test & cấu hình

• Chuẩn bị ít nhất 3 nhóm email: email tạm, email thật, email doanh nghiệp (nếu có thể) để so sánh deliverability.
• Xác định rõ cấu hình OTP: thời hạn, độ dài, số lần nhập sai, cooldown resend, max resend.
• Biết cơ chế xác minh: OTP trên màn hình hay OTP qua email, link click hay auto-verify khi nhập mã.
• Kiểm tra môi trường: staging/prod-like, mail provider, template email, domain gửi, DKIM/SPF/DMARC (nếu team có theo dõi).

1.3. Quan sát & đo lường trong quá trình test

• Log server: request tạo OTP, request verify, resend, lỗi provider, latency.
• Event tracking: signup_started, otp_sent, otp_delivered, otp_verified, otp_failed, otp_expired, resend_clicked.
• UI states: loading, disabled button, error copy, success state, chuyển màn hợp lý.
• Timing: đo thời gian email đến (từ lúc bấm gửi đến lúc thấy email trong inbox), và thời gian verify end-to-end.

2) Checklist UI/UX cho Signup

2.1. Form validation (client + server)

• Email hợp lệ: định dạng chuẩn, trim khoảng trắng đầu/cuối, không nhận ký tự lạ.
• Case-insensitive: cùng một email viết hoa/thường không tạo trùng tài khoản.
• Mật khẩu: rule rõ ràng (min length, complexity), hiển thị lỗi dễ hiểu, không “mắng” người dùng.
• Nút submit: disabled khi thiếu trường, có loading khi gửi, ngăn double click tạo nhiều request.
• Thông báo lỗi: phân biệt lỗi mạng, lỗi validation, lỗi server, và lỗi “email đã tồn tại”.

2.2. Trạng thái & điều hướng

• Sau khi signup: điều hướng đúng tới màn OTP/Verify, không bị quay lại form trống.
• Refresh trang: trạng thái signup/verify có được giữ không? (token tạm, session, local storage).
• Nút “Đổi email”: có cho đổi không, đổi xong OTP cũ có bị hủy không.
• Nút “Gửi lại mã”: hiển thị countdown, khóa nút hợp lý để tránh spam.
• Ngôn ngữ: copy tiếng Việt tự nhiên, không dịch máy quá cứng; giữ tone lịch sự, rõ ràng.

3) Checklist OTP/Email Verification — Happy Path (luồng thành công)

1. Tạo email tạm và giữ tab inbox mở (để tránh mất phiên ở một số dịch vụ).
2. Signup với email tạm, xác nhận request tạo OTP được gửi (UI hiển thị “đã gửi” + countdown).
3. Kiểm tra inbox:
   • Email đến trong thời gian hợp lý.
   • Tiêu đề, tên sản phẩm, và nội dung hiển thị đúng, không bị cắt xén kỳ lạ trên mobile.
   • OTP hiển thị rõ ràng, không lẫn với text khác; nếu là link verify thì link mở đúng trang.
4. Verify:
   • Nhập OTP đúng hoặc click link: hệ thống chuyển trạng thái verified, điều hướng vào app.
   • Không tạo lỗi “đã xác minh rồi” trong lần verify đầu.
   • Session/token sau verify hoạt động, không bị logout bất ngờ.
5. Kiểm tra hậu xác minh:
   • Tài khoản hiển thị trạng thái verified trong profile/account settings.
   • Nếu có onboarding: bước tiếp theo hoạt động bình thường.
   • Không còn bị ép verify lại ngay khi vào app.

4) Checklist Resend OTP — Các tình huống quan trọng nhất

4.1. Resend khi chưa nhận email

• Nút resend chỉ bật sau countdown; trước đó phải disabled và có giải thích.
• Resend tạo OTP mới: OTP cũ phải bị vô hiệu hóa (nếu đây là yêu cầu bảo mật).
• Email resend có phân biệt “mã mới” và không gây nhầm lẫn với email trước đó.
• Resend nhiều lần liên tiếp: hệ thống rate limit rõ ràng (UI báo “vui lòng thử lại sau”).

4.2. Resend sau khi đã nhận OTP cũ

• Nếu user nhập OTP cũ sau resend: phải báo “mã không còn hiệu lực” hoặc “mã đã được thay thế”.
• Nếu chính sách cho phép OTP cũ còn hạn: phải thống nhất, không lúc được lúc không.
• Verify thành công với OTP mới: trạng thái verified cập nhật chuẩn, không tạo 2 record xác minh.

4.3. Thay đổi email giữa chừng

• Đổi sang email tạm khác: OTP cũ phải bị hủy, và UI phải phản ánh email mới.
• Tránh lỗi: resend vẫn gửi về email cũ dù UI hiển thị email mới.
• Chặn lộ thông tin: khi đổi email, không hiển thị full email cũ trong UI/log client.

5) Negative Tests — Lỗi phổ biến & tiêu chí pass/fail

5.1. OTP sai / nhập sai nhiều lần

• Nhập sai 1 lần: báo lỗi nhẹ nhàng, không tiết lộ “mã gần đúng”.
• Nhập sai nhiều lần: khóa tạm thời theo chính sách, UI báo rõ thời gian chờ.
• Không để user brute-force: request verify phải có throttling ở server.

5.2. OTP hết hạn

• Nhập OTP sau khi hết hạn: thông báo “mã đã hết hạn”, kèm CTA resend.
• Đảm bảo countdown trên UI khớp với server (tránh lệch giờ client).
• Không xảy ra trạng thái “đã verify” dù OTP đã hết hạn.

5.3. Duplicate account / email đã tồn tại

• Thông báo không làm lộ dữ liệu: tránh kiểu “email này đã đăng ký” trong bối cảnh nhạy cảm nếu sản phẩm yêu cầu bảo mật cao.
• Nếu cho phép: cung cấp luồng “đăng nhập” hoặc “quên mật khẩu” rõ ràng.
• Không tạo thêm user record “ảo” trong DB khi signup fail.

5.4. Lỗi mạng / timeout / provider error

• Khi provider email chậm: UI không treo vô hạn; có retry guidance.
• Khi resend: nếu request fail, UI phải trả về trạng thái đúng, không “ảo” rằng đã gửi thành công.
• Không hiển thị stack trace hoặc thông tin nội bộ trên client.

6) Edge Cases nâng cao: Multi-device, timezone, session & deep link

6.1. Multi-device / multi-tab

• Signup trên máy A, mở email trên máy B: link verify có hoạt động không?
• Hai tab cùng màn OTP: resend ở tab 1, verify ở tab 2 có tạo trạng thái không nhất quán không?
• Đăng ký nhiều lần nhanh: hệ thống có tạo spam OTP không, có block hợp lý không?

6.2. Timezone & đồng bộ thời gian

• Thiết bị đặt timezone khác: OTP expiry tính theo server, UI vẫn hiển thị đúng.
• Đổi giờ hệ thống trong lúc countdown: UI không được “lệch nhịp” so với server.

6.3. Deep link / universal link

• Click verify link trên mobile: mở app đúng màn, không rơi vào browser loop.
• Nếu app chưa cài: mở web fallback, verify xong điều hướng hợp lý.
• Link hết hạn: thông báo rõ và có hướng dẫn resend.

7) Deliverability & Email Content QA — Không chỉ “gửi được” là đủ

Với email tạm, đôi khi email đến chậm hoặc bị chặn theo miền. Đây là lúc QA cần tách hai vấn đề: hệ thống có gửi và người nhận có nhận. Bạn nên kiểm tra cả hai.

7.1. Template & hiển thị

• Subject rõ: “Mã xác minh” hoặc “Verify your email” (nếu đa ngôn ngữ).
• OTP dễ đọc: font rõ, tách từng ký tự hoặc có spacing hợp lý.
• Tránh đưa OTP vào hình ảnh: nhiều hệ thống email chặn ảnh, user sẽ không thấy mã.
• CTA link đủ lớn, rõ ràng; có text fallback nếu user không click được.
• Không lộ dữ liệu nhạy cảm trong email: không gửi mật khẩu, không gửi token dài dễ bị lộ.

7.2. Latency & retry

• Đo thời gian email đến trong các thời điểm khác nhau (giờ cao điểm/thấp điểm).
• Kiểm tra resend: email mới có đến nhanh hơn hay chậm hơn? có “dồn” cùng lúc không?
• Nếu email đến trễ hơn thời hạn OTP: đây là lỗi trải nghiệm nghiêm trọng, cần điều chỉnh expiry hoặc pipeline gửi.

8) Bảo mật & chống lạm dụng: QA cần nhìn vào đâu?

• Rate limit: signup/otp/resend/verify đều cần giới hạn theo IP, theo email, theo device fingerprint (tùy sản phẩm).
• Enumeration: tránh để attacker đoán email tồn tại hay không qua thông báo khác nhau.
• Token handling: OTP/token không được log ra console client hoặc gửi qua query string dài dễ bị lưu lịch sử.
• Session fixation: verify xong nên rotate session/token để giảm rủi ro chiếm phiên.
• Replay: OTP/link verify dùng một lần; verify xong click lại phải ra thông báo hợp lý.

Với disposable email, kẻ xấu có thể tạo nhiều tài khoản nhanh. Vì vậy QA nên test cả khả năng “chịu tải” của hệ thống xác minh, và chất lượng phản hồi UI khi bị chặn hoặc yêu cầu thêm bước xác thực.

9) Tiêu chí hoàn tất (Definition of Done) cho Signup + OTP

• Happy path chạy ổn định, không phụ thuộc may rủi vào tốc độ email.
• Resend hoạt động đúng, OTP cũ xử lý nhất quán theo chính sách.
• Negative cases có thông báo rõ ràng, không lộ thông tin nội bộ.
• Multi-tab/multi-device không tạo trạng thái sai hoặc crash.
• Logging/metrics đủ để truy vết: biết OTP gửi lúc nào, verify lúc nào, fail vì lý do gì.
• Email template rõ ràng, OTP dễ đọc, link verify không gây loop hoặc dead-end.

10) Checklist rút gọn để dán vào ticket QA

• Signup form validation + loading + double submit protection
• OTP sent state + countdown + resend cooldown + max resend
• OTP đúng/sai/hết hạn + lockout + server throttling
• Resend tạo OTP mới + vô hiệu OTP cũ + copy lỗi rõ
• Đổi email giữa chừng + hủy request cũ + UI đồng bộ
• Multi-tab/multi-device + deep link/universal link
• Email template: subject, OTP readability, link fallback, no sensitive data
• Deliverability: latency đo được + xử lý chậm + retry guidance
• Security: enumeration, replay protection, token/session rotation
• Metrics/logging: event đầy đủ để phân tích funnel

Nếu bạn áp checklist này đều tay, team sẽ giảm được phần lớn lỗi “người dùng kẹt OTP”, đồng thời tối ưu trải nghiệm đăng ký theo đúng hành vi thực tế: đăng ký nhanh, xác minh gọn, và không để spam làm bẩn email chính của người dùng.