मोबाइल परीक्षण के साथ आपको शिफ्ट-लेफ्ट की आवश्यकता क्यों है

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

नफरत वाली बात तब होती है जब प्रोजेक्ट की समयसीमा के कारण परीक्षण कम प्राथमिकता बन जाता है ... अक्सर इस हद तक कि यह एक बैकलॉग इच्छा सूची आइटम बन जाता है जो वर्तमान स्प्रिंट में शायद ही कभी सामने आता है। यह लगभग गारंटी देता है कि ग्राहक अप्रत्याशित परिणामों के साथ आपसे संपर्क करेंगे।

जैसे-जैसे सॉफ्टवेयर डेवलपमेंट लाइफसाइकल्स (SDLCs) परिपक्व होते गए हैं, परीक्षण आसान होता गया है, जिससे डेवलपर्स को यूनिट टेस्ट बनाने की अनुमति मिलती है जो मान्य किए जा रहे पहलू को पूरी तरह से कवर करते हैं। ChatGPT या GitHub Co-Pilot का उपयोग उस बिंदु तक परिपक्व हो गया है जहाँ ऐसे यूनिट टेस्ट स्वचालित रूप से उत्पन्न किए जा सकते हैं। निरंतर एकीकरण (CI) टूलिंग समाधान किसी भी पुल अनुरोध (PR) को मर्ज करने से पहले उच्च स्तर के कोड कवरेज को लागू करने के लिए बेहतर हुए हैं। ऐसा करने से टीमों को अपने विकास के साथ बाईं ओर शिफ्ट होने की अनुमति मिलती है - विकास चरण के दौरान समस्याओं को संबोधित करने के लिए मजबूर करना और रास्ते में सुविधाओं की लागत में कटौती करना।

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

मैं यह देखना चाहता था कि क्या मैं ऐसा कोई तरीका खोज सकता हूँ जिससे मोबाइल विकास और परीक्षण में शिफ्ट-लेफ्ट अवधारणा को अपनाया जा सके।

मोबाइल परीक्षण में क्या कमी है

उच्च स्तर पर, मोबाइल एप्लिकेशन स्पेस में उसी तरह से सुविधाओं और कार्यक्षमता का परीक्षण करने की क्षमता होनी चाहिए जिस तरह से आज API और वेब फ्रेमवर्क परीक्षण कर रहे हैं। इसका मतलब है कि भौतिक उपकरणों या एमुलेटर की सूची का उपयोग करके मैन्युअल रूप से परीक्षण करने के व्यवसाय से बाहर निकलना।

मोबाइल परीक्षण की यह आदर्श स्थिति यूआई-संचालित होगी ताकि उपयोगकर्ता गतिविधि पर केंद्रित गुप्त परीक्षण लिखने से बचा जा सके। यह दृष्टिकोण उन आंतरिक उपभोक्ताओं या उत्पाद स्वामियों तक टूलिंग का विस्तार कर सकता है जो अपनी दृष्टि को वास्तविकता के रूप में मान्य करना चाहते हैं।

पारंपरिक इकाई या एकीकरण परीक्षणों की तरह, मॉड्यूल पेश करने की क्षमता मोबाइल एप्लिकेशन के छोटे पहलुओं को मान्य कर सकती है और बड़े प्रवाह के लिए बिल्डिंग ब्लॉक के रूप में उपयोग की जा सकती है। ऐसा करने से, टीमें "सूखी" (खुद को दोहराना नहीं) रह पाएंगी और दोहराए गए काम से बच पाएंगी।

अंततः, इन परीक्षणों को ग्राफिकल UI द्वारा संचालित होने के बावजूद, CI/CD पाइपलाइन का हिस्सा बनने में सक्षम होना होगा।

इस आदर्श स्थिति में, मोबाइल सॉफ्टवेयर इंजीनियर अपने मोबाइल विकास और परीक्षण के लिए प्रभावी रूप से बाईं ओर स्थानांतरित हो सकते हैं।

आखिर "शिफ्ट लेफ्ट" क्या है?

