QA के लिए परीक्षण ईमेल खाता कैसे चुनें
अस्थायी इनबॉक्स साइन-अप और OTP की खुद करके जाँच के लिए उपयुक्त है। जो परीक्षण बिना किसी व्यक्ति के चलते हैं, असली ग्राहक डेटा को छूते हैं, या जिनमें जवाब और अनुलग्नकों की ज़रूरत होती है, उनके लिए अलग तरह का परीक्षण इनबॉक्स चाहिए। हर परीक्षण के लिए सही विकल्प कैसे चुनें, यह यहाँ बताया गया है।
त्वरित पहुँच
QA के लिए परीक्षण ईमेल खाता क्या है?
परीक्षण ईमेल खाता, या QA के लिए परीक्षण ईमेल पता, वह पता है जिसका उपयोग आपकी टीम अपने ही एप्लिकेशन द्वारा भेजे गए ईमेल प्राप्त करने और जाँचने के लिए करती है। मैनुअल, गैर-संवेदनशील साइन-अप और OTP जाँच के लिए अस्थायी इनबॉक्स का उपयोग करें। संदेशों को सहेजने, उत्तर देने या अनुलग्नकों के लिए कंपनी का मेलबॉक्स चुनें, और जब स्वचालित परीक्षणों को बिना किसी व्यक्ति के ईमेल जाँचना हो तो SMTP सैंडबॉक्स या होस्टेड इनबॉक्स API चुनें।
यह ब्लॉग Tmailor चलाता है, इसलिए यहाँ बताया गया है कि यह कहाँ फिट बैठता है। Tmailor वेब, Android, iOS और Telegram बॉट पर एक मुफ़्त, केवल-प्राप्ति वाली अस्थायी मेल सेवा है। यह पहले मामले के लिए उपयुक्त है: कोई व्यक्ति इनबॉक्स खोलता है, साइन-अप ट्रिगर करता है और जो आता है उसे पढ़ता है। अंतिम मामले के लिए, अलग Tmailor Temp Mail API स्वचालित परीक्षणों को केवल-प्राप्ति वाले पते बनाने और कोड से उनके संदेश पढ़ने देता है। संदेश आने के लगभग 24 घंटे तक रहते हैं, अनुलग्नक प्राप्त नहीं होते, और पता भेज या उत्तर नहीं दे सकता। यदि आप अस्थायी इनबॉक्स में नए हैं, तो अस्थायी मेल कैसे काम करता से शुरू करें।
- किसी ईमेल के आने की आवश्यकता नहीं है (फ़ॉर्म सत्यापन, फ़िक्स्चर, यूनिट परीक्षण): आरक्षित उदाहरण डोमेन का उपयोग करें।
- कोई व्यक्ति ईमेल पढ़ता है और उसमें कुछ भी संवेदनशील नहीं है: अस्थायी इनबॉक्स सबसे तेज़ विकल्प है।
- संवेदनशील डेटा, उत्तर, अनुलग्नक या ऐसे साक्ष्य जिन्हें आपको रखना है: किसी अनुमोदित कंपनी-नियंत्रित मेलबॉक्स का उपयोग करें; प्लस टैग तभी जोड़ें जब आपका मेल सिस्टम और एप्लिकेशन उनका समर्थन करते हों।
- कोई व्यक्ति नहीं देख रहा है: यदि आप ऐप की आउटबाउंड मेल सेटिंग्स नियंत्रित करते हैं तो SMTP कैचर का उपयोग करें, या यदि ऐप को अपने सामान्य प्रदाता के माध्यम से भेजना है तो होस्टेड इनबॉक्स API का उपयोग करें।
मैनुअल बनाम स्वचालित ईमेल परीक्षण: एक निर्णय वृक्ष
चार प्रश्न तय करते हैं कि किसी जाँच के लिए कौन-सा परीक्षण ईमेल खाता चाहिए: क्या ईमेल का आना ज़रूरी है, उसे कोई व्यक्ति पढ़ता है या कोड, क्या उसमें संवेदनशील डेटा है, और क्या आप नियंत्रित करते हैं कि एप्लिकेशन अपना आउटबाउंड मेल कहाँ भेजता है।
- क्या परीक्षण के लिए ईमेल का आना ज़रूरी है? फ़ॉर्मेट जाँच, UI स्थितियाँ, फ़िक्स्चर और यूनिट परीक्षणों में आमतौर पर नहीं। example.com, example.org या example.net पर पते उपयोग करें। ये डोमेन दस्तावेज़ीकरण और उदाहरणों के लिए आरक्षित हैं, इसलिए कुछ भी किसी वास्तविक व्यक्ति तक नहीं पहुँचता। मनमाने डोमेन गढ़ने से बचें, क्योंकि कोई उनका मालिक हो सकता है।
- क्या परीक्षण के दौरान कोई व्यक्ति संदेश पढ़ेगा? स्मोक टेस्ट, मैनुअल UAT, डेमो और खोजपूर्ण सत्रों में एक व्यक्ति शामिल होता है। रिग्रेशन सूट और CI जॉब्स में आमतौर पर नहीं।
- यदि कोई व्यक्ति इसे पढ़ता है, तो क्या इसमें कुछ संवेदनशील है? वास्तविक ग्राहक रिकॉर्ड, क्रेडेंशियल, विनियमित डेटा, या ऐसे संदेश जिन्हें आपको ऑडिट साक्ष्य के रूप में रखना है, अस्थायी इनबॉक्स में नहीं रखे जाने चाहिए। इसके बजाय कंपनी मेलबॉक्स का उपयोग करें। यदि उत्तर नहीं है, तो अस्थायी इनबॉक्स पर्याप्त है।
- यदि कोड इसे पढ़ता है, तो क्या परीक्षण वातावरण अपना मेल परीक्षण SMTP सर्वर को भेज सकता है? यदि हाँ, तो SMTP कैचर हर संदेश को बिना वितरित किए कैप्चर करता है। यदि नहीं, क्योंकि ऐप को अपने सामान्य ईमेल प्रदाता के माध्यम से भेजना है, तो होस्टेड इनबॉक्स का उपयोग करें जिसे आपके परीक्षण API के माध्यम से पढ़ते हैं।
तालिका पाँचों विकल्पों की साथ-साथ तुलना करती है।
| विकल्प | किसके लिए सबसे अच्छा | मेल कैसे पढ़ा जाता है | किस बात का ध्यान रखें |
|---|---|---|---|
| आरक्षित उदाहरण डोमेन | सत्यापन, फ़िक्स्चर, नकारात्मक परीक्षण | डिलीवर नहीं हुआ | आगमन, समय या सामग्री का परीक्षण नहीं कर सकते |
| अस्थायी इनबॉक्स (जैसे Tmailor) | स्मोक टेस्ट, मैनुअल UAT, डेमो, खोजपूर्ण जाँच | ब्राउज़र या ऐप में कोई व्यक्ति | लगभग 24 घंटे के संदेश, केवल प्राप्ति, कोई अनुलग्नक नहीं, संवेदनशील डेटा के लिए नहीं |
| कंपनी-नियंत्रित मेलबॉक्स, वैकल्पिक रूप से प्लस टैग के साथ | संवेदनशील या लंबे समय तक चलने वाले प्रवाह, उत्तर, अनुलग्नक, ऑडिट साक्ष्य | कोई व्यक्ति, या आपकी IT टीम द्वारा अनुमोदित मेलबॉक्स एक्सेस | टैग किए गए पते एक ही मेलबॉक्स साझा करते हैं, इसलिए समानांतर परीक्षण एक-दूसरे के मेल देख सकते हैं |
| SMTP कैचर या सैंडबॉक्स | Dev, स्टेजिंग और CI, जहाँ आप आउटबाउंड मेल सेटिंग्स नियंत्रित करते हैं | वेब यूआई और एपीआई | सार्वजनिक DNS और MX पर डिलीवरी या इनबॉक्स प्लेसमेंट सिद्ध नहीं करता |
| होस्टेड इनबॉक्स API | आपके वास्तविक भेजने के पथ से एंड-टू-एंड परीक्षण | REST API और SDK | प्लान सीमाएँ, रिटेंशन, डोमेन और कॉन्करेंसी विक्रेता के अनुसार भिन्न होते हैं |
ईमेल फ़ील्ड को कौन-से पते स्वीकार या अस्वीकार करने चाहिए?
फ़ॉर्म सत्यापन का परीक्षण संदेश डिलीवरी से अलग करें। कभी डिलीवर न होने वाले मान्य दिखने वाले मामले के लिए user@example.com जैसे आरक्षित पते का उपयोग करें, प्लस टैग वाला पता और उपडोमेन वाला पता शामिल करें, और गुम लोकल भाग या गुम डोमेन जैसे विकृत मामले जोड़ें। अपेक्षित परिणामों को उसी वैलिडेटर के अनुरूप रखें जो आपका प्रोडक्शन सिस्टम वास्तव में उपयोग करता है।
कब एक अस्थायी इनबॉक्स पर्याप्त है
एक अस्थायी इनबॉक्स तब काम करता है जब कोई व्यक्ति एक समय में एक ही प्रवाह जाँच रहा हो और संदेश में ऐसा कुछ न हो जिसे एक दिन बाद खोने का अफ़सोस हो। QA के लिए अस्थायी ईमेल का यही पारंपरिक उपयोग है: आपको हाथ से फ़ॉर्म परखने के लिए एक ईमेल पता चाहिए, लंबे समय तक चलने वाला खाता नहीं। सामान्य मामले हैं साइन-अप फ़ॉर्म का प्री-रिलीज़ स्मोक टेस्ट, नए ऑनबोर्डिंग ईमेल पर मैनुअल UAT पास, खाता बनाने का बिक्री डेमो, या ऐसा खोजपूर्ण सत्र जिसमें आप अजीब इनपुट आज़माकर देखते हैं कि ऐप क्या भेजता है।
इसका आकर्षण गति है। IT से कोई खाता माँगना नहीं पड़ता और साफ़ करने के लिए कोई साझा मेलबॉक्स नहीं होता। कीमत नियंत्रण की है: आपको संदेशों के लिए छोटी अवधि मिलती है, कोई अनुलग्नक नहीं, और ऐसा इनबॉक्स जिसे कोड के बजाय कोई व्यक्ति पढ़ता है।
कब आपको SMTP कैचर या होस्टेड इनबॉक्स API चाहिए
जैसे ही परीक्षण बिना किसी व्यक्ति की निगरानी में चलने लगते हैं, इनबॉक्स को कोड द्वारा पढ़ा जा सकना चाहिए। उपकरणों के दो वर्ग इस आवश्यकता को पूरा करते हैं, और वे अलग-अलग समस्याएँ हल करते हैं।
SMTP कैचर और सैंडबॉक्स परीक्षण वातावरण में आपके ऐप के आउटबाउंड मेल सर्वर की जगह लेते हैं और हर संदेश को डिलीवर करने के बजाय निरीक्षण के लिए रख लेते हैं।
- Mailpit एक मुफ़्त, ओपन-सोर्स टूल है जिसे आप स्वयं चलाते हैं। यह डिफ़ॉल्ट रूप से मेल कैप्चर करता है और इंटीग्रेशन टेस्ट के लिए वेब UI और REST API देता है।
- MailHog भी इसी तरह काम करता है, लेकिन पुराना है। Mailpit के अनुरक्षक इसे अब अनुरक्षित नहीं बताते, इसलिए अपनाने से पहले इसकी स्थिति जाँच लें।
- Mailtrap Email Sandbox उसी विचार का होस्टेड संस्करण है, जिसमें SMTP और API एक्सेस उपलब्ध है। यह Mailtrap के प्रोडक्शन सेंडिंग प्रोडक्ट से अलग है।
- Ethereal एक मुफ़्त फ़ेक SMTP सेवा है जिसका इस्तेमाल मुख्य रूप से Nodemailer के साथ होता है। संदेश प्रीव्यू के लिए रोके जाते हैं और कभी डिलीवर नहीं होते।
होस्टेड इनबॉक्स API टेस्ट को विक्रेता के डोमेन पर असली पते देते हैं, इसलिए आपका ऐप अपने सामान्य प्रोवाइडर के ज़रिए मेल भेजता है और टेस्ट API के ज़रिए नतीजा पढ़ता है। Tmailor का अपना Temp Mail API इसी तरह काम करता है, जिसमें Python, Node.js और PHP के लिए आधिकारिक SDK हैं।
- Mailosaur टेस्ट ईमेल पते, एक API और क्लाइंट लाइब्रेरी देता है जो Cypress, Playwright और Selenium जैसे फ़्रेमवर्क के साथ काम करती हैं। यह SMS कोड भी कवर करता है।
- MailSlurp अपने API और SDK के ज़रिए मांग पर इनबॉक्स बनाता है। टेस्ट किसी संदेश का इंतज़ार कर सकते हैं, फिर कोड, लिंक और अटैचमेंट निकाल सकते हैं।
विक्रेता की सुविधाएँ और प्लान बदलते रहते हैं, इसलिए किसी टेस्ट सूट को किसी एक पर टिकाने से पहले हर आधिकारिक साइट पर मौजूदा जानकारी की पुष्टि करें।
कंपनी का प्लस टैग वाला मेलबॉक्स कब बेहतर विकल्प होता है
प्लस टैग एक ही कंपनी मेलबॉक्स को कई पता-रूपांतर स्वीकार करने देते हैं। आपकी कंपनी डोमेन पर qa+signup या qa+reset को भेजा गया मेल qa मेलबॉक्स में पहुँचता है, जहाँ आप उसे टैग के हिसाब से फ़िल्टर कर सकते हैं। Google Workspace इसका समर्थन करता है, और Microsoft का दस्तावेज़ कहता है कि Exchange Online में प्लस एड्रेसिंग डिफ़ॉल्ट रूप से चालू रहती है, जब तक कोई एडमिन उसे बंद न कर दे।
इस रास्ते का इस्तेमाल तब करें जब किसी फ़्लो में असली ग्राहक डेटा हो, वह एक दिन से ज़्यादा चले, उसमें जवाब या अटैचमेंट की ज़रूरत हो, या ऐसा सबूत बने जो ऑडिटर माँग सकता है। सीमाओं को ध्यान में रखें। टैग एक ही मेलबॉक्स के रूपांतर हैं, अलग इनबॉक्स नहीं, इसलिए समानांतर टेस्ट एक-दूसरे के संदेश पढ़ सकते हैं। कुछ साइन-अप फ़ॉर्म प्लस चिह्न को अस्वीकार करते हैं, और कुछ ऐप टैग वाले रूपांतरों को एक ही खाता मानते हैं। दोनों व्यवहार अपने आप में एक टेस्ट केस के लायक हैं।
अस्थायी इनबॉक्स के साथ मैन्युअल साइन-अप टेस्ट कैसे चलाएँ
टेस्टिंग के लिए अस्थायी ईमेल का इस्तेमाल करने वाले मैन्युअल साइन-अप टेस्ट के लिए तीन चीज़ें चाहिए: एक नया पता, वह बिल्ड जिसका आप टेस्ट कर रहे हैं, और जो आया उसे दर्ज करने के लिए इनबॉक्स के बाहर कोई जगह। इसे सिर्फ़ उन्हीं सिस्टम पर चलाएँ जो आपके हैं या जिन्हें टेस्ट करने की आपको अनुमति है।
- एक इनबॉक्स खोलें। वेब पर एक निःशुल्क अस्थायी इनबॉक्स बनाएं, या Tmailor ऐप या Telegram बॉट का इस्तेमाल करें, और पता कॉपी करें। डेस्कटॉप पर, Tmailor ब्राउज़र एक्सटेंशन इसे आपके टेस्ट बिल्ड के ईमेल फ़ील्ड में भी भर सकता है।
- अपने टेस्ट बिल्ड पर साइन अप करें। अपने स्टेजिंग या QA एनवायरनमेंट में इस पते का इस्तेमाल करें और जिस समय फ़ॉर्म सबमिट किया उसे नोट करें।
- ईमेल का इंतज़ार करें। देखें कि कौन सा संदेश आया, प्रेषक का नाम और From पता, विषय, और इसमें कितना समय लगा।
- चरण पूरा करें। लिंक पर क्लिक करें या कोड दर्ज करें। पुष्टि करें कि खाते की स्थिति एक बार बदलती है और वही लिंक दोबारा इस्तेमाल करने पर स्पष्ट संदेश के साथ विफल होता है।
- सबूत कहीं और दर्ज करें। लिंक, कोड, टाइमस्टैम्प और स्क्रीनशॉट को अपने टेस्ट केस में कॉपी करें। संदेश आने के लगभग 24 घंटे तक रहते हैं, इसलिए इनबॉक्स आपका टेस्ट रिकॉर्ड नहीं है।
- अगर आप दोबारा टेस्ट करेंगे तो access token सहेजें। token बाद में उसी पते को फिर से खोलता है, जैसे पासवर्ड रीसेट दोबारा चलाने के लिए। यह उन संदेशों को बहाल नहीं करता जो पहले ही समाप्त हो चुके हैं, और खोया हुआ token वापस नहीं पाया जा सकता।
जब किसी सत्र में एक साथ कई भूमिकाओं की ज़रूरत हो, जैसे एक मुफ़्त उपयोगकर्ता, एक ट्रायल उपयोगकर्ता और एक आमंत्रित टीममेट, तो एकाधिक इनबॉक्स दृश्य एक ही ब्राउज़र टैब में अधिकतम पाँच पते साथ-साथ रखता है। हर भूमिका को अपना पता मिलता है, इसलिए आप देख सकते हैं कि कौन सा ईमेल किस खाते का है।
यह व्यू अब भी मैन्युअल है। इनबॉक्स ब्राउज़र में कोई व्यक्ति बनाता है, कोड उन्हें प्रोविज़न नहीं करता, इसलिए यह समानांतर बिना-निगरानी वाले रन के लिए होस्टेड इनबॉक्स API की जगह नहीं लेता।
प्रति परीक्षण एक इनबॉक्स या एक पता?
एक ही साझा इनबॉक्स त्वरित स्मोक जाँच के लिए ठीक है, लेकिन यह जल्दी ही अव्यवस्थित हो जाता है। जब एक साथ कई परीक्षण चलते हैं, तो मिलते-जुलते विषयों के कारण यह पहचानना मुश्किल हो जाता है कि कौन-सा ईमेल किस स्क्रिप्ट का है, और डिबगिंग अनुमान लगाने में बदल जाती है।
प्रति परीक्षण मामला एक पता रखने से यह समस्या हल हो जाती है। लॉग, स्क्रीनशॉट और ईमेल एक-दूसरे से मेल खाते हैं, और कोई संदेश न मिलने पर संकेत सभी परिदृश्यों के बजाय एक ही परिदृश्य की ओर इशारा करता है। एकाधिक अस्थायी मेल इनबॉक्स चलाने की मार्गदर्शिका उस वर्कफ़्लो को अधिक विस्तार से समझाती है।
कुछ यात्राओं में कई दिनों बाद फिर से उसी पते की आवश्यकता होती है, जैसे कि कोई ट्रायल जो सशुल्क में बदल जाता है या कोई उपयोगकर्ता जो चर्न के बाद वापस आता है। एक पुन: प्रयोज्य अस्थायी मेल पता अपने एक्सेस टोकन के माध्यम से पता उपलब्ध रखता है, लेकिन मेल नहीं। हर चरण चलते समय आवश्यक लिंक और कोड संग्रहीत करें, और पुराने संदेशों पर निर्भर किसी भी चरण को कंपनी मेलबॉक्स में ले जाएँ। यदि कोई परीक्षक व्यक्तित्व पते बनाने से पहले मुफ्त Tmailor खाते में साइन इन करता है, तो हर पता Created Emails के अंतर्गत सहेजा जाता है, इसलिए टोकन खोने का मतलब अब पता खोना नहीं है।
| पैटर्न | सबसे उपयुक्त उपयोग | मुख्य जोखिम |
|---|---|---|
| साझा इनबॉक्स | स्मोक जाँच और छोटे मैनुअल सत्र | रन ओवरलैप होने पर संदेशों को परीक्षणों से मिलाना कठिन |
| प्रति-परीक्षण पता | बहु-चरणीय साइन-अप और ऑनबोर्डिंग मामले | ट्रैक और रिटायर करने के लिए अधिक पते |
| पुन: प्रयोग योग्य व्यक्तित्व पता | ट्रायल-से-सशुल्क, पुनर्सक्रियण और वापसी यात्राएँ | संदेश फिर भी लगभग 24 घंटे बाद समाप्त हो जाते हैं; टोकन खोने का मतलब पता खोना है, जब तक कि पता Tmailor खाते में सहेजा न गया हो |
साइन-अप और ऑनबोर्डिंग ईमेल में क्या जाँचें
यात्रा में भेजे जा सकने वाले हर ईमेल की सूची बनाकर शुरू करें, फिर तय करें कि प्रत्येक परीक्षण को क्या जाँचना चाहिए। टीमों को अक्सर अतिरिक्त ईमेल तभी पता चलते हैं जब वे परीक्षण के बीच में दिखाई देते हैं, क्योंकि किसी ग्रोथ प्रयोग या सुरक्षा बदलाव ने ऐसा ईमेल जोड़ दिया था जिसे किसी ने लिखा ही नहीं था।
एक सामान्य साइन-अप यात्रा में ईमेल
- सत्यापन लिंक या वन-टाइम कोड
- स्वागत ईमेल और कोई भी त्वरित-शुरुआत अनुक्रम
- मैजिक-लिंक साइन-इन
- पासवर्ड रीसेट
- ईमेल पता परिवर्तन, पुराने और नए दोनों पतों पर भेजा जाता है
- नए डिवाइस या नए स्थान की सुरक्षा चेतावनी
- उन साइन-अप के लिए अनुस्मारक जो कभी पूरे नहीं हुए
हर एक के लिए, ट्रिगर, अपेक्षित समय और उसे बदलने वाली शर्तें, जैसे प्लान, क्षेत्र या भाषा, लिख लें। अनुमत डिलीवरी विंडो को किसी सार्वभौमिक सीमा के अनुमान के बजाय अपने उत्पाद की प्रलेखित आवश्यकता से तय करें; तत्काल भेजे जाने वाले सत्यापन संदेश और निर्धारित स्वागत अनुक्रम के लिए अलग-अलग अपेक्षाएँ होती हैं। एक बार ये अपेक्षाएँ तय हो जाने पर, हर परीक्षण के पास जाँचने के लिए कुछ ठोस होता है।
हर परीक्षण ईमेल में क्या जाँचना चाहिए
- प्रेषक और प्राप्तकर्ता: प्रेषक का नाम और पता, Reply-To, और सटीक To पता।
- विषय और मुख्य भाग: HTML और सादे-पाठ, दोनों संस्करण, सही नाम, प्लान विवरण और भाषा के साथ।
- लिंक: गंतव्य और क्या यह सही वातावरण की ओर इशारा करता है। स्टेजिंग से भेजा गया ईमेल जो प्रोडक्शन से लिंक करता है, एक वास्तविक बग है।
- कोड: प्रारूप, लंबाई, समाप्ति से जुड़ा टेक्स्ट, और क्या बताई गई समाप्ति सर्वर द्वारा लागू की जाने वाली समाप्ति से मेल खाती है।
- समय: ट्रिगर के बाद संदेश आने में कितना समय लगा।
- अनुलग्नक: यदि कोई प्रवाह PDF या इनवॉइस भेजता है, तो उसका परीक्षण कंपनी के मेलबॉक्स या किसी परीक्षण उपकरण में करें। Tmailor अनुलग्नक प्राप्त नहीं करता है।
रेंडरिंग पर एक सावधानी। अस्थायी इनबॉक्स दिखाता है कि कोई एक वेब व्यूअर आपके HTML को कैसे प्रदर्शित करता है। यह नहीं बताता कि वही ईमेल Gmail, Outlook, Apple Mail, डार्क मोड या छोटी फोन स्क्रीन पर कैसा दिखता है, इसलिए अगर ये बातें मायने रखती हैं तो अलग से रेंडरिंग जाँच की योजना बनाएँ।
ईमेल बदलने और खाता पुनर्प्राप्ति के प्रवाह
पुनर्प्राप्ति प्रवाह साइन-अप की तुलना में अधिक चुपचाप तरीकों से टूटते हैं। जाँचें कि ईमेल बदलने पर नए पते पर पुष्टिकरण और पुराने पते पर सूचना जाती है, कि इस्तेमाल किया गया रीसेट लिंक दोबारा उपयोग नहीं किया जा सकता, कि नया रीसेट लिंक भेजे जाने के बाद पुराना रीसेट लिंक काम करना बंद कर देता है, और यह कि दूसरे डिवाइस पर खोला गया लिंक उपयोगकर्ता को एक समझदार स्थिति में पहुँचाता है। OTP प्रवाहों के लिए अलग जोखिम समीक्षा होनी चाहिए; क्यूए और यूएटी के लिए ओटीपी जोखिम चेकलिस्ट में मेट्रिक्स, दोबारा भेजने की विंडो और स्वामित्व शामिल हैं।
OTP और सत्यापन के एज केसों का परीक्षण कैसे करें
OTP और सत्यापन प्रवाहों का परीक्षण देरी से डिलीवरी, दोबारा भेजने, समाप्त और गलत कोड, तथा किसी अन्य डिवाइस पर खोले गए लिंक के विरुद्ध करें। हर मामले में सर्वर का परिणाम और उपयोगकर्ता को दिखाया गया संदेश, दोनों जाँचे जाने चाहिए। ये परीक्षण केवल उन्हीं सिस्टम पर चलाएँ जो आपके हैं या जिनका परीक्षण करने के लिए आप अधिकृत हैं। अच्छे OTP परीक्षण जानबूझकर प्रवाह को तोड़ते हैं:
- धीमी डिलीवरी: इनबॉक्स जाँचने से पहले प्रतीक्षा करें और पुष्टि करें कि UI बताता है कि क्या हो रहा है और दोबारा भेजने का स्पष्ट तरीका देता है।
- दोबारा भेजने का व्यवहार: दूसरे कोड का अनुरोध करें और जाँचें कि पहला कोड अमान्य हो गया है या अब भी स्वीकार किया जाता है।
- समाप्ति: बताए गए जीवनकाल के बाद कोड दर्ज करें और पुष्टि करें कि त्रुटि संदेश वास्तव में हुई बात से मेल खाता है।
- गलत कोड: पुष्टि करें कि प्रयास सीमा और कूलडाउन का टेक्स्ट किसी व्यक्ति के लिए समझ में आता है।
- क्रॉस-डिवाइस मैजिक लिंक: लैपटॉप पर लिंक का अनुरोध करें, उसे फोन पर खोलें, और जाँचें कि उपयोगकर्ता कहाँ पहुँचता है।
इस बात की व्यापक जानकारी के लिए कि कौन-से कोड अस्थायी इनबॉक्स तक पहुँचते हैं और कौन-से नहीं, ओटीपी कोड के लिए अस्थायी मेल पर यह मार्गदर्शिका देखें।
यदि आपका उत्पाद जानबूझकर डिस्पोजेबल ईमेल डोमेन को अस्वीकार करता है, तो सीधे उसी पथ का परीक्षण करें। पुष्टि करें कि अस्वीकृति संदेश स्पष्ट है और कोई वास्तविक या कंपनी-नियंत्रित पता अब भी साइन-अप पूरा करता है। ब्लॉक को पार करने के लिए अन्य अस्थायी डोमेन बदल-बदलकर न आज़माएँ, न अपने उत्पाद पर और न किसी और के उत्पाद पर। ब्लॉक के काम करने की पुष्टि करना ही परीक्षण है; उसे तोड़ना नहीं। अस्थायी मेल डोमेन को क्यों ब्लॉक पर यह व्याख्या उन फ़िल्टरों के पीछे के कारणों को समझाती है।
ईमेल परीक्षण बिना निगरानी में चलने पर क्या बदलता है
जब कोई व्यक्ति निगरानी नहीं कर रहा होता, तो परीक्षण को ऐसे इनबॉक्स की ज़रूरत होती है जिसे वह कोड के ज़रिए पढ़ सके। इसका मतलब है SMTP कैचर का API या होस्ट किया गया इनबॉक्स API। Tmailor वेब इनबॉक्स वह उपकरण नहीं है, लेकिन Tmailor Temp Mail API है: परीक्षण केवल-प्राप्ति वाले पते बना सकते हैं, संदेशों को सूचीबद्ध और पढ़ सकते हैं, और API जो वन-टाइम कोड या सत्यापन लिंक ढूँढता है उसे प्राप्त कर सकते हैं। एक MCP सर्वर Claude, Cursor या VS Code Copilot जैसे AI एजेंटों को उन साइन-अप प्रवाहों के लिए भी ऐसा ही करने देता है जो आपके हैं या जिनका परीक्षण करने की आपको अनुमति है।
कुछ आदतें बिना निगरानी वाले ईमेल परीक्षणों को स्थिर रखती हैं, चाहे आप कोई भी उपकरण चुनें:
- हर परीक्षण रन को अपना अलग पता और एक सहसंबंध आईडी दें, ताकि किसी पिछले रन से देर से आया ईमेल गलत दावे को पूरा न कर सके।
- ईमेल आने के लिए उचित बैकऑफ़ के साथ एक समर्पित प्रतीक्षा का उपयोग करें, जो समग्र परीक्षण टाइमआउट से अलग हो, और लॉग करें कि हर संदेश में कितना समय लगा।
- "नवीनतम ईमेल" पढ़ने के बजाय प्राप्तकर्ता और विषय के आधार पर सटीक संदेश का मिलान करें।
- CI लॉग में कोड और मैजिक लिंक छिपाएँ, क्योंकि लॉग अक्सर इनबॉक्स से ज़्यादा समय तक रहते हैं।
यह भी स्पष्ट रखें कि पास हुआ परीक्षण क्या साबित करता है। "ऐप ने ईमेल बनाया और सौंप दिया," "किसी होस्ट किए गए परीक्षण डोमेन ने उसे सार्वजनिक ईमेल अवसंरचना पर प्राप्त किया," और "जीमेल ने उसे इनबॉक्स में रखा, स्पैम में नहीं" — ये तीन अलग-अलग तथ्य हैं। SMTP कैचर पहला साबित करता है, होस्ट किया गया इनबॉक्स API पहले दो साबित करता है, और इनमें से कोई भी तीसरा साबित नहीं करता। GitHub Actions, GitLab CI और CircleCI पर पाइपलाइन सेटअप के लिए, CI/CD पाइपलाइनों में ईमेल परीक्षण की मार्गदर्शिका देखें।
परीक्षण डेटा को सुरक्षित रखें और नियमों के भीतर रहें
अस्थायी परीक्षण इनबॉक्स में सिंथेटिक पहचान और गैर-संवेदनशील सामग्री का उपयोग करें, और साइन-अप परीक्षण केवल उन्हीं सिस्टमों पर चलाएँ जो आपके स्वामित्व में हैं या जिनका मूल्यांकन करने के लिए आप अधिकृत हैं। QA खातों को उत्पादन एनालिटिक्स से बाहर रखें, दर सीमाओं का पालन करें, और विनियमित डेटा, क्रेडेंशियल, अनुलग्नक तथा सुरक्षित रखे जाने वाले साक्ष्य को अनुमोदित कंपनी-नियंत्रित प्रणालियों में स्थानांतरित करें।
- अस्थायी इनबॉक्स में कोई वास्तविक डेटा नहीं। कभी भी वास्तविक ग्राहक रिकॉर्ड, क्रेडेंशियल, API कुंजियाँ या विनियमित डेटा किसी अस्थायी मेल पते पर न भेजें। स्पष्ट रूप से नकली नामों वाले सिंथेटिक उपयोगकर्ताओं का उपयोग करें।
- केवल वही परीक्षण करें जिसकी आपको अनुमति है। साइन-अप परीक्षण अपने स्वयं के उत्पाद या ऐसे सिस्टम पर चलाएँ जिसका परीक्षण करने के लिए आप अधिकृत हैं, और उस सेवा की दर सीमाओं तथा शर्तों का पालन करें। तृतीय-पक्ष साइटों पर बड़ी संख्या में खाते बनाने के लिए अस्थायी मेल का उपयोग न करें। वॉल्यूम और लोड परीक्षण अपने ही स्टेजिंग वातावरण में होने चाहिए, जिसमें SMTP कैचर या होस्ट किया गया इनबॉक्स API हो।
- QA ट्रैफ़िक को उत्पादन के आँकड़ों से बाहर रखें। परीक्षण खातों को स्पष्ट रूप से लेबल करें और उन्हें एनालिटिक्स तथा ग्रोथ डैशबोर्ड से बाहर रखें। अपने उत्पादन भेजने वाले डोमेन से बड़ी मात्रा में परीक्षण मेल भेजने से बचें, जहाँ बाउंस और शिकायतें उसकी प्रतिष्ठा को नुकसान पहुँचा सकती हैं।
- नीति लिखित रूप में रखें। स्पष्ट करें कि कौन-से प्रवाह अस्थायी इनबॉक्स का उपयोग कर सकते हैं, किनके लिए कंपनी मेलबॉक्स ज़रूरी है, परीक्षण डेटा कितने समय तक रखा जाता है, और किसके पास पहुँच है। जब सीमाएँ पहले से कागज़ पर हों, तो सुरक्षा और अनुपालन समीक्षाएँ तेज़ी से होती हैं।
जब सुरक्षा टीम पूछे कि कोई प्रदाता डेटा को कैसे संभालता है, तो देखें कि वह क्या एकत्र करता है, संदेशों को कितने समय तक रखता है, और एक्सेस कैसे काम करता है। अस्थायी मेल और ऑनलाइन गोपनीयता का यह अवलोकन उपयोगकर्ता के दृष्टिकोण से इन प्रश्नों को कवर करता है। डिस्पोजेबल इनबॉक्स का उपयोग किन प्रवाहों में हो, यह निर्णय अब भी आपकी अपनी कानूनी, गोपनीयता और सुरक्षा टीमों का है।
योजना बनाते समय ध्यान रखने योग्य सीमाएँ
Tmailor वेब इनबॉक्स गैर-संवेदनशील इनबाउंड ईमेल की छोटी मैन्युअल जाँच के लिए उपयुक्त है (स्वचालन के लिए Temp Mail API है)। इसे चुनने से पहले तय करें कि वर्कफ़्लो को आउटबाउंड कार्रवाइयाँ, अनुलग्नक, लंबे समय तक रखा जाने वाला साक्ष्य, या स्थायी पता पुनर्प्राप्ति चाहिए या नहीं। इनमें से कोई भी आवश्यकता कंपनी-नियंत्रित मेलबॉक्स या किसी विशेषज्ञ परीक्षण उपकरण की माँग करती है; नीचे दी गई चेकलिस्ट बताती है कि क्यों।
- Tmailor केवल प्राप्ति के लिए है। यह इनबाउंड साइन-अप, सत्यापन और OTP मेल की जाँच कर सकता है, लेकिन उत्तर देने वाले प्रवाहों या पते से भेजी जाने वाली किसी भी चीज़ की नहीं।
- Tmailor अनुलग्नक प्राप्त नहीं करता, इसलिए चालान, अनुबंध या दस्तावेज़-वितरण वाले ईमेल के लिए कंपनी मेलबॉक्स या कोई परीक्षण उपकरण आवश्यक है।
- संदेश आने के बाद लगभग 24 घंटे तक रहते हैं। जिन लिंक, कोड और टाइमस्टैम्प की लंबी जाँच में आवश्यकता होगी, उन्हें निर्यात कर लें।
- एक्सेस टोकन पते को फिर से खोलता है, समाप्त हो चुके संदेशों को नहीं, और खोया हुआ टोकन वापस नहीं पाया जा सकता।
- वेब इनबॉक्स को कोई व्यक्ति पढ़ता है। बिना किसी व्यक्ति के इनबॉक्स पढ़ने के लिए SMTP कैचर या होस्ट किया गया इनबॉक्स API चाहिए, जैसे Tmailor Temp Mail API।
- कुछ सेवाएँ डिस्पोजेबल ईमेल डोमेन को ब्लॉक करती हैं। यदि आप जिस प्रवाह का परीक्षण कर रहे हैं वह जानबूझकर ऐसा करता है, तो इसे किसी वास्तविक या कंपनी-नियंत्रित पते से सत्यापित करें।
अक्सर पूछे जाने वाले प्रश्न
क्या मैं QA परीक्षण के लिए अस्थायी ईमेल पते का उपयोग कर सकता हूँ?
हाँ, ऐसे मैन्युअल परीक्षणों के लिए जिनमें कोई व्यक्ति ईमेल पढ़ता है और उसमें कुछ भी संवेदनशील नहीं होता। अस्थायी इनबॉक्स स्मोक टेस्ट, मैन्युअल UAT और साइन-अप व OTP प्रवाह के डेमो के लिए अच्छी तरह काम करता है। यह वास्तविक ग्राहक डेटा, अनुलग्नक, उत्तर, लगभग 24 घंटे से अधिक समय तक रखे जाने वाले संदेश, या बिना किसी व्यक्ति के चलने वाले परीक्षणों के लिए गलत विकल्प है।
क्या स्वचालित परीक्षण एपीआई के माध्यम से टीमेलर इनबॉक्स पढ़ सकते हैं?
हाँ, Tmailor Temp Mail API के माध्यम से बनाए गए पतों के साथ। परीक्षण केवल-प्राप्ति वाले पते बना सकते हैं, संदेशों को सूचीबद्ध और पढ़ सकते हैं, और आधिकारिक Python, Node.js या PHP SDK का उपयोग करके वह एकमुश्त कोड या सत्यापन लिंक प्राप्त कर सकते हैं जो API निकालता है (सर्वोत्तम प्रयास)। शुरू करने के लिए एक निःशुल्क योजना उपलब्ध है। इसका उपयोग केवल उन प्रवाहों के लिए करें जो आपके हैं या जिनका परीक्षण करने के लिए आप अधिकृत हैं। जब आप ऐप की आउटबाउंड मेल सेटिंग्स नियंत्रित करते हैं, तो Mailpit या Mailtrap Email Sandbox जैसा SMTP कैचर एक और विकल्प है, और अन्य होस्ट किए गए इनबॉक्स API में Mailosaur और MailSlurp शामिल हैं।
परीक्षण ईमेल खाते और SMTP सैंडबॉक्स में क्या अंतर है?
परीक्षण ईमेल खाता, या परीक्षण मेलबॉक्स, एक प्राप्ति पता है जिस पर आपका एप्लिकेशन भेज सकता है और जहाँ कोई व्यक्ति या कोई परीक्षण पहुँचे हुए संदेश का निरीक्षण करता है। इसके विपरीत, SMTP सैंडबॉक्स ऐप के आउटबाउंड मेल सर्वर की जगह लेता है और सार्वजनिक डिलीवरी से पहले संदेश को पकड़ लेता है। प्राप्ति मेलबॉक्स भेजने के पथ का अधिक परीक्षण करता है, लेकिन इनमें से कोई भी विकल्प अकेले यह साबित नहीं करता कि संदेश Gmail या Outlook के इनबॉक्स में पहुँचेगा।
क्या प्रत्येक QA परीक्षण में अलग ईमेल पता होना चाहिए?
आमतौर पर हाँ। प्रति परीक्षण मामला एक पता रखने से लॉग, स्क्रीनशॉट और ईमेल एक-दूसरे से मेल खाते रहते हैं और एक परीक्षण दूसरे परीक्षण का संदेश नहीं पढ़ पाता। त्वरित स्मोक जाँच के लिए साझा इनबॉक्स ठीक है, लेकिन एक साथ कई परीक्षण चलने पर डीबग करना मुश्किल हो जाता है।
क्या मैं किसी अन्य परीक्षण के लिए उसी Tmailor पते का दोबारा उपयोग कर सकता हूँ?
हाँ, यदि आपने उसका एक्सेस टोकन सहेज लिया है। टोकन किसी भी डिवाइस पर वही पता फिर से खोलता है, जो दोबारा परीक्षण और कई दिनों तक चलने वाली यात्राओं में मदद करता है। यह लगभग 24 घंटे से पुराने संदेश वापस नहीं लाता, और अतिथि पते का खोया हुआ टोकन वापस नहीं पाया जा सकता, इसलिए हर चरण चलते समय आवश्यक लिंक और कोड दर्ज करते रहें।
QA को अस्थायी ईमेल के बजाय कंपनी मेलबॉक्स का उपयोग कब करना चाहिए?
कंपनी मेलबॉक्स का उपयोग तब करें जब ईमेल में वास्तविक ग्राहक डेटा या क्रेडेंशियल हों, जब प्रवाह में उत्तर या अनुलग्नक चाहिए हों, जब आपको संदेश को ऑडिट साक्ष्य के रूप में रखना हो, या जब कोई उत्पाद जानबूझकर डिस्पोजेबल डोमेन को ब्लॉक करता हो। तृतीय-पक्ष पहचान प्रदाताओं और उत्पादन माइग्रेशन के लिए भी आमतौर पर वास्तविक, कंपनी-नियंत्रित पते चाहिए होते हैं।
क्या प्लस-एड्रेसिंग से अलग-अलग परीक्षण खाते बन सकते हैं?
यह पते के रूपांतर बनाता है, अलग इनबॉक्स नहीं। आपके डोमेन पर qa+one और qa+two को भेजा गया मेल उसी qa मेलबॉक्स में पहुँचता है, इसलिए परीक्षण संदेश इतिहास साझा करते हैं। आपका एप्लिकेशन इन रूपांतरों को अलग खातों के रूप में स्वीकार कर सकता है, प्लस चिह्न को अस्वीकार कर सकता है, या उन्हें एक ही उपयोगकर्ता में सामान्य कर सकता है। इस व्यवहार को धारणा मानने के बजाय एक परीक्षण मामला मानें।
सत्यापन ईमेल परीक्षण इनबॉक्स में क्यों नहीं आया?
सबसे आम कारण हैं ऐप में भेजने की त्रुटि, ईमेल प्रदाता पर देरी, बार-बार अनुरोध पर दर सीमा, पते में टाइपो, या ऐसा फ़िल्टर जो डिस्पोजेबल डोमेन को अस्वीकार करता है। पहले अपने ऐप के मेल लॉग जाँचें, फिर कंपनी-नियंत्रित पते के साथ एक बार दोबारा प्रयास करें ताकि पता चले कि समस्या पते के साथ आती है या प्रवाह के साथ।
क्या अस्थायी इनबॉक्स अनुलग्नक, उत्तर या ईमेल डिलीवरेबिलिटी का परीक्षण कर सकता है?
Tmailor के साथ नहीं। यह अनुलग्नक प्राप्त नहीं करता और न भेज सकता है न उत्तर दे सकता है। अस्थायी इनबॉक्स में संदेश प्राप्त होने से यह भी पता नहीं चलता कि Gmail या Outlook उसे इनबॉक्स में रखेगा या स्पैम में। अनुलग्नक और उत्तर के लिए कंपनी मेलबॉक्स का उपयोग करें, और इनबॉक्स प्लेसमेंट के लिए समर्पित डिलीवरेबिलिटी या सीड-टेस्टिंग सेवा का उपयोग करें।
क्या अस्थायी ईमेल से परीक्षण साइन-अप हमारे एनालिटिक्स को विकृत कर सकते हैं?
हाँ, यदि ट्रैफ़िक पर लेबल नहीं लगाया गया हो। हर परीक्षण खाते को स्पष्ट रूप से चिह्नित करें, उदाहरण के लिए नामकरण परंपरा या परीक्षण फ़्लैग से, और उन खातों को उत्पादन डैशबोर्ड और ग्रोथ रिपोर्ट से बाहर रखें। अलग स्टेजिंग वातावरण में परीक्षण चलाने से वह अधिकांश ट्रैफ़िक शुरू से ही वास्तविक संख्याओं से बाहर रहता है।
सही परीक्षण इनबॉक्स चुनना
इनबॉक्स उस बात के अनुसार चुनें जो परीक्षण को साबित करना है। जब डिलीवरी की आवश्यकता न हो तो आरक्षित उदाहरण डोमेन का उपयोग करें, मैन्युअल गैर-संवेदनशील जाँच के लिए अस्थायी इनबॉक्स, संरक्षित या संवेदनशील यात्राओं के लिए कंपनी मेलबॉक्स, जब आप आउटबाउंड सेटिंग्स नियंत्रित करते हों तो SMTP कैचर, और बिना किसी व्यक्ति के चलने वाले एंड-टू-एंड परीक्षणों के लिए होस्ट किया गया इनबॉक्स API।
मैन्युअल मामलों के लिए, एक अस्थायी इनबॉक्स खोलें और उसी साइन-अप प्रवाह से शुरू करें जिसे आप आगे लॉन्च कर रहे हैं। अस्थायी मेल में बहुत सारे क्यूए से परे भी बहुत सारे व्यावहारिक उपयोग भी।
Marcus Lee writes Tmailor's step-by-step guides, signing up to apps and platforms with temp mail, using the mobile app and Telegram bot, custom domains, reusing addresses, and getting the most out of disposable email day to day.
