मेन्यू

QA परीक्षक को रिलीज़ और परिनियोजन प्रबंधन प्रक्रिया के बारे में क्या पता होना चाहिए

what qa tester should know about release

समस्याओं को खत्म करने के लिए हमारे साधन का प्रयास करें

आज हमारी टीम की बैठक में, प्रबंधक ने सभी के साथ जाँच की परीक्षण निष्पादन के लिए तत्परता । उन्होंने उल्लेख किया 'कल सुबह तक क्यूए के लिए कोड तैयार हो जाएगा'। जब उन्होंने कहा कि 'कोड तैयार हो जाएगा' तो उनका क्या मतलब था, क्या इसका मतलब यह है कि डेवलपर्स आज रात को क्यूए वातावरण में कोड लिखने जा रहे हैं?

उनका वास्तव में मतलब था कि रात में तैनाती की योजना बनाई गई है और नए कोड को परीक्षण के लिए क्यूए वातावरण में तैनात किया जाएगा।

आप में से कई अब पूछ सकते हैं कि तैनाती क्या है और वे वास्तव में इसमें क्या करते हैं?

क्यूए के लिए रिलीज और तैनाती प्रबंधन प्रक्रिया

आप क्या सीखेंगे:

QA टीम के लिए समग्र रिलीज़ और परिनियोजन प्रबंधन प्रक्रिया और महत्व

  • हम वास्तव में विभिन्न वातावरण क्यों बनाए रखते हैं?
  • कोड एक वातावरण से दूसरे में कैसे स्थानांतरित होता है?

मैं इस लेख में निम्नलिखित विषयों को कवर करूंगा

  1. परीक्षकों को रिलीज और तैनाती प्रक्रिया के बारे में पता होना क्यों महत्वपूर्ण है?
  2. विभिन्न वातावरण
  3. बिल्ड एंड डिप्लॉयमेंट से आपका क्या मतलब है?
  4. नियोजित बनाम आपातकालीन तैनाती
  5. क्यूए चेकलिस्ट - तैनाती से पहले और बाद में

# 1 परीक्षकों को तैनाती प्रक्रिया के बारे में पता होना क्यों महत्वपूर्ण है?

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

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

# २। विभिन्न वातावरण

विभिन्न वातावरण

उपरोक्त वर्गीकरण में मैंने 4 सबसे महत्वपूर्ण वातावरण को कवर किया है, जो कि अधिकांश संगठन का अनुसरण करते हैं, हालांकि, कई ग्राहक मंचन, पूर्व-मंचन आदि जैसे बहुत अधिक वातावरण बनाए रखते हैं। इसके अलावा, नामकरण सम्मेलन अलग हो सकता है।

  • DEV - देव पर्यावरण कोड लिखने के लिए विकास टीम द्वारा बनाया और बनाए रखा जाता है। इस वातावरण की पहुँच केवल विकास दल को दी गई है। आमतौर पर क्यूए टीम के पास इस वातावरण तक पहुंच नहीं होती है। इस वातावरण का उपयोग ज्यादातर देव टीम द्वारा उनकी इकाई परीक्षण के लिए किया जाता है।
  • क्यूए - क्यूए पर्यावरण वह है जहां परीक्षण वास्तव में होता है। यह वातावरण QA ​​टीम के स्वामित्व में है। DEV टीम के पास इस वातावरण तक पहुंच नहीं है। डिजाइन और कोडिंग पूरा होने के बाद, QA टीम को परीक्षण निष्पादन करने के लिए QA वातावरण में कोड ले जाया जाता है।
  • UAT - उपयोगकर्ता स्वीकृति परीक्षण एक ऐसा वातावरण है जहाँ व्यापार उपयोगकर्ताओं द्वारा परीक्षण किया जाता है। यह सिस्टम परीक्षण पूरा होने के बाद किया जाता है। प्रमुख उद्देश्य व्यापार के दृष्टिकोण से प्रणाली का परीक्षण करना है। इस वातावरण तक पहुंच केवल व्यावसायिक उपयोगकर्ताओं को दी गई है। हालांकि, कुछ अवसरों पर वे क्यूए सहायता की तलाश करते हैं, ऐसी परिस्थितियों में, क्यूए टीम को पर्यावरण तक अस्थायी पहुंच दी जाती है।
  • PROD - PROD पर्यावरण वास्तविक लाइव वातावरण है जो वास्तविक उपयोगकर्ताओं के संपर्क में है और DEV और QA टीमों में से किसी ने भी इस वातावरण तक पहुंच नहीं पढ़ी / लिखी है। प्रोडक्शन सपोर्ट टीमों को उत्पादन पर्यावरण से जुड़े मुद्दों को हल करने के लिए रखा जाता है।