यह स्पष्ट करना अच्छा विचार है कि जब मैं मोबाइल परीक्षण के लिए "बाईं ओर शिफ्ट" कहता हूं तो मेरा क्या मतलब है।

विकिपीडिया परीक्षण के लिए बाईं ओर शिफ्ट को इस प्रकार परिभाषित करता है:

"शिफ्ट-लेफ्ट टेस्टिंग सॉफ्टवेयर टेस्टिंग और सिस्टम टेस्टिंग का एक तरीका है जिसमें टेस्टिंग लाइफसाइकिल में पहले की जाती है (यानी प्रोजेक्ट टाइमलाइन पर बाईं ओर ले जाया जाता है)। यह 'जल्दी और अक्सर परीक्षण करें' कहावत का पहला भाग है। इसे 2001 में लैरी स्मिथ ने गढ़ा था।"

केवल शिफ्ट लेफ्ट को अपनाने से विकास चरण के दौरान दोषों की पहचान की जा सकती है। यह महत्वपूर्ण है क्योंकि समस्या का समाधान तब किया जा सकता है जब स्रोत पर ध्यान केंद्रित करने वाले इंजीनियर(ओं) के दिमाग में विशेषता ताज़ा हो।

शिफ्ट लेफ्ट अपनाने के कुछ लाभ इस प्रकार हैं:

• विकास के समय समस्याओं का पता लगाकर और उन्हें ठीक करके सुविधाएँ प्रदान करने में लागत में कमी लाना।
• डिलीवरी के काफी समय बाद समाधान पर पुनः विचार करने के लिए लगने वाले समय में कमी के कारण उच्च दक्षता।
• विकास चरण के दौरान पूर्णतः कवर करने और मान्य करने के लिए बाध्य होने के कारण उच्च गुणवत्ता।

अंततः, शिफ्ट लेफ्ट अवधारणा से प्रतिस्पर्धात्मक लाभ प्राप्त होगा, जब समाधान उपभोक्ताओं तक पहुंचेंगे, जो मान्य होंगे और अपेक्षा के अनुरूप काम करेंगे।

टोस्का के बारे में

पिछले साल, मैंने अपने "ट्राइसेंटिस टेस्टिम का उपयोग करके ग्राहक-सामना करने वाले ऐप की गुणवत्ता में सुधार" लेख में ट्राइसेंटिस टेस्टिम के उपयोग का पता लगाया था। मैं इस बात से प्रभावित था कि GO-आधारित RESTful API और Vue.js वेब-आधारित क्लाइंट का उपयोग करके अपने मैजिक 8 बॉल समाधान को सत्यापित करना कितना आसान था। मैं देखना चाहता था कि क्या ट्राइसेंटिस के पास ऐसा समाधान है जो टीमों को मोबाइल परीक्षण के लिए बाईं ओर शिफ्ट करने की अनुमति देगा।

पता चला कि उनके पास टोस्का नामक एक उत्पाद है।

Tosca उत्पाद कोड रहित परीक्षण निर्माण प्रदान करता है, जिससे छोटे मॉड्यूल का निर्माण संभव होता है जिन्हें पुनः उपयोग किया जा सकता है और स्वचालित किया जा सकता है। इन मॉड्यूल को लेगो ब्लॉक के रूप में माना जा सकता है जिन्हें उनके बीच एक मानकीकृत अनुबंध के उपयोग के कारण जहाँ भी आवश्यकता हो, जोड़ा जा सकता है। Tosca आपके फ़ीचर के लिए मोबाइल परीक्षण बनाने में मदद करने के लिए AI का लाभ उठाने की क्षमता प्रदान करके चीजों को अधिक पारंपरिक विकास जीवनचक्र के करीब ले जाता है।

टोस्का, ट्राइसेंटिस मोबाइल एजेंट के माध्यम से भारी सीखने की अवस्था के बिना ओपन सोर्स एपियम प्रोजेक्ट की शक्ति का भी लाभ उठाता है। यह मेरे पिछले लेख में दी गई सभी शक्तियों को मोबाइल विकास के साथ शिफ्ट लेफ्ट यात्रा में शामिल करने की अनुमति देता है।

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

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

