मुफ़्त अस्थायी ईमेल उन टीमों का डिफ़ॉल्ट शुरुआती बिंदु है जिन्हें टेस्ट के अंदर एक इनबॉक्स चाहिए और उसके लिए बजट की कोई पंक्ति नहीं है। इसे आज़माने में कुछ खर्च नहीं होता, किसी डोमेन की जरूरत नहीं पड़ती, और पहली बार में यह ठीक काम करता है। मुश्किल तब शुरू होती है जब यही तरीका ऐसी पाइपलाइन में जोड़ दिया जाता है जो हर रात चलती है, क्योंकि सार्वजनिक मुफ़्त मेलबॉक्स को सुविधाजनक बनाने वाले गुण ही उसे बड़े पैमाने पर अभरोसेमंद भी बनाते हैं।
यह लेख समझाता है कि मुफ़्त शब्द वास्तव में क्या खरीद रहा है, साझा सार्वजनिक डोमेन ब्लॉकलिस्ट में क्यों पहुंच जाते हैं, अपने नियंत्रण वाला डोमेन गणित कैसे बदल देता है, और बिना बजट वाली टीम भी ऐसा मेल टेस्टिंग कैसे खड़ा कर सकती है जो सॉफ़्टवेयर से असंबंधित कारणों से विफल न हो। लेख के अंत तक आप यह तय कर सकेंगे कि किसी दिए गए टेस्ट के लिए मुफ़्त पर्याप्त है या वह केवल टाली हुई लागत है।
मुफ़्त अस्थायी ईमेल में क्या शामिल है और क्या नहीं?
सार्वजनिक मुफ़्त मेलबॉक्स में साझा डोमेन पर एक पता शामिल होता है, संदेश पढ़ने के लिए एक वेब इंटरफ़ेस, और मिनटों या घंटों में नापी गई एक रिटेंशन विंडो। जो चीजें टेस्टिंग के नियमित होते ही मायने रखती हैं, वे इसमें शामिल नहीं हैं: गारंटीकृत रिटेंशन अवधि, ऐसी दर सीमा जिसकी योजना बनाई जा सके, डोमेन पर नियंत्रण, और सेवा कब बदलेगी इस पर कोई प्रतिबद्धता।
रिटेंशन विंडो पहला छिपा हुआ चर है। मुफ़्त सेवा देने वाले संदेशों को अपनी चुनी हुई अवधि तक रखते हैं और बिना सूचना के उसे छोटा कर सकते हैं। ऐसा सत्यापन टेस्ट जो संदेश का इंतजार करता रहता है, और ऐसा मेलबॉक्स जो टेस्ट के सोते-सोते समाप्त हो जाता है, मिलकर ऐसी विफलता पैदा करते हैं जो डिलीवरी की समस्या जैसी दिखती है पर असल में रिटेंशन की समस्या है। इसे पहचानना कठिन है क्योंकि त्रुटि संदेश चाहे जो भी कहे, ट्रांसपोर्ट में कुछ भी गलत नहीं हुआ।
दर सीमा दूसरा छिपा हुआ चर है। सेवा देने वाले यह सीमित करते हैं कि किसी एक स्रोत से एक अवधि में कितने मेलबॉक्स बन सकते हैं, और यह सीमा ऐसे रूप में प्रकाशित नहीं होती जिसके खिलाफ योजना बनाई जा सके। ऐसा सुइट जो हर टेस्ट केस के लिए एक मेलबॉक्स बनाता है, इस सीमा से किसी रन के बीच में टकराएगा, और विफलताएं पूरे सुइट में अनुमान से बाहर बिखर जाएंगी। कल का रन हरा और परसों का लाल हो सकता है, बिना किसी कोड परिवर्तन के।
डोमेन तीसरा और सबसे बड़ा चर है। मुफ़्त सेवा के हर उपयोगकर्ता का डोमेन एक ही होता है, यानी आपके टेस्ट की डिलीवरेबिलिटी इस बात का फलन है कि उस सप्ताह अजनबियों ने क्या किया। आप इसे सुधारने के लिए कुछ नहीं कर सकते और विफल बिल्ड पढ़ रहे सहकर्मी को इसे समझाने के लिए भी कुछ नहीं कर सकते। मुफ़्त सेवा किसी पते या पूरे डोमेन को बिना सूचना निलंबित भी कर सकती है, और उसका एकमात्र दिखने वाला लक्षण यह होता है कि जिस संदेश का आप इंतजार कर रहे थे वह कभी नहीं आता।
साझा सार्वजनिक डोमेन ब्लॉकलिस्ट में क्यों पहुंच जाते हैं?
साइनअप उत्पाद स्वचालित अकाउंट निर्माण रोकना चाहते हैं, और सबसे सस्ता उपलब्ध संकेत ईमेल डोमेन है। अस्थायी डोमेन की प्रकाशित सूची से कोई फ़ॉर्म एक ही तुलना में सबमिशन अस्वीकार कर सकता है, किसी पासवर्ड की जांच से पहले और कोई मेल भेजे जाने से पहले। यह सूची विक्रेता बनाए रखते हैं, लगातार अद्यतन करते हैं, और हजारों उत्पाद उसका उपभोग करते हैं।
किसी डोमेन का ऐसी सूची में पहुंचने का तंत्र बिलकुल साधारण है। देखा जाता है कि वह डोमेन ऐसे पतों के लिए मेल स्वीकार कर रहा है जो कभी पंजीकृत ही नहीं हुए, या ऐसी दर पर पते जारी कर रहा है जो कोई इंसान बनाए नहीं रख सकता, या दुरुपयोग की शिकायतों में उसका इस्तेमाल हो रहा है। इनमें से कोई एक अवलोकन पर्याप्त है, और इनमें से किसी के लिए भी जरूरी नहीं कि आपने कुछ गलत किया हो। मुफ़्त स्तर इन सूचियों पर बेतहाशा ज्यादा दिखते हैं, क्योंकि जिस सेवा का उपयोग मुफ़्त हो वही थोक में अकाउंट बनाने वाले के लिए सबसे सस्ता औजार है, और जो डोमेन ऐसा ट्रैफ़िक खींचता है वह जल्दी नोटिस हो जाता है।
टेस्टिंग के लिए इसका नतीजा यह है कि ब्लॉकलिस्ट एक ऐसी पर्यावरण निर्भरता बन जाती है जो आपकी नहीं है। जो पाइपलाइन शुक्रवार को पास हुई और सोमवार को विफल हो गई, उसके अपने भंडार में ऐसा कोई परिवर्तन नहीं है जो इस अंतर को समझा सके, और डिबगिंग का मानक रास्ता — diff पढ़ो, स्थानीय रूप से दोहराओ — कुछ भी नहीं ढूंढेगा। पहचान का दूसरा पक्ष, यानी डोमेन सूची से आगे की जांच, इस दिशा में आगे का काम है।
स्टेजिंग वातावरण के लिए एक और पेच है। कई टीमें स्टेजिंग में अस्थायी डोमेन की रोकटोक बंद कर देती हैं ताकि उनके अपने टेस्ट पास हो जाएं, जिसका मतलब है कि ब्लॉकलिस्ट वाला रास्ता कभी परखा ही नहीं जाता। फिर रोकटोक के तर्क में मौजूद दोष बिना परखे प्रोडक्शन तक पहुंच जाता है, और उसकी पहली रिपोर्ट बिल्ड से नहीं, किसी उपयोगकर्ता से आती है।
क्या अपना डोमेन होने से गणित बदल जाता है?
यह लगभग हर उस चीज को बदल देता है जो अस्थिर थी। जब डोमेन आपका होता है, तो डिलीवरेबिलिटी का सवाल साझा प्रतिष्ठा की जगह आपकी अपनी भेजने की प्रतिष्ठा का हो जाता है, रिटेंशन विंडो वही होती है जो आपका मेलबॉक्स करता है, दर सीमा आपका अपना ढांचा होती है, और कोई तीसरे पक्ष की सूची यह तय नहीं करती कि आपका टेस्ट पास होगा या नहीं।
लागत शून्य नहीं होती, भले ही पैसा शून्य हो। आपको एक डोमेन चाहिए, एक MX रिकॉर्ड, एक मेलबॉक्स या एक प्रोसेसिंग स्क्रिप्ट, और कोई ऐसा जो समझता हो कि नए डोमेन से आया मेल कभी-कभी स्पैम में क्यों चला जाता है। यह ध्यान की असली लागत है, और यही कारण है कि टीमें सबसे पहले सार्वजनिक सेवा की ओर हाथ बढ़ाती हैं।
बदले में मिलता है ऐसा टेस्ट सुइट जो केवल तब विफल होता है जब सॉफ़्टवेयर विफल होता है। यह गुण जितना सुनाई देता है उससे कहीं ज्यादा मूल्यवान है, क्योंकि बिना समझ आने वाली विफलताओं वाला सुइट अनदेखा कर दिया जाता है, और अनदेखा किया गया सुइट किसी चीज की रक्षा नहीं करता। एक बार मेल का रास्ता आपके नियंत्रण में आ जाए, तो सत्यापन प्रवाह में विफलता का अर्थ है सत्यापन प्रवाह में दोष। सबसे छोटा संभव रूप यह है कि एक ही मेलबॉक्स अपने डोमेन के सारे पते स्वीकार कर ले और टेस्ट केस को अपने पते के निशान से पहचान ले।
एक बीच का विकल्प भी जानने लायक है: ऐसी सार्वजनिक टेस्ट मेल सेवा जो सामान्य अस्थायी डोमेन की जगह टेस्टिंग के लिए आरक्षित डोमेन पर पते जारी करती है। इनके ब्लॉकलिस्ट में पहुंचने की संभावना कम होती है क्योंकि इन्हें आम उपभोक्ताओं के लिए बेचा नहीं जाता, पर ये फिर भी एक तीसरा पक्ष हैं, और उपलब्धता के वही सवाल इन पर भी लागू होते हैं। इन्हें अपने डोमेन का विकल्प न मानें, इन्हें अस्थायी राहत मानें।
शून्य बजट वाली टीम भरोसेमंद मेल टेस्ट कैसे बनाए
शुरुआत यह करें कि अधिकतर टेस्ट से डिलीवरी हटा दें। ऐसा स्थानीय कैप्चर सर्वर जो संदेश भेजने की जगह प्राप्त करता है, टेम्पलेट रेंडरिंग, लिंक निकालना और कोड निकालना — तीनों कवर करता है, और यह बिना किसी नेटवर्क निर्भरता के मिलीसेकंड में चलता है। ज्यादातर मेल जांचें ट्रांसपोर्ट की नहीं, सामग्री की होती हैं, इसलिए यह डिफ़ॉल्ट होना चाहिए।
असली डिलीवरी को उन गिने-चुने टेस्ट के लिए बचाकर रखें जिन्हें वह वाकई चाहिए। एंड-टू-एंड सत्यापन, लिंक की समाप्ति, और मेलर तथा बाहरी सेवा के बीच की परस्पर क्रिया ऐसे मामले हैं जो असली संदेश को जायज ठहराते हैं, और ऐसे मामले आम तौर पर मुट्ठी भर होते हैं, सैकड़ों नहीं। इस समूह को छोटा रखना ही इसे अपने नियंत्रण वाले ढांचे पर चलाना किफायती बनाता है।
अगर आपको मुफ़्त सार्वजनिक मेलबॉक्स इस्तेमाल करना ही पड़े, तो उसे अपने अलग जॉब में रखें। ऐसा अलग पाइपलाइन चरण जिसके अस्थिर होने की छूट हो, साथ में पुनः प्रयास और स्पष्ट विफलता संदेश, यह रोकता है कि तीसरे पक्ष की गड़बड़ी किसी रिग्रेशन से अलग दिखे। रिलीज फ्रीज़ के दौरान उन टेस्ट को छोड़ने लायक चिह्नित करना एक व्यावहारिक समझौता है, बशर्ते हुई कवरेज हानि कहीं लिखी गई हो।
मेलबॉक्स को पहचानने लायक बनाएं, चाहे रास्ता कोई भी हो। ऐसा उपसर्ग जो वातावरण, रन और टेस्ट केस दर्ज करता है, प्राप्त संदेश को खोजने लायक बनाता है और सफाई को संभव बनाता है। बिना निशान वाला इनबॉक्स जिसमें साल भर के संदेश जमा हो जाते हैं, वह टेस्ट संपत्ति नहीं, रिटेंशन दायित्व है। संदेश कैप्चर हो जाने के बाद कौन सी जांचें करनी चाहिए, यह अलग विषय है और वह भी इसी सोच का हिस्सा है। ये नियम वही हैं जिनके इर्द-गिर्द यहां का टेम्परेरी मेल टूल बना है, और ये मुफ़्त तथा सशुल्क दोनों मेलबॉक्स पर लागू होते हैं।
कौन से मुफ़्त विकल्प वाकई स्वीकार्य हैं
मुफ़्त विकल्प तब स्वीकार्य है जब उसका विफलता तरीका दिखता हो और उसका असर दायरा छोटा हो। हाथ से एक बार इस्तेमाल किया गया मेलबॉक्स, यह पक्का करने के लिए कि पासवर्ड रीसेट का ईमेल आता है और ठीक से दिखता है, मुफ़्त अस्थायी डोमेन का बिलकुल उचित उपयोग है। कल उस पर कुछ निर्भर नहीं है, और अगर डोमेन अवरुद्ध हो गया तो आपको तुरंत दिख जाएगा।
यह अस्वीकार्य तब हो जाता है जब वही मेलबॉक्स स्वचालित सुइट के अनिवार्य रास्ते पर बैठा हो। अगर पाइपलाइन किसी ऐसे डोमेन पर संदेश आने की प्रतीक्षा में अटकी है जो किसी और के नियंत्रण में है, तो पाइपलाइन की विश्वसनीयता ऐसी सेवा का फलन है जिसका आपके प्रति कोई दायित्व नहीं, कोई सूचना अवधि नहीं, और आपके बिल्ड की परवाह करने का कोई प्रोत्साहन नहीं। गणित को कम आंकना आसान है जब एकमात्र दिखने वाली लागत शून्य हो, क्योंकि अनदेखी लागत उन विफलताओं पर खर्च हुए ध्यान के रूप में होती है जिनके पीछे किसी का परिवर्तन नहीं होता।
एक उपयोगी परीक्षा यह है कि पूछें, अगर सेवा बिना चेतावनी गायब हो जाए तो क्या होगा। अगर जवाब यह है कि एक बिल्ड लाल हो जाएगा और कोई दोपहर भर जांच में लगा देगा, तो मुफ़्त विकल्प एक डोमेन से ज्यादा महंगा पड़ रहा है। अगर जवाब यह है कि विकल्प मिलने तक हाथ से जांच नहीं हो सकती, तो लागत समझी हुई है और स्वीकार्य है।
दूसरे दर्जे की लागतें भी ईमानदारी से गिनना मदद करता है, क्योंकि मुफ़्त शायद ही स्टाफ के समय में मुफ़्त रहता है। किसी को यह सीखना पड़ता है कि सेवा कैसे व्यवहार करती है, पुनः प्रयास का तर्क लिखना पड़ता है, और यह सवाल झेलना पड़ता है कि रात का बिल्ड फिर क्यों विफल हुआ। उस ध्यान को उन महीनों की संख्या से गुणा करें जितने सुइट चलेगा, और उसकी तुलना एक डोमेन तथा एक कैप्चर स्क्रिप्ट को स्थापित करने में लगी एक दोपहर से करें। तुलना सामान्यतः सशुल्क रास्ते के पक्ष में जाती है, इसीलिए इतनी सारी टीमें अंततः अपना डोमेन रखने लगती हैं।
एक और सरल सवाल भी है: जिस प्रवाह का परीक्षण हो रहा है, क्या वह मुफ़्त डोमेन के पते के लिए वैसा ही व्यवहार करता है जैसा सामान्य पते के लिए। अगर आपका उत्पाद अस्थायी डोमेन अवरुद्ध करता है, तो टेस्ट में अस्थायी डोमेन इस्तेमाल करने का मतलब है कि आप अस्वीकृति का रास्ता परख रहे हैं, सफलता का नहीं। इन दोनों को मिला देना एक आम और महंगी भूल है, क्योंकि तब हरा टेस्ट किसी ऐसी चीज की पुष्टि कर रहा होता है जो उपयोगकर्ता के पास कभी नहीं पहुंचेगी।
संदेशों और पतों का उपयोग किस लिए नहीं करना चाहिए
टेस्टिंग के लिए बनाया गया पता एक काल्पनिक रिकॉर्ड है। यह किसी व्यक्ति का नहीं है, यह कोई ऐसा संपर्क बिंदु नहीं है जिसे कोई देखता हो, और इसका इस्तेमाल किसी का रूप धारण करने, अपने नहीं के अकाउंट तक पहुंच पाने, किसी मुफ़्त परीक्षण को उसकी शर्तों से आगे बढ़ाने, दर सीमा या सत्यापन नियंत्रण को लांघने, या किसी के लिए मायने रखने वाला मेल प्राप्त करने के लिए नहीं किया जाना चाहिए।
बजट की चर्चा में यह आखिरी बिंदु जोर देने लायक है, क्योंकि संसाधन तंग होने पर मुफ़्त मेलबॉक्स को टेस्टिंग के अलावा किसी और काम में लगाने का लालच सबसे तेज होता है। ऐसे डोमेन पर रखा गया सहायता पता, बिलिंग संपर्क या पासवर्ड रिकवरी बिंदु, जो समाप्त हो जाता है, उस चीज के लिए दायित्व है जिससे वह जुड़ा है — यह सवाल अलग है कि ऐसा करने की अनुमति है या नहीं।
कैप्चर किए गए संदेशों को भी अल्पजीवी मानें। वे असली ईमेल हैं, उनमें ऐसे असली मान हो सकते हैं जो किसी टेम्पलेट से चूक गए, और बिना विलोपन नीति वाला स्टेजिंग इनबॉक्स अंततः कुछ ऐसा रखने लगेगा जो उसे नहीं रखना चाहिए। तय समय पर हटाएं, और रिटेंशन अवधि ऐसी जगह लिखें जहां पूरी टीम देख सके। पता और पहचान वाले डेटा के लिए पहचान टूल के साथ यही अनुशासन रखें, और किसी भी निर्मित मान को सत्यापन के लिए इस्तेमाल करने से पहले सत्यापन नियम देख लें।
यहां जो कुछ भी चर्चा हुई है, वह आपके अपने सॉफ़्टवेयर को परखने के लिए है। बनाए गए पते और मेलबॉक्स परीक्षण की वस्तुएं हैं, पहचान नहीं, और इनका उपयोग किसी असली सत्यापन को पार करने, किसी के नाम पर असली अकाउंट खोलने, या किसी के संपर्क विवरण का प्रतिनिधित्व करने के लिए नहीं किया जा सकता। जिन पतों की जगह यह मेलबॉक्स बैठता है, उनका संरचनात्मक पक्ष भी उतना ही महत्वपूर्ण है — जब मेल के साथ असली पता डेटा भी चाहिए हो, तो पता टूल से निर्मित रिकॉर्ड लें और उन्हें भी काल्पनिक ही मानें।