क्या एमुलेटर पर सफल बिल्ड असली फोन पर लॉन्च के लिए तैयार है?

शुक्रवार की शाम एमुलेटर पर हरा दिखता रिलीज़ कैंडिडेट लॉन्च के लिए तैयार नहीं माना जा सकता। असली फोन पर कैमरा, अनुमति, नेटवर्क, मेमोरी और ऑपरेटिंग सिस्टम के साथ परीक्षण ही बताता है कि ग्राहक ऐप चला पाएगा या लॉन्च वाले दिन अटक जाएगा।

1999 में नासा की मार्स क्लाइमेट ऑर्बिटर टीम भी एक ऐसी प्रणाली पर भरोसा कर रही थी जिसके अलग-अलग हिस्से अपने स्तर पर सही काम करते दिख रहे थे। अंतरिक्ष यान मंगल के करीब पहुंच चुका था। तभी संपर्क टूट गया। उस समय टीम को यह नहीं मालूम था कि यान दोबारा संकेत भेजेगा या मिशन समाप्त हो चुका है।

बाद में नासा के Mars Climate Orbiter Mishap Investigation Board Phase I Report ने मूल गलती दर्ज की: एक सॉफ्टवेयर घटक ने थ्रस्टर से जुड़ा डेटा अमेरिकी पाउंड-सेकंड इकाई में दिया, जबकि दूसरा हिस्सा उसे न्यूटन-सेकंड मानकर चला। दोनों प्रणालियां काम कर रही थीं। उनके बीच की वास्तविक कड़ी गलत थी। नतीजे में अंतरिक्ष यान नियोजित ऊंचाई से बहुत नीचे मंगल के वातावरण में पहुंचा और मिशन खो गया।

मोबाइल रिलीज़ में दांव अलग हैं, पर विफलता का ढांचा अक्सर यही होता है। एमुलेटर ऐप के अपने हिस्से को जांचता है। ग्राहक का फोन उन जोड़ोें को सामने लाता है जहां ऐप हार्डवेयर, अनुमति, नेटवर्क, स्टोरेज और ऑपरेटिंग सिस्टम से मिलता है।

एमुलेटर की हरी स्क्रीन क्या छिपा सकती है

शुक्रवार के रिलीज़ कैंडिडेट में लॉगिन चलता है, कैमरा खुलता है और भुगतान की स्क्रीन लोड होती है। टीम बिल्ड को तैयार मान लेती है। फिर वही ऐप उस फोन पर लगाया जाता है जिसे ग्राहक रोज जेब में लेकर चलता है।

कैमरा अनुमति देने के बाद दृश्य काला रह सकता है। फोटो चुनते समय ऐप बंद हो सकता है। कमजोर नेटवर्क पर भुगतान पूरा होने के बाद पुष्टि अटक सकती है। बैकग्राउंड में भेजा गया ऐप लौटने पर पुरानी स्थिति दिखा सकता है। बड़े फॉन्ट या हिंदी इंटरफेस में मुख्य बटन स्क्रीन से बाहर जा सकता है।

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

यही वजह है कि एक फोन पर मिला लॉन्च अवरोधक दोष मामूली QA टिप्पणी नहीं होता। वह उस धारणा को गलत साबित करता है जिस पर रिलीज़ निर्णय टिका था।

असली फोन पर किन सीमाओं को टकराना चाहिए

भौतिक डिवाइस परीक्षण का उद्देश्य हर स्क्रीन पर उंगली फेरना नहीं है। सबसे जोखिम भरे रास्तों को उन परिस्थितियों में चलाना है जहां ग्राहक उन्हें इस्तेमाल करेगा।

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

कैमरा, माइक्रोफोन, ब्लूटूथ, लोकेशन, पुश नोटिफिकेशन और बायोमेट्रिक प्रमाणीकरण जैसी क्षमताएं हार्डवेयर तथा सिस्टम नीतियों पर निर्भर करती हैं। इनके लिए “एमुलेटर पर चला” सीमित प्रमाण है।

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

ऑन-डिमांड भौतिक डिवाइस और समानांतर परीक्षण सेवाएं इस काम को आसान बना सकती हैं। फिर भी दूर से स्ट्रीम हुआ डिवाइस हर सवाल का उत्तर नहीं देता। नेटवर्क बदलना, तापमान, बैटरी दबाव, कैमरे की वास्तविक गुणवत्ता और लंबे उपयोग के बाद जमा स्थिति के लिए हाथ में पकड़ा फोन अब भी उपयोगी है।

शुक्रवार की रिलीज़ के लिए स्पष्ट रोक नियम

सबसे महंगा दोष वह नहीं जो शुक्रवार को मिलता है। सबसे महंगा दोष वह है जिसे सोमवार को ग्राहक, सहायता टीम और ऐप स्टोर की समीक्षाएं एक साथ खोजती हैं।

रिलीज़ से पहले एक छोटा प्रमाणपत्र बनाएं। उसमें बिल्ड संख्या, फोन मॉडल, ऑपरेटिंग सिस्टम संस्करण, जांचा गया मुख्य रास्ता और परिणाम दर्ज हों। “QA हो गया” लिखना प्रमाण नहीं है। “नए इंस्टॉल पर फोटो लेकर अपलोड पूरा हुआ” उपयोगी प्रमाण है।

रोक नियम पहले तय करें। लॉगिन, डेटा सहेजना, भुगतान, सदस्यता बहाली, कैमरा कैप्चर या क्रैश में विफलता मिले तो बिल्ड आगे नहीं जाएगा। समय कम होने पर जांच का दायरा घटाया जा सकता है, पर पास होने की परिभाषा नहीं।

एक व्यक्ति परीक्षण करे और दूसरा रिलीज़ का निर्णय ले, तो पुष्टि पूर्वाग्रह कम होता है। बिल्ड बनाने वाला व्यक्ति अक्सर वही रास्ता चुनता है जिसे वह सही जानता है। नया परीक्षक ग्राहक की तरह गलत क्रम, अस्वीकृत अनुमति और अधूरा इनपुट लेकर आता है।

लॉन्च तारीख से अधिक मूल्यवान प्रमाण

मार्स क्लाइमेट ऑर्बिटर की विफलता यह नहीं सिखाती कि सॉफ्टवेयर पर भरोसा नहीं करना चाहिए। वह बताती है कि अलग-अलग सही दिखने वाले हिस्सों के बीच की सीमा को प्रत्यक्ष प्रमाण चाहिए। इकाइयों का मेल वहां जांचना था जहां दो प्रणालियां जुड़ रही थीं।

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

हरी स्क्रीन आत्मविश्वास देती है। दर्ज किया हुआ डिवाइस परीक्षण निर्णय लेने लायक प्रमाण देता है।