यह भी पढ़ें=> कैसे प्रभावी रूप से 'टेस्ट बेड' तैयार करें और टेस्ट पर्यावरण दोषों को कम करें

# 3 आपको बिल्ड एंड डिप्लॉयमेंट से क्या मतलब है

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

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

एक बार बिल्ड तैनात होने के बाद, क्यूए टीम को करने के लिए सूचित किया जाता है सत्यापन परीक्षण का निर्माण करें (बीवीटी) और यदि यह सफल है, तो टीम शेष प्रदर्शन करती है क्रियात्मक परीक्षण ।

कैसे जावा के साथ .jar फ़ाइलें खोलने के लिए

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

बिल्ड 1.0.0 या 1.0.03 नंबर का उपयोग करके बनाए रखा जाता है। इसलिए, यह संभव है कि 1.0.01 का निर्माण DLL v0.2 चल रहा हो और निर्माण 1.0.03 DLL v0.5 चल रहा हो। क्यूए टीम के लिए यह सुनिश्चित करना महत्वपूर्ण हो जाता है कि परीक्षण शुरू होने से पहले पर्यावरण में सही निर्माण को तैनात किया जाए। प्रत्येक बिल्ड के हिस्से के रूप में प्रदान किए गए परिवर्तनों का ट्रैक रखना हमेशा एक अच्छा विचार है।

एक अलग तैनाती टीम को बनाए रखना हमेशा एक अच्छा अभ्यास होता है क्योंकि यह एक पर्यावरण से दूसरे वातावरण में कोड के सुचारू संचालन में मदद करता है।

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

निर्माण और तैनाती

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

यदि कुछ विवरण छूट जाते हैं, तो बदलाव तैनाती के लिए अनुमोदित नहीं होते हैं। टीम तब तय करती है कि परिवर्तन अगले दिन की तैनाती का हिस्सा हो सकता है या नहीं। क्यूए टेस्ट लीड को यह सुनिश्चित करने के लिए अनुमोदन के लिए कहा गया है कि परिवर्तन किसी भी मौजूदा परीक्षण को प्रभावित नहीं करेगा। बैठक में, अंतिम परिनियोजन आइटम की योजना बनाई जाती है।

स्वीकृत सूची परिनियोजन टीम द्वारा तैनाती के दिन काम किया जाता है। टीम प्रत्येक परिवर्तन के रूप में (डेवलपर्स द्वारा प्रदान की गई) रूप में परिभाषित कार्यक्रमों का एक सेट चलाती है और फिर संचार को परिनियोजन पूर्ण के रूप में बाहर भेजती है।

परिनियोजन पूर्ण संदेश QA टीम को एक संकेत प्रदान करता है, कि परिवर्तन / नया कोड परीक्षण के लिए तैयार है।

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

प्रोडक्ट की ज़्यादातर तैनाती देर रात में की जाती है, जब अंतिम उपयोगकर्ताओं द्वारा पर्यावरण के प्रभावित होने की संभावना कम होती है।

# 4 नियोजित बनाम आपातकालीन तैनाती

प्रत्येक संगठन परिनियोजन कैलेंडर रखता है। कई ग्राहक सप्ताह में एक बार की तैनाती का पालन करते हैं और कई लोग द्वि-साप्ताहिक के लिए जाते हैं, कहते हैं कि नियोजित तैनाती केवल मंगलवार को होनी चाहिए या मंगलवार और शुक्रवार को हो सकती है। यदि परिनियोजन के लिए नियोजित दिन छुट्टी पर पड़ता है, तो परिनियोजन के दिन बदल सकते हैं।

उपरोक्त अनुभाग में, मैंने उस प्रक्रिया को कवर किया है जो किसी भी के लिए अनुसरण की जाती है नियोजित तैनाती ।

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

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

# 5 क्यूए चेकलिस्ट - तैनाती से पहले और बाद में

तैनाती से पहले -

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

तैनाती के बाद -

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

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

निष्कर्ष

आशा है कि उपरोक्त लेख ने आपको समग्र सॉफ्टवेयर विकास चक्र के एक हिस्से के रूप में जारी समग्र रिलीज और तैनाती प्रबंधन प्रक्रिया के बारे में एक विचार दिया। यह सिर्फ एक सामान्य प्रक्रिया थी जिसका अधिकांश संगठनों में पालन किया जाता था, हालांकि कई ग्राहकों के अलग-अलग प्रोटोकॉल होते हैं।

लेखक : यह भयानक लेख एसटीएच टीम की सदस्य प्रिया आर द्वारा लिखा गया है।

क्या आपको यह प्रक्रिया मददगार लगी? हमें अपने संगठन में तैनाती की प्रक्रिया के बारे में बताएं।

अनुशंसित पाठ

^