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