मान लें कि आपकी कंपनी का सबसे ज़रूरी सॉफ़्टवेयर अचानक काम करना बंद कर देता है. ऐसे में क्या होगा? ऑर्डर खो सकते हैं, समयसीमाएं छूट सकती हैं, लेकिन ग्राहक शिकायत ज़रूर करेंगे.
इस बुरे सपने से बचा जा सकता है. इसके लिए, लगातार और सही तरीके से टेस्टिंग की प्रोसेस लागू करें, ताकि गड़बड़ियां होने से पहले ही उन्हें पकड़ा जा सके. हालांकि, अपने संगठन में ऐसी प्रोसेस लागू करना आसान नहीं है.
इस दस्तावेज़ में, आपको उन सभी बातों के बारे में बताया जाएगा जो आपको अपनी कंपनी में टेस्टिंग शुरू करते समय ध्यान में रखनी चाहिए. साथ ही, यह भी बताया जाएगा कि लंबे समय में टेस्टिंग से आपको कैसे फ़ायदा मिल सकता है.
प्रॉडक्ट टीमों के लिए, टेस्टिंग के सबसे सही तरीके
इस दस्तावेज़ के पहले हिस्से में, आपके वर्कफ़्लो में टेस्टिंग लागू करने की प्रोसेस के बारे में बताया गया है.
अपनी टीम में टेस्टिंग की संस्कृति लागू करना
अपनी टीम में टेस्टिंग को सही तरीके से लागू करने के लिए, यह ज़रूरी है कि सभी लोग एक ही सोच के साथ काम करें. साथ ही, क्वालिटी को बोझ नहीं, बल्कि एक निवेश के तौर पर देखें. यह एक ऐसी प्रोसेस है जिसमें, किसी भी सांस्कृतिक बदलाव की तरह, समय और एक जैसा रवैया बनाए रखने की ज़रूरत होती है.
इस संस्कृति को आकार देने में, गड़बड़ियों पर चर्चा करने के लिए नियमित मीटिंग मददगार साबित हो सकती हैं. इन मीटिंग में, गड़बड़ियों के असर, उनकी वजह, और उन्हें ठीक करने में लगने वाले समय के बारे में चर्चा की जा सकती है. इससे, यह समझने में मदद मिलती है कि ऐसी गड़बड़ियों को होने से रोकना क्यों ज़रूरी है.
टीम में एक ऐसा व्यक्ति होने से, जो इस काम की निगरानी करता है और इसे आगे बढ़ाता है, सफलता की संभावना बढ़ सकती है. ऐसा व्यक्ति जो टीम या पूरे संगठन के लिए दिशा-निर्देश तय करता है, सबसे सही तरीके इकट्ठा करता है और उन्हें शेयर करता है. साथ ही, सभी लेवल पर इस काम को बढ़ावा देता है.
एक और तरीका यह हो सकता है कि आपके प्रॉडक्ट के लिए सहायता की भूमिका को रोटेट किया जाए. अपने ग्राहकों से सीधे और बिना फ़िल्टर किए गए सुझाव या राय पाना. साथ ही, अपने प्रॉडक्ट के साथ उन्हें रोज़ाना आने वाली समस्याओं के बारे में जानना, प्रॉडक्ट मैनेजर, डिज़ाइनर, और डेवलपर के लिए एक अहम अनुभव हो सकता है.
इसका मकसद यह है कि आपकी टीम में हर कोई यह समझे कि क्वालिटी एक सुविधा है. यह उतनी ही ज़रूरी है जितनी आपके प्रॉडक्ट के लिए बनाई गई कोई अन्य सुविधा. जब सभी लोग इस सोच को अपना लेते हैं, तो यह समझना आसान हो जाता है कि टेस्ट भी एक सुविधा है. ऐसा इसलिए, क्योंकि टेस्ट ही यह पक्का करते हैं कि प्रॉडक्ट की क्वालिटी अच्छी हो.
टेस्टिंग की सिलसिलेवार प्रोसेस
प्रॉडक्ट डेवलपमेंट में शामिल अलग-अलग टीमों के बीच तालमेल होने के बाद, टेस्ट के इस्तेमाल और उनकी अहमियत को और बेहतर बनाया जा सकता है.
टेस्ट को "पूरा होने की परिभाषा" का हिस्सा बनाना
टेस्ट को सुविधा की ज़रूरी शर्त के तौर पर जोड़ने से, यह तय हो जाता है कि कोई सुविधा तब तक लॉन्च नहीं की जा सकती, जब तक उसकी सही तरीके से और अपने-आप जांच न हो जाए
नियमित तौर पर टेस्ट करना
ऑटोमेटेड टेस्ट लागू करने के बाद, ये डेवलपमेंट की प्रोसेस के हर चरण में आपकी सुरक्षा कर सकते हैं. इन्हें चलाने के लिए, किसी व्यक्ति की ज़रूरत नहीं होती. साथ ही, इन्हें डेवलपमेंट पाइपलाइन के हर अहम चरण में चलाया जा सकता है. उदाहरण के लिए:
- हर कमिट पर.
- पुल के हर अनुरोध पर.
- हर पूरी रिलीज़ या एनवायरमेंट में बदलाव के बाद.
अगर अपने प्रोडक्शन एनवायरमेंट में तीसरे पक्ष की सेवाओं का इस्तेमाल किया जा रहा है, तो अपने टेस्ट को प्रोडक्शन के ख़िलाफ़ चलाना भी सही हो सकता है. इससे यह पक्का किया जा सकता है कि तीसरे पक्ष के एपीआई, उम्मीद के मुताबिक काम कर रहे हैं.
मेट्रिक तय करना और इकट्ठा करना
मेट्रिक का सेट तय करना ज़रूरी है, ताकि आपके टेस्ट की परफ़ॉर्मेंस और आपके कारोबार पर टेस्टिंग वर्कफ़्लो के असर को मेज़र किया जा सके. यहां मेट्रिक के कुछ उदाहरण दिए गए हैं जिनका इस्तेमाल किया जा सकता है:
- हर महीने रिलीज़: हर महीने ज़्यादा रिलीज़, डेवलपमेंट की बेहतर प्रोसेस का संकेत दे सकती हैं. ऑटोमेटेड टेस्टिंग यहां अहम भूमिका निभाती है. इससे यह पक्का होता है कि रिलीज़ को भरोसे के साथ आगे बढ़ाया जा सके.
- बग रिपोर्ट: बग रिपोर्ट में कमी आना, इस बात का अच्छा संकेत हो सकता है कि आपकी टेस्टिंग (और डेवलपमेंट की प्रोसेस) असरदार हैं.
- टेस्ट कवरेज: हालांकि, यह कभी भी सटीक मेट्रिक नहीं होती, लेकिन कवरेज इस बात का अच्छा संकेत हो सकता है कि अहम इस्तेमाल के मामलों की कितनी गहराई से जांच की जा रही है.
ध्यान दें कि इन मेट्रिक पर अन्य फ़ैक्टर का भी असर पड़ता है, जिससे ये गलत हो सकती हैं. उदाहरण के लिए, छुट्टियों के सीज़न में आपकी रिलीज़ की संख्या कम हो सकती है, जबकि बग रिपोर्ट बढ़ सकती हैं. इसलिए, सिर्फ़ कुछ मेट्रिक पर भरोसा न करें. साथ ही, पक्का करें कि आपकी टीम के पास मौजूद अन्य डेटा के साथ इनकी तुलना की जाए.
जब आपकी टीम इन चरणों को सही तरीके से लागू करती है, तो लंबे समय में आपके प्रॉडक्ट की क्वालिटी बेहतर होगी. हालांकि, अब भी आपके पास और भी विकल्प हैं!
सिस्टम एडमिन के लिए, टेस्टिंग के सबसे सही तरीके
प्रॉडक्ट टीमें अपने दम पर काम नहीं कर सकतीं. वे हार्डवेयर, टूल, और इन्फ़्रास्ट्रक्चर पर निर्भर करती हैं. इनकी देखभाल सिस्टम एडमिन करते हैं. हालांकि, सिस्टम एडमिन आम तौर पर प्रॉडक्ट डेवलपमेंट में सीधे तौर पर योगदान नहीं देते, लेकिन वे डेवलपमेंट वर्कफ़्लो को बेहतर बना सकते हैं. उदाहरण के लिए, कंपनी में कुछ उपयोगकर्ता ग्रुप, ब्राउज़र के जिस वर्शन का इस्तेमाल करते हैं उसे मैनेज करके.
लेख के इस दूसरे हिस्से में, यह बताया गया है कि Chrome के रिलीज़ चैनल और Enterprise की नीतियों का इस्तेमाल करके, यह कैसे काम करता है.
Chrome के रिलीज़ चैनल
रिलीज़ के चार चैनल हैं: स्टेबल, बीटा, डेव, और कैनरी.
ज़्यादा जानने के लिए, Chrome के रिलीज़ चैनल देखें.
किसी संगठन में चैनलों का इस्तेमाल करना
प्रॉडक्ट टीमों की संरचना, संगठनों के हिसाब से अलग-अलग होती है, क्योंकि सॉफ़्टवेयर डेवलपमेंट के लिए कोई एक तरीका सभी के लिए सही नहीं होता. उदाहरण के लिए, हम ऐसी टीम मानेंगे जिसमें ये भूमिकाएं हैं: प्रॉडक्ट मैनेजमेंट, यूएक्स और यूआई, इंजीनियरिंग, ऑपरेशन, और सहायता.
इस तरह के संगठन के लिए, इन चैनलों का इस्तेमाल किया जा सकता है:
- प्रॉडक्ट मैनेजमेंट: पीएम आम तौर पर स्टेबल चैनल पर हो सकते हैं, ताकि वे ज़्यादातर उपयोगकर्ताओं की तरह ही वर्शन का इस्तेमाल कर सकें. कभी-कभी वे बीटा या डेव चैनल का इस्तेमाल कर सकते हैं, अगर वे किसी ऐसी सुविधा पर काम कर रहे हैं जिसके लिए ऐसे एपीआई की ज़रूरत है जो अब तक लॉन्च नहीं हुआ है.
- इंजीनियरिंग और यूएक्स: इन टीमों के कुछ सदस्य डेव चैनल पर हो सकते हैं, ताकि उन्हें व्यू ट्रांज़िशन जैसी नई सुविधाओं का ऐक्सेस मिल सके. भले ही, ये सुविधाएं स्टेबल वर्शन में न हों.
- ऑपरेशन: बीटा चैनल पर हो सकते हैं, ताकि उपयोगकर्ताओं पर असर डालने वाली गड़बड़ियों का अनुमान लगाया जा सके.
- सहायता: स्टेबल चैनल पर रह सकती है, ताकि यह पक्का किया जा सके कि वे प्रॉडक्ट के साथ उसी ब्राउज़र से इंटरैक्ट कर रहे हैं जिसका इस्तेमाल आपके ज़्यादातर ग्राहक करते हैं.
चैनलों को मैनेज करने के लिए, Enterprise की नीतियों का इस्तेमाल करना
Chrome, सिर्फ़ दिशा-निर्देश देने और यह तय करने का विकल्प नहीं देता कि किस चैनल का इस्तेमाल करना है. बल्कि, यह Enterprise और एडमिन टूल भी उपलब्ध कराता है, ताकि यह मैनेज किया जा सके कि हर उपयोगकर्ता किस चैनल का इस्तेमाल कर रहा है. यह फ़ायदेमंद है, क्योंकि इससे टेस्टिंग की सुविधा तुरंत कुछ लोगों से बढ़कर, उपयोगकर्ताओं के तय सेट तक पहुंच जाती है. इससे, गड़बड़ियों की पहचान जल्द से जल्द और ट्रैक किए जा सकने वाले तरीके से की जा सकती है.
अगर आपको इस लेवल का कंट्रोल चाहिए, तो हम यह कॉन्फ़िगरेशन इस्तेमाल करने का सुझाव देंगे:
- कर्मचारी (ऐप्लिकेशन के उपयोगकर्ता): गड़बड़ी होने के जोखिम को कम करने के लिए, ज़्यादातर कर्मचारियों को स्टेबल चैनल पर होना चाहिए. Chrome की टेस्ट टीम ने इसकी पूरी तरह से जांच कर ली है. इसके अलावा, उपयोगकर्ताओं का एक छोटा प्रतिशत (5 से 10%) बीटा चैनल पर हो सकता है. इस चैनल पर, स्टेबल वर्शन में आने वाली सुविधाओं की झलक 4 से 6 हफ़्तों तक देखी जा सकती है. इससे एडमिन को रिलीज़ में संभावित समस्याओं का पता लगाने में मदद मिल सकती है. साथ ही, रिलीज़ को सभी के लिए उपलब्ध कराने से पहले, समस्याओं को हल करने के लिए ज़्यादा समय मिल सकता है.
- आईटी विभाग: आईटी विभाग के सदस्य, जिनमें सिस्टम एडमिन भी शामिल हैं, बीटा या डेव चैनल पर हो सकते हैं. इससे उन्हें Chrome के स्टेबल वर्शन में आने वाली सुविधाओं की झलक 4 से 6 या 9 से 12 हफ़्तों तक के लिए मिल सकती है.
लंबे समय तक इस्तेमाल किए जा सकने वाले रिलीज़ चैनल
ऐसा हो सकता है कि प्रॉडक्ट डेवलपमेंट, प्लान के मुताबिक तेज़ी से न हो. साथ ही, Chrome के रिलीज़ की एक महीने की कैडेंस बहुत ज़्यादा हो सकती है. इस इस्तेमाल के मामले के लिए, Chrome एक एक्सटेंडेड स्टेबल चैनल उपलब्ध कराता है. इससे सुविधाओं के अपडेट कम मिलते हैं, लेकिन सुरक्षा से जुड़ी समस्याओं को ठीक किए जाने के अपडेट मिलते रहते हैं. यह चैनल हर आठ हफ़्ते में अपडेट होता है.
नीचे दिए गए डायग्राम में दिखाया गया है कि Chrome के अलग-अलग रिलीज़ चैनलों के ज़रिए, अलग-अलग माइलस्टोन कैसे आगे बढ़ते हैं: :
- पहले चार हफ़्तों के लिए, स्टेबल और एक्सटेंडेड स्टेबल, दोनों में एक ही वर्शन शिप किए जाते हैं. इसके बाद, दोनों अलग-अलग हो जाते हैं.
- एक्सटेंडेड बीटा चैनल नहीं है. इसके बजाय, स्टेबल और एक्सटेंडेड स्टेबल, दोनों को स्थिर करने के लिए, चार हफ़्तों के स्टैंडर्ड बीटा साइकल का इस्तेमाल किया जाता है. Enterprise को आठ हफ़्तों के एक्सटेंडेड स्टेबल वर्शन का विकल्प चुनने पर, बीटा चैनल को आज की तरह ही इस्तेमाल करना चाहिए. इससे, उन समस्याओं की पहचान पहले से की जा सकती है जो उनके एनवायरमेंट पर असर डाल सकती हैं.
एक्सटेंडेड स्टेबल वर्शन के उपयोगकर्ताओं के लिए, डेव और बीटा चैनलों की अहमियत
स्टेबल चैनल, दो हफ़्तों के रिलीज़ साइकल पर तेज़ी से बढ़ रहा है. साथ ही, आपका संगठन, आठ हफ़्तों के एक्सटेंडेड स्टेबल साइकल को अपना रहा है, ताकि टेस्टिंग के लिए ज़्यादा समय मिल सके. हालांकि, डेव और बीटा चैनलों का इस्तेमाल करना अब भी ज़रूरी है. "एक्सटेंडेड डेव या बीटा" के लिए कोई अलग चैनल नहीं हैं. स्टेबल और एक्सटेंडेड स्टेबल, दोनों रिलीज़ को स्थिर करने के लिए, स्टैंडर्ड डेव और बीटा चैनलों का इस्तेमाल किया जाता है.
डेव और बीटा चैनलों का इस्तेमाल जारी रखकर, Enterprise उन समस्याओं की पहचान पहले से कर सकते हैं जो उनके एनवायरमेंट पर असर डाल सकती हैं. डेव और बीटा चैनलों पर, आने वाली स्टेबल रिलीज़ की झलक चार हफ़्तों तक देखी जा सकती है. एक्सटेंडेड स्टेबल वर्शन के उपयोगकर्ताओं के लिए, यह झलक आठ हफ़्तों के फ़ीचर अपडेट से पहले, संभावित गड़बड़ियों का पता लगाने और उन्हें ठीक करने के लिए ज़रूरी है.
डेव और बीटा चैनल, आठ हफ़्तों के एक्सटेंडेड स्टेबल एनवायरमेंट में होने वाले किसी भी बदलाव के लिए, शुरुआती चेतावनी सिस्टम के तौर पर काम करते हैं. इससे यह पक्का होता है कि आपके Enterprise ऐप्लिकेशन, साथ काम करते रहें. सिस्टम एडमिन, उपयोगकर्ताओं के एक छोटे और तय ग्रुप (उदाहरण के लिए, ऐप्लिकेशन के 5 से 10% उपयोगकर्ता) को डेव और बीटा चैनलों पर असाइन कर सकते हैं, ताकि इस फ़ायदे को ज़्यादा से ज़्यादा बढ़ाया जा सके.
नतीजा
सॉफ़्टवेयर डेवलपमेंट कंपनियों के लिए, टेस्टिंग एक अहम हिस्सा है. इससे यह पक्का होता है कि उनके प्रॉडक्ट की क्वालिटी अच्छी हो. साथ ही, सिस्टम एडमिन के लिए भी यह एक अहम चरण है, ताकि किसी संगठन के कर्मचारियों को अच्छी क्वालिटी वाले सॉफ़्टवेयर का ऐक्सेस दिया जा सके और कारोबार की प्रोसेस में कोई रुकावट न आए.
अपने संगठन में टेस्टिंग वर्कफ़्लो को लागू करने में सफलता पाने के लिए, यह ज़रूरी है कि सभी लोग एक ही सोच के साथ काम करें. साथ ही, यह समझें कि क्वालिटी और इसलिए टेस्टिंग एक सुविधा है.
इस दस्तावेज़ में, हमने आपके संगठन में टेस्टिंग के सबसे सही तरीकों को इंटिग्रेट करने के अलग-अलग तरीकों की समीक्षा की है. मौजूदा टेस्टिंग टूल की पूरी समीक्षा के लिए, हमारा लेख बिना किसी रुकावट के, ऑटोमेटेड टेस्टिंग के लिए Chrome के टूल देखें.
टेस्टिंग के लिए, शुरू से आखिर तक की गाइडेंस पाने के लिए, हमारा हाल ही में लॉन्च हुआ Learn Testing कोर्स और टेस्ट ऑटोमेशन के सबसे सही तरीके web.dev पर भी देखें.