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