आप Tosca का उपयोग iOS या Android फ़ोन पर सीधे परीक्षण करने के लिए कर सकते हैं, साथ ही Android Studio जैसे IDE के माध्यम से उपलब्ध एमुलेटर या सिमुलेटर के माध्यम से भी कर सकते हैं। Tosca का उपयोग करके, आप अपने एप्लिकेशन को स्कैन कर सकते हैं और उससे परीक्षण मामले बना सकते हैं:

एक बार जब Tosca ने परीक्षण मामले बना लिए, तो आप भी अपने स्वयं के परीक्षण मामले बना सकते हैं।

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

इस उदाहरण में, हमने अपने Tosca मोबाइल परीक्षण मामले के लिए तीन मॉड्यूल का उपयोग किया है। हम परीक्षण करते हैं:

1. ब्राउज़र खोलना और हमारे ऐप के एंडपॉइंट पर जाना
2. किसी विशेष प्रकार के वाहन का चयन करना
3. उस विशेष वाहन के बारे में फॉर्म भरना

ध्यान दें कि हमें केवल सैंपल इनपुट प्रदान करना था (स्क्रीनशॉट में, हम ऊपर हाइलाइट किए गए चरण 3 के लिए ऐसा कर रहे हैं)। एक बार परीक्षण पूरा हो जाने पर, आपको Tosca पर एक डायग्नोस्टिक्स रिपोर्ट प्राप्त होगी।

मोबाइल परीक्षण के लिए शिफ्ट छोड़ दी गई

टोस्का जैसे उत्पाद का लाभ उठाकर, मोबाइल विकास पर ध्यान केंद्रित करने वाले सॉफ्टवेयर इंजीनियर मोबाइल परीक्षण के लिए बची हुई सामग्री का उपयोग करके अपनी टीमों को प्रतिस्पर्धात्मक लाभ दे सकते हैं:

• मोबाइल सुविधाओं का सत्यापन, सेवाओं और वेब फ्रेमवर्क के समान, विकास चरण के दौरान किया जाता है।
• परीक्षण यूआई द्वारा संचालित होते हैं, जिसे आंतरिक उपभोक्ताओं और उत्पाद स्वामियों तक विस्तारित किया जा सकता है, जिससे उनके दृष्टिकोण को ठोस बनाने में मदद मिल सके।
• परीक्षण सूट को "शुष्क" मॉड्यूल के संग्रह से बनाया जा सकता है जो नई सुविधाओं और कार्यक्षमता को पूरी तरह से कवर करने के लिए संरचित हैं।
• मोबाइल उपकरणों के स्वामित्व और रखरखाव के बिना भी उनकी विस्तृत सूची के विरुद्ध परीक्षण किया जा सकता है।
• प्राथमिक कोड शाखा में नई सुविधाएं शुरू करने से पहले, संबंधित पीआर ने यूआई-जनरेटेड परीक्षणों को उसी तरह बुलाया होगा जिस तरह से एपीआई या वेब फ्रेमवर्क सीआई/सीडी पाइपलाइनों में यूनिट या एकीकरण परीक्षण निष्पादित किए जाते हैं।

निष्कर्ष

मेरे पाठकों को याद होगा कि मैं निम्नलिखित मिशन वक्तव्य पर केंद्रित रहा हूं, जो मुझे लगता है कि किसी भी आईटी पेशेवर पर लागू हो सकता है:

"अपना समय उन सुविधाओं/कार्यक्षमताओं को प्रदान करने पर केंद्रित करें जो आपकी बौद्धिक संपदा के मूल्य को बढ़ाती हैं। बाकी सभी चीज़ों के लिए फ्रेमवर्क, उत्पादों और सेवाओं का लाभ उठाएँ।" - जे. वेस्टर

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

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

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

आपका दिन सचमुच बहुत अच्छा हो!