साइन-अप और QA जांच में अस्थायी ईमेल का उपयोग

स्टेजिंग या लोकल वातावरण इस्तेमाल करें, जहां असली ग्राहकों को सूचनाएं न जाती हों। नकली विवरण वाला टेस्ट खाता बनाएं और अस्थायी पता तभी दें जब सेवा अनुमति देती हो। पासवर्ड, उत्पादन रिकॉर्ड, भुगतान जानकारी और ग्राहक ईमेल को टेस्ट से बाहर रखें। अस्थायी इनबॉक्स भी बाहरी मेलबॉक्स है; उसमें मौजूद जानकारी को तीसरी पक्ष की सेवा से संभाला गया डेटा मानें।

नए उपयोगकर्ता वाला ही फॉर्म और रास्ता इस्तेमाल करके पता दर्ज करें। पेज अनुरोध स्वीकार करे तो जांचें कि उसी पते के इनबॉक्स में संदेश आया या नहीं। भेजने वाले का नाम, विषय, झलक और समर्थित डिवाइस पर संदेश का सामान्य रूप देखें। पुष्टि लिंक केवल टेस्ट वातावरण में खोलें। नतीजा और जहां प्रक्रिया रुकी उसे दर्ज करें; फॉर्म बार-बार जमा न करें।

स्टेजिंग अनुमति दे तो सही और गलत पता, दूसरा अनुरोध, देर से आया संदेश, इस्तेमाल किया लिंक और खत्म हुई पुष्टि अवधि भी जांचें। देखें कि पेज उपयोगकर्ता को अगला कदम समझाता है या नहीं। रीसेंड बटन अनियंत्रित संदेश न भेजे और नया कोड या लिंक साफ दिखे। अपेक्षित व्यवहार लिखें, ताकि दूसरा परीक्षक भी जांच दोहरा सके।

ईमेल वास्तविक डिलीवरी रास्ते से किसी ऐसे पते पर पहुंच रहा है जिसे आप खोल सकते हैं, यह देखने के लिए अस्थायी इनबॉक्स उपयोगी है। स्थायी इनबॉक्स पहचान, संदेश API, तय सफाई या निजी टेस्ट डेटा वाली स्वचालित जांच के लिए यह कम उपयुक्त हो सकता है। ऐसी जरूरत में समर्पित ईमेल टेस्टिंग सेवा या टीम का नियंत्रित मेलबॉक्स चुनें। टूल वही लें जिससे टेस्ट का सवाल हल हो।

स्टेजिंग प्रक्रिया के अनुसार टेस्ट खाते हटाएं या उनकी अवधि खत्म होने दें, दस्तावेजों से सेव किए टेस्ट पते हटाएं और संदेश की सामग्री सार्वजनिक बग रिपोर्ट में कॉपी न करें। संदेश में पहुंच लिंक या कोड हो तो उसकी अवधि खत्म होने तक उसे गोपनीय मानें। वातावरण, ब्राउज़र और नतीजे का छोटा रिकॉर्ड रखें, ताकि आगे कोड की गलती और ईमेल डिलीवरी की समस्या में अंतर समझ आए।