टीम पूरे स्प्रिंट के लिए ऐप का परीक्षण करती है, निर्माण जारी करती है - और एक सप्ताह बाद समर्थन में शिकायतें आती हैं: "मेरे शहर में कीमत अलग है", "पुश नहीं आया", "मैं कार्ड से भुगतान नहीं कर सकता।" कारण लगभग हमेशा एक ही होता है: सभी परीक्षण एक ही कॉर्पोरेट IP से किए गए थे, जबकि वास्तविक उपयोगकर्ता अन्य क्षेत्रों, नेटवर्क और ऑपरेटरों से आते हैं। इस लेख में, हम 7 विशिष्ट QA परिदृश्यों का विश्लेषण करेंगे, जिन्हें IP पता बदले बिना भौतिक रूप से जांचना असंभव है, और दिखाएंगे कि प्रॉक्सी के साथ परीक्षण बुनियादी ढांचे को कैसे सेटअप करें।
क्यों ऑफिस IP - QA के लिए अंधा क्षेत्र है
आजकल अधिकांश मोबाइल ऐप IP पते के आधार पर निर्णय लेते हैं: उपयोगकर्ता के देश, इंटरफेस की भाषा, मुद्रा, उपलब्ध भुगतान विधियाँ, सुविधाओं का सेट और यहां तक कि सदस्यता की कीमत निर्धारित करते हैं। जब पूरा QA विभाग एक ही ऑफिस से एक स्थिर IP डेटा सेंटर या कॉर्पोरेट नेटवर्क से परीक्षण करता है, तो ऐप हमेशा बैकएंड से एक ही प्रतिक्रिया प्राप्त करता है - जैसे कि सभी परीक्षक दुनिया के एक ही बिंदु पर हैं।
परिणामस्वरूप, भू-स्थान, समय क्षेत्र, संचार ऑपरेटर या कनेक्शन के प्रकार पर निर्भर बग्स परीक्षण स्टैंड पर पुन: उत्पन्न नहीं होते हैं। वे केवल उत्पादन में प्रकट होते हैं - जब कजाकिस्तान का उपयोगकर्ता रूबल में कीमतें देखता है, जर्मन उपयोगकर्ता अपने नेटवर्क में GCM की ब्लॉकिंग के कारण पुश नहीं प्राप्त करता है, और इंडोनेशियाई ग्राहक कार्ड से भुगतान नहीं कर सकता है क्योंकि उसके क्षेत्र के लिए भुगतान प्रदाता कनेक्ट नहीं है। रिलीज के बाद ऐसे बग को ठीक करना QA चरण में पकड़ने की तुलना में कई गुना महंगा होता है।
समाधान - रिलीज से पहले वास्तविक भूगोल और नेटवर्क विविधता का अनुकरण करना। इसके लिए QA इंजीनियर प्रॉक्सी सर्वर का उपयोग करने लगे हैं: वे परीक्षण उपकरण या एमुलेटर को किसी भी देश, शहर या यहां तक कि संचार ऑपरेटर में "स्थानांतरित" करने की अनुमति देते हैं बिना वहां भौतिक रूप से जाने या दर्जनों सिम कार्ड खरीदने की आवश्यकता के।
परिदृश्य 1: भू-सामग्री और क्षेत्रीय मूल्य
अधिकांश सदस्यता वाले ऐप्स (स्ट्रीमिंग, फिटनेस, शिक्षा) विभिन्न देशों में विभिन्न कीमतें दिखाते हैं - इसे भू-मूल्य निर्धारण कहा जाता है। यदि QA केवल स्थानीय IP से सदस्यता की प्रक्रिया की जांच करता है, तो यह सुनिश्चित करना असंभव है कि तुर्की, ब्राजील या भारत के उपयोगकर्ता के लिए मूल्य सही ढंग से, सही मुद्रा में और सही गोलाई के साथ प्रदर्शित होता है।
सामग्री कैटलॉग के साथ भी यही समस्या है: फिल्मों, उत्पादों या प्रचारों की लाइब्रेरी अक्सर क्षेत्रीय होती है। वास्तविक उपयोगकर्ता जो स्क्रीन देखता है, उसे देखने के लिए सही देश में भौतिक रूप से "उपस्थित" होना आवश्यक है। ऐसे परीक्षणों के लिए रेसिडेंशियल प्रॉक्सी का उपयोग करना सुविधाजनक है - वे किसी विशेष देश के वास्तविक घरेलू उपयोगकर्ताओं का IP प्रदान करते हैं, और ऐप का बैकएंड अनुरोध को सामान्य जैविक ट्रैफ़िक के रूप में मानता है, न कि डेटा सेंटर से आने वाले अनुरोध के रूप में।
व्यावहारिक चेक: 8-10 प्रमुख बाजारों (यूएसए, जर्मनी, ब्राजील, भारत, तुर्की, जापान, नाइजीरिया, यूएई) पर सदस्यता प्रक्रिया का परीक्षण करें, कीमत और मुद्रा के स्क्रीनशॉट लें, और उत्पाद की मूल्य सूची के साथ मिलान करें। यह "क्यों मेरी कीमत अलग है" जैसी शिकायतों का बड़ा हिस्सा बंद कर देता है।
परिदृश्य 2: भू-प्रतिबंध और पहुंच की सीमाएं
फिनटेक ऐप्स, स्ट्रीमिंग सेवाएं और कुछ गेम कानूनी या लाइसेंसिंग कारणों से कुछ देशों से पहुंच को प्रतिबंधित करते हैं। QA को यह सुनिश्चित करना चाहिए कि ऐप वहां काम करता है जहां इसे करना चाहिए, बल्कि यह भी कि यह सही तरीके से (और क्रैश नहीं) उन स्थानों पर पहुंच से इनकार करता है जहां इसे नहीं करना चाहिए।
एक सामान्य बग: "सेवा आपके क्षेत्र में उपलब्ध नहीं है" के बजाय, उपयोगकर्ता को एक सफेद स्क्रीन या अंतहीन लोडर दिखाई देता है - क्योंकि डेवलपर्स ने केवल अनुमत देश से खुश रास्ते का परीक्षण किया। भू-प्रतिबंधों की जांच के लिए कई प्रतिबंधित न्यायालयों से लगातार कनेक्शन की आवश्यकता होती है, जो जीवित सिम कार्ड और यात्रा पर अवास्तविक है, जबकि प्रॉक्सी के माध्यम से यह प्रत्येक देश के लिए 10-15 मिनट लेता है।
इस परिदृश्य के लिए, शहर के स्तर पर सटीक भू-स्थान के साथ प्रॉक्सी उपयुक्त हैं, न कि केवल देश के स्तर पर - यह महत्वपूर्ण है कि "जर्मनी सामान्य रूप से" नहीं, बल्कि यदि लाइसेंस देश के भीतर क्षेत्र द्वारा सीमित है तो विशिष्ट भूमि की जांच की जाए।
परिदृश्य 3: A/B और देशों में चरणबद्ध रोलआउट
फीचर-फ्लैग और चरणबद्ध रोलआउट लगभग हमेशा भू-स्थान से जुड़े होते हैं: नई सुविधा पहले कनाडा में सक्षम होती है, एक सप्ताह बाद ऑस्ट्रेलिया में, फिर - हर जगह। यदि QA टीम भौतिक रूप से एक ही देश में है, तो वह मूल रूप से नए संस्करण को अन्य क्षेत्रों से पहले नहीं देख सकती, जब तक कि फ्लैग उसके पास नहीं पहुंचता।
वैश्विक रिलीज से पहले फीचर का परीक्षण करने के लिए, पहले रोलआउट की पहली लहर के देश में भू-स्थान को बदलना आवश्यक है। यह एक सबसे सामान्य कार्यों में से एक है, जिसे प्रॉक्सी एंटी-डिटेक्ट ब्राउज़रों या उपकरणों के एमुलेटर के साथ हल करते हैं - आवश्यक देश में IP बदलें, ऐप सत्र को पुनः प्रारंभ करें, अन्य उपयोगकर्ताओं से पहले फीचर देखें और बग्स को खोजने का समय मिले जब तक कि फ्लैग 100% ऑडियंस तक नहीं पहुंचता।
एक महत्वपूर्ण बिंदु: A/B परीक्षणों के लिए पूरे परीक्षण चक्र के लिए IP पर स्थिर "पंजीकरण" की आवश्यकता होती है - सत्र अनुरोधों के बीच देशों के बीच नहीं कूदना चाहिए, अन्यथा बैकएंड प्रयोग की शर्तों को भ्रमित करेगा और कभी नियंत्रण समूह दिखाएगा, कभी परीक्षण समूह।
परिदृश्य 4: स्थानीयकरण और पुश-नोटिफिकेशन
पुश-नोटिफिकेशन का पाठ, इसे भेजने का समय और यहां तक कि वितरण का तथ्य अक्सर उपकरण के भू-स्थान पर निर्भर करता है। कुछ देशों में पुश प्रदाता (Firebase, APNs, स्थानीय SMS गेट्स) देरी से काम करते हैं या वैकल्पिक मार्गों के माध्यम से - और जो परीक्षण वातावरण में मॉस्को के ऑफिस से सही ढंग से वितरित होता है, वह इंडोनेशिया में उपयोगकर्ता तक नहीं पहुंच सकता है क्योंकि स्थानीय संचार प्रदाता द्वारा कुछ पुश सर्वरों को ब्लॉक किया गया है।
इसके अलावा, इंटरफेस का स्थानीयकरण अक्सर IP के आधार पर ट्रिगर होता है, न कि केवल सिस्टम की भाषा पर: एक उपयोगकर्ता जिसका फोन अंग्रेजी में है, लेकिन IP फ्रांस से है, मिश्रित इंटरफेस देख सकता है - शीर्षक फ्रेंच में, बटन अंग्रेजी में। ऐसे बग 100% अदृश्य होते हैं, यदि पूरा QA एक ही भू-क्षेत्र से परीक्षण कर रहा है।
अनुशंसित प्रक्रिया: उत्पाद के प्राथमिक बाजारों से 5-7 स्थानीयताएँ लें, प्रॉक्सी के माध्यम से संबंधित IP से कनेक्ट करें, डिवाइस/एमुलेटर पर सिस्टम की भाषा बदलें और यह रिकॉर्ड करें कि ऐप कौन सा पाठ और तिथि/संख्या का प्रारूप दिखाता है। IP-देश और सिस्टम की भाषा में असंगतता - एक अलग अनिवार्य मामला है, जिसे अक्सर भुला दिया जाता है।
परिदृश्य 5: भुगतान विधियाँ और धोखाधड़ी प्रणाली
मोबाइल ऐप में उपलब्ध भुगतान विधियों का सेट लगभग हमेशा देश पर निर्भर करता है: एक क्षेत्र में कार्ड और Apple Pay से भुगतान उपलब्ध है, दूसरे में - केवल स्थानीय वॉलेट (Mercado Pago, Boleto, UPI, QIWI), तीसरे में - संचार ऑपरेटर के माध्यम से भुगतान। यदि QA आवश्यक देश से कनेक्ट नहीं हो सकता है, तो भुगतान परिदृश्यों का आधा हिस्सा उत्पादन तक बिना परीक्षण के रह जाता है, जहां गलती की कीमत - खोई हुई आय और समर्थन में शिकायतें हैं।
एक अलग समस्या - भुगतान प्रदाताओं की धोखाधड़ी प्रणाली। वे IP के आधार पर लेनदेन के जोखिम का आकलन करते हैं: डेटा सेंटर के IP से अनुरोध लगभग निश्चित रूप से अस्वीकृति या अतिरिक्त 3D-सुरक्षित जांच प्राप्त करेगा, भले ही कार्ड पूरी तरह से मान्य हो। यह परीक्षण परिणामों को विकृत करता है: QA भुगतान में अस्वीकृति देखता है और डेवलपर्स को बग रिपोर्ट करता है, जबकि समस्या कोड में नहीं है, बल्कि इस तथ्य में है कि परीक्षण IP धोखाधड़ी स्कोरिंग के लिए संदिग्ध दिखता है।
भुगतान परिदृश्यों के लिए रेसिडेंशियल प्रॉक्सी या मोबाइल प्रॉक्सी का उपयोग करना बेहतर है - वे वास्तविक उपयोगकर्ता के सामान्य ट्रैफ़िक के रूप में दिखते हैं और धोखाधड़ी प्रणाली के अनावश्यक ट्रिगर को सक्रिय नहीं करते हैं, जो भुगतान प्रवाह के व्यवहार की अधिक ईमानदार तस्वीर देता है।
परिदृश्य 6: मोबाइल नेटवर्क में व्यवहार
एक ऐप जो ऑफिस Wi-Fi पर 200 एमबीपीएस पर शानदार काम करता है, मोबाइल नेटवर्क 3G/4G में अस्थिर कनेक्शन, ऑपरेटर का NAT प्रॉक्सी और उच्च विलंबता में पूरी तरह से अलग व्यवहार कर सकता है। अनुरोधों के समय-सीमा, पुनः प्रयास, वीडियो/ऑडियो गुणवत्ता में गिरावट, ऑफ़लाइन मोड का काम - यह सभी मोबाइल इंटरनेट की स्थिति के करीब परीक्षण करना महत्वपूर्ण है, न कि स्थिर ऑफिस नेटवर्क में।
अतिरिक्त जटिलता: कुछ संचार ऑपरेटर अपने स्वयं के प्रॉक्सी और CGNAT का उपयोग करते हैं, जिसके कारण सर्वर वास्तविक उपयोगकर्ता के IP को नहीं देखता है, बल्कि ऑपरेटर का सामान्य IP देखता है, जिसके माध्यम से हजारों ग्राहक एक साथ गुजरते हैं। यह दर सीमित करने और IP के माध्यम से भू-स्थान पर प्रभाव डालता है - ऐप "सोच सकता है" कि उपयोगकर्ता उस शहर में है जहां वह भौतिक रूप से है।
ऐसे व्यवहार को पुन: उत्पन्न करने के लिए, मोबाइल प्रॉक्सी की आवश्यकता होती है, जो आवश्यक देश के वास्तविक सिम कार्ड के माध्यम से इंटरनेट में प्रवेश करती है - यह NAT, विलंबता और गति की सटीक तस्वीर देती है, जिसे सामान्य डेटा सेंटर IP पर प्राप्त नहीं किया जा सकता है।
परिदृश्य 7: दर सीमित करना और बॉट्स से सुरक्षा
कई मोबाइल ऐप्स के बैकएंड API एक IP से अनुरोधों की संख्या को सीमित करते हैं (दर सीमित करना) और बॉट्स से सुरक्षा का उपयोग करते हैं, जो कैप्चा या व्यवहारात्मक विश्लेषण के समान होता है। यदि QA टीम एक कॉर्पोरेट IP से ऑटो-टेस्ट चला रही है, तो कुछ समय बाद सर्वर 429 त्रुटियों के साथ प्रतिक्रिया देना शुरू कर देता है या अनुरोधों को पूरी तरह से ब्लॉक कर देता है - और परीक्षण ऐप में बग के कारण नहीं गिरते, बल्कि इस कारण से कि बैकएंड ने परीक्षण ट्रैफ़िक को हमले के रूप में लिया।
यह विशेष रूप से लोड और पुनरागमन परीक्षण के लिए प्रासंगिक है, जब थोड़े समय में सैकड़ों समान अनुरोधों (पंजीकरण, लॉगिन, कार्ट में जोड़ना) को निष्पादित करना आवश्यक होता है। विभिन्न IP के बीच अनुरोधों का वितरण प्रॉक्सी पूल के माध्यम से API को ईमानदारी से लोड करने की अनुमति देता है बिना धोखाधड़ी सुरक्षा के सक्रियण के कारण परिणामों को विकृत किए बिना।
इस प्रकार के बड़े पैमाने पर स्वचालित परीक्षण के लिए अक्सर डेटा सेंटर प्रॉक्सी का उपयोग करना अधिक फायदेमंद होता है - वे उच्च मात्रा में अनुरोधों पर तेजी से और सस्ते होते हैं, और इस परिदृश्य में भू-स्थान की सटीकता उतनी महत्वपूर्ण नहीं होती जितनी गति और कनेक्शन की स्थिरता।
QA के लिए उपकरण और प्रॉक्सी सेटअप
एमुलेटर (Android Studio Emulator, Xcode Simulator) पर मैनुअल QA के लिए प्रॉक्सी को एमुलेटर के नेटवर्क सिस्टम सेटिंग्स के माध्यम से सेट किया जाता है: प्रॉक्सी सर्वर का IP और पोर्ट, उपयोगकर्ता नाम और पासवर्ड निर्दिष्ट करें, यदि प्रमाणीकरण का उपयोग किया जाता है। वास्तविक उपकरणों के लिए, समान सेटिंग्स Wi-Fi कनेक्शन में "उन्नत सेटिंग्स → प्रॉक्सी → मैन्युअल" के माध्यम से उपलब्ध हैं।
ऐप और बैकएंड के बीच ट्रैफ़िक को पकड़ने और विश्लेषण करने के लिए QA इंजीनियर चार्ल्स प्रॉक्सी या प्रॉक्सिमन का उपयोग करते हैं - दोनों उपकरण ऐप के ट्रैफ़िक को बाहरी प्रॉक्सी के माध्यम से पास करने की अनुमति देते हैं और एक साथ सभी HTTP/HTTPS अनुरोध, भू-स्थान के हेडर और सर्वर के उत्तर देख सकते हैं। यह निदान के लिए सुविधाजनक है: तुरंत स्पष्ट होता है कि बैकएंड अनुरोध के क्षण में कौन सा IP और कौन सा देश "देखता है"।
Appium या Espresso के माध्यम से स्वचालित परीक्षण के लिए, प्रॉक्सी को सत्र की इच्छित क्षमताओं में या परीक्षण सेट चलाने से पहले उपकरण की सिस्टम सेटिंग्स के माध्यम से निर्दिष्ट किया जाता है। मोबाइल ऐप्स के परीक्षण के लिए क्लाउड प्लेटफ़ॉर्म (BrowserStack, Sauce Labs) भी कस्टम प्रॉक्सी कनेक्शन का समर्थन करते हैं, जो दुनिया के प्रत्येक बिंदु पर भौतिक उपकरणों के बिना विभिन्न देशों से एक ही ऑटो-टेस्ट परिदृश्य चलाने की अनुमति देता है।
यदि टीम के पास ऐप का वेब संस्करण है या विभिन्न भू-स्थान के साथ कई खातों का समानांतर परीक्षण करना आवश्यक है, तो एंटी-डिटेक्ट ब्राउज़रों (Dolphin Anty, AdsPower, Multilogin) का उपयोग करना सुविधाजनक होता है - प्रत्येक प्रोफ़ाइल को अलग-अलग प्रॉक्सी से जोड़ा जाता है, और QA इंजीनियर एक साथ 5-10 सत्रों को विभिन्न देशों से बिना कुकीज़ और कैश में भ्रम के खोल सकता है।
प्रत्येक परिदृश्य के लिए कौन सा प्रॉक्सी प्रकार चुनें
| QA परिदृश्य | अनुशंसित प्रॉक्सी प्रकार | क्यों |
|---|---|---|
| भू-मूल्य और सामग्री | रेसिडेंशियल | सामान्य उपयोगकर्ता के ट्रैफ़िक के रूप में दिखते हैं, धोखाधड़ी से सुरक्षा को सक्रिय नहीं करते हैं |
| भू-प्रतिबंध | रेसिडेंशियल | शहर/क्षेत्र तक सटीक भू-स्थान |
| A/B और रोलआउट | रेसिडेंशियल / डेटा सेंटर | पूरे परीक्षण चक्र के लिए स्थिर सत्र |
| पुश और स्थानीयकरण | मोबाइल | ऑपरेटरों के माध्यम से वितरण की वास्तविक स्थिति का अनुकरण करते हैं |
| भुगतान और धोखाधड़ी | रेसिडेंशियल / मोबाइल | धोखाधड़ी प्रणाली के झूठे सक्रियण का कम जोखिम |
| मोबाइल ऑपरेटरों के नेटवर्क | मोबाइल | ऑपरेटरों के वास्तविक सिम कार्ड, NAT और विलंबता का सटीक अनुकरण |
| दर सीमित करना / लोड परीक्षण | डेटा सेंटर | उच्च गति और बड़े मात्रा में अनुरोधों पर कम लागत |
रिलीज से पहले चेकलिस्ट
निर्माण को उत्पादन में छोड़ने से पहले, भू-स्थान और नेटवर्क से संबंधित जांचों की एक छोटी सूची पर जाएं - यह ऊपर वर्णित अधिकांश बग्स को बंद कर देता है:
- कम से कम 5 प्रमुख बाजारों में सदस्यता के लिए कीमतें और मुद्रा की जांच की गई
- प्रतिबंधित देशों में भू-प्रतिबंध स्क्रीन का सही प्रदर्शन जांचा गया
- पहली लहर के रोलआउट देश में फीचर-फ्लैग का परीक्षण किया गया वैश्विक रिलीज से पहले
- विभिन्न देशों के विभिन्न संयोजनों से IP और सिस्टम की भाषा के साथ पुश-नोटिफिकेशन की जांच की गई
- प्रत्येक प्रमुख क्षेत्र के लिए अलग से उपलब्ध भुगतान विधियों की जांच की गई
- धोखाधड़ी प्रणाली के झूठे सक्रियण के बिना भुगतान प्रवाह का परीक्षण किया गया
- ऐप को मोबाइल नेटवर्क (3G/4G) की स्थिति में परीक्षण किया गया, न कि केवल Wi-Fi पर
- एक IP से समानांतर लॉन्च के दौरान दर सीमित करने के कारण ऑटो-टेस्ट नहीं गिरते हैं
निष्कर्ष
मोबाइल ऐप एक ही समय में दर्जनों देशों, नेटवर्क और भुगतान पारिस्थितिक तंत्र में जीवित रहता है, जबकि QA टीम भौतिक रूप से एक ही ऑफिस में एक IP के साथ बैठी होती है। यही कारण है कि वास्तविक दर्शकों और परीक्षण की स्थितियों के बीच यह अंतर अधिकांश "अव्याख्येय" बग्स को जन्म देता है, जो उत्पादन तक पहुंचते हैं। ऊपर दिए गए सात परिदृश्य - भू-मूल्य, भू-प्रतिबंध, A/B रोलआउट, पुश और स्थानीयकरण, भुगतान, मोबाइल ऑपरेटरों के नेटवर्क और दर सीमित करना - ऐसे जोखिमों का मुख्य हिस्सा बंद कर देते हैं।
यदि आपकी टीम उस ऐप का परीक्षण कर रही है जो क्षेत्रीय सामग्री, कीमतों या भुगतानों के साथ काम करता है, तो वास्तविक उपयोगकर्ताओं का अनुकरण करने के लिए परीक्षण स्टैक में रेसिडेंशियल प्रॉक्सी को जोड़ना समझदारी है, और मोबाइल कनेक्शन और पुश वितरण के परिदृश्यों के लिए - मोबाइल प्रॉक्सी को विशिष्ट ऑपरेटरों से जोड़ना। यह QA चरण में महत्वपूर्ण बग्स को खोजने की अनुमति देता है, न कि स्टोर में उपयोगकर्ताओं की शिकायतों के बाद।