1) टेस्ट सेटअप: शुरू करने से पहले क्या तैयार रखें

Test environment readiness

• Environment: staging/QA में email provider (SMTP/API) properly configured हो और production जैसी settings हों।
• Domain / Sender: From/Reply-To, DKIM/SPF/DMARC alignment की basic verification (कम से कम staging पर)।
• OTP नीति: OTP length, validity window, retry limit, lockout rules, resend interval स्पष्ट हों।
• Logs/Tracing: signup request, OTP generate, OTP send, OTP verify, rate-limit events सबके correlation IDs हों।
• Time sync: server clocks sync हों ताकि expiry/timestamps mismatch न हो।

Disposable email selection criteria

• Receive-only inbox preferable है ताकि abuse surface कम हो।
• Refresh/Reload behavior stable हो और messages reliably दिखें।
• Multiple domains उपलब्ध हों तो domain-level blocks का behavior टेस्ट कर सकते हैं।
• Expiry model समझें: inbox कब reset होता है, address reuse संभव है या नहीं।

2) Happy Path Checklist: Signup → OTP → Verified

A) Signup screen validations

• Email field: uppercase/lowercase handling, trimming, leading/trailing spaces removal।
• Invalid formats: missing @, multiple @, invalid TLD, unicode edge-cases (जहां applicable)।
• Disposable email address paste: mobile keyboard paste, clipboard permissions, input masks का behavior।
• CTA state: invalid input पर button disabled/inline error message UX consistent।

B) OTP भेजने के बाद expected UI

• “OTP sent” feedback: message, timer (यदि दिखाते हैं), resend button state।
• OTP entry: auto-focus, auto-advance (यदि multi-field), backspace behavior, paste full OTP।
• Loading states: verify press पर double-submit रोकना (button disabled + spinner)।
• Navigation: back करने पर state retain या reset—जो भी product निर्णय हो, consistent हो।

C) Email content checks (OTP Email)

• Subject line: स्पष्ट हो कि यह OTP/verification है, लेकिन sensitive details न हों।
• Body: OTP code readable, monospace styling (अगर संभव), copy-friendly।
• Localization: हिंदी copy, numerals formatting (देवनागरी/अरबी अंक नीति) consistent।
• Link-based OTP (यदि है): deep link / universal link का behavior सही हो।
• Accessibility: plain-text fallback मौजूद हो, images पर निर्भर न रहे।

D) Verification success

• Correct OTP पर success state immediate दिखे और next screen पर navigate हो।
• Server response delay में UI timeouts/ retry behavior graceful हो।
• Session/token issuance: login token, refresh token, device binding (अगर है) सही set हो।

3) Delivery & Timing: सबसे common failures की जांच

Email delivery latency tests

• OTP email arrival time measure करें: 5s, 15s, 30s, 60s पर inbox refresh करके observe करें।
• Provider delays simulate: staging में throttling/queueing scenarios (यदि संभव) check करें।
• Inbox refresh UX: user को “refresh” guidance है या auto-polling? दोनों में reliability देखें।

OTP validity window checks

• OTP expiry से पहले verify: pass।
• Expiry boundary: expiry के बिल्कुल पास verify attempt का outcome consistent हो (server authoritative)।
• Expired OTP: clear error message + resend path smooth।
• Clock skew: client time गलत होने पर भी server-side validation सही रहे।

4) Resend Flow: Rate limits, cooldown, और UX

Resend button behavior

• Cooldown timer: resend allowed से पहले button disabled रहे, UI में reason दिखे।
• Multiple taps protection: rapid click/press पर एक ही request जाए।
• Resend success: नया OTP generate हुआ या वही OTP re-sent? policy के अनुसार verify करें।
• Old OTP handling: अगर नया OTP generate होता है तो पुराना OTP invalid होना चाहिए (या policy के अनुसार)।

Rate-limit validation

• Same email पर N attempts के बाद: 429/limit error + next retry time messaging।
• IP-based limits: same IP से multiple accounts attempts पर throttling।
• Device-based limits (यदि लागू): emulator vs real device differences।
• Abuse signals: suspicious patterns पर silent hardening (captcha/extra step) का behavior।

5) Edge Cases: टूटने वाली जगहों को पहले पकड़ें

A) Email variations

• Plus addressing: name+tag@domain.com support/normalize rules (यदि supported) verify करें।
• Case-insensitivity: User@Domain.com को same account माना जाए या नहीं—spec के अनुसार।
• Internationalized email (यदि supported): unicode local-part/domain behavior verify करें।
• Disposable domain blocking: अगर आपका product disposable domains block करता है तो messaging और fallback path सही हो।

B) OTP input stress

• Wrong OTP: 1-2 बार गलत, फिर सही OTP—lockout policy के अनुसार pass हो या नहीं check करें।
• Too many attempts: max tries पर lock, cooldown, या step-up verification।
• Paste with spaces/newlines: OTP में whitespace sanitize हो।
• Non-numeric characters: अगर OTP numeric है तो alphabet paste पर validation सही हो।

C) Navigation & state

• App background/foreground: OTP screen पर लौटने पर timer और input state सही रहे।
• Refresh/Reload web: page reload पर state restore या restart—expected behavior match हो।
• Multiple tabs: एक tab से OTP request, दूसरे tab से verify—race conditions handle हों।
• Back button: OTP screen से वापस signup पर जाने पर resend/attempt counters leak न हों।

D) Email inbox expiry impact

• Disposable inbox expire होने पर user क्या देखता है? QA में इस scenario को intentionally reproduce करें।
• OTP late पहुंचे और inbox reset हो चुका हो: user journey में recovery path (resend/new address) स्पष्ट हो।
• Address reuse risk: अगर same address दोबारा मिलता है तो data leakage risk के against mitigation policies verify करें।

6) Security Checklist: OTP को safe बनाना

OTP flows केवल UX नहीं हैं, security perimeter भी हैं। Disposable email testing का फायदा यह है कि आप attackers जैसा व्यवहार simulate कर सकते हैं और frictionless abuse रोकने वाले controls verify कर सकते हैं।

A) OTP generation & storage

• OTP randomness: predictable sequence नहीं हो; sufficient entropy policy follow हो।
• Server-side hashing: OTP plaintext store न किया जाए (जहां संभव)।
• Single-use: verify होने के बाद OTP invalidate हो।
• Replay prevention: same OTP reuse attempt fail हो।

B) Enumeration resistance

• “Email exists” leakage न हो: signup/resend errors generic हों (जहां applicable)।
• Password reset/verify flows में अलग-अलग behavior से user enumeration आसान न बने।
• Response timing: exists vs not-exists पर बहुत अलग response time न हो।

C) Rate limiting & abuse controls

• OTP request limits: per email, per IP, per device—कम से कम दो स्तर।
• Verification limits: failed attempts पर step-up या temporary lock।
• Captcha/Challenge: suspicious patterns पर trigger होने का behavior test करें।
• Audit logs: security events (lockouts, rate limits) log हों और searchable हों।

7) Observability & Debugging: जब OTP नहीं आता तब क्या देखें

Client-side quick checks

• Email typo: spaces, hidden characters, clipboard artifacts।
• Resend cooldown: user जल्दी-जल्दी resend नहीं कर पा रहा—UX messaging स्पष्ट है?
• Inbox refresh: disposable inbox में refresh/polling सही काम कर रहा?
• Network: verify/resend endpoints पर 4xx/5xx errors तो नहीं?

Server-side checks

• OTP generate हुआ? event logs में OTP issued entry मौजूद हो।
• Email send triggered हुआ? provider request ID/correlation ID capture हुआ?
• Provider response: accepted/queued vs rejected vs bounced।
• Suppression list: previously bounced addresses suppress तो नहीं हो गए?
• Template rendering: subject/body placeholders सही resolve हो रहे?

Email provider side checks

• Rate limits: provider quota hits या throttling।
• Deliverability: staging domain reputation issues, sandbox mode misconfig।
• Spam filtering: content triggers, missing authentication records।
• Webhook callbacks: delivery/bounce events ingest हो रहे?

8) Regression Suite: हर रिलीज़ से पहले क्या दुहराएं

OTP flows में छोटे changes भी बड़ा impact ला सकते हैं—UI refactor, email template update, provider switch, rate-limit rules, या localization changes। इसलिए एक छोटा लेकिन मजबूत regression suite तय करना लाभदायक है।

Must-run scenarios

• New user signup → OTP delivered → verified → logged-in state confirmed।
• Resend OTP once → new OTP verify → old OTP invalid।
• Wrong OTP 2 बार → correct OTP → policy expected outcome verify।
• Expired OTP → error → resend → success।
• Multiple devices/tabs: OTP request और verify consistency।
• Localized email template: subject/body Hindi rendering + links formatting।

Nice-to-have scenarios

• Disposable domain blocked path: clear UX + alternative suggestion।
• Provider delay simulation: user guidance + no duplicate OTP confusion।
• High load: concurrent OTP requests behavior stable।

9) QA के लिए प्रैक्टिकल टेम्पलेट: टेस्ट केस लिखने का ढांचा

अगर आपकी टीम test management tool इस्तेमाल करती है, तो नीचे जैसा ढांचा consistency लाता है। आप इसे web/app दोनों पर apply कर सकते हैं।

Test case template

• Title: उदाहरण—“Signup OTP delivered within expected latency on disposable inbox”
• Preconditions: staging env, disposable email ready, clean user state
• Steps: signup → request OTP → open inbox → copy OTP → verify
• Expected: OTP arrives, UI errors none, verification success, session created
• Telemetry: correlation ID, provider message ID captured
• Notes: latency observed, resend tested, anomalies

10) निष्कर्ष: Disposable email के साथ QA क्यों मजबूत होता है

Disposable/Temporary Email आपको तेज़ iteration देता है—हर run में नई पहचान, कम clutter, और बेहतर coverage। लेकिन असली value तब आती है जब आप सिर्फ “OTP आया या नहीं” नहीं, बल्कि timing, retries, edge-cases, security controls और observability को भी systematically validate करते हैं। इस checklist को अपनी टीम के release pipeline में जोड़ें—और signup/OTP को एक बार सही करके बार-बार tickets से बचें।