एजाइल टेस्ट ऑटोमेशन फ्रेमवर्क

⚡ स्मार्ट सारांश

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

  • 🔘 मुख्य तनाव: स्वचालन स्थिरता को महत्व देता है जबकि एजाइल परिवर्तन को महत्व देता है, इसलिए परीक्षण कवरेज की तुलना में परीक्षण चयन अधिक महत्वपूर्ण है।
  • जलप्रपात का विरोधाभास: परंपरागत स्वचालन में एक स्थिर अनुप्रयोग, विशेषज्ञ स्क्रिप्टर और उच्च सेटअप लागत की आवश्यकता होती है।
  • Sprint यथार्थ बात: एक से चार सप्ताह का स्प्रिंट बड़े स्क्रिप्ट को डिजाइन करने, कोड करने और मान्य करने के लिए शायद ही कभी उपयुक्त होता है।
  • 🧪 अन्वेषणात्मक नहीं: स्वचालित परीक्षण ज्ञात व्यवहार की पुष्टि करते हैं; वे नए और नवीन दोषों की खोज नहीं करते हैं।
  • उपकरण का चयन: प्रतिबंधित लाइसेंस वाले उपकरण उस खुले सहयोग के विपरीत हैं जिस पर एजाइल टीमें निर्भर करती हैं।
  • 📈 सर्वोत्तम योग्य: स्पष्ट उत्तीर्ण या असफल परिणामों के साथ दोहराव वाले, डेटा-प्रधान प्रतिगमन जांच अच्छी तरह से स्वचालित हो जाते हैं।

एजाइल टेस्ट ऑटोमेशन फ्रेमवर्क

एजाइल स्वचालन परीक्षण

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

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

एजाइल और स्वचालन का संयोजन एजाइल में स्वचालन में परिणत होता है।

वॉटरफॉल पद्धति में स्वचालन बनाम एजाइल पद्धति में स्वचालन

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

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

इसलिए ये दोनों स्थितियां टेस्ट सूट पर बहुत अलग-अलग मांगें रखती हैं:

फ़ैक्टर वॉटरफॉल में स्वचालन एजाइल में स्वचालन
आवेदन स्थिति स्क्रिप्टिंग शुरू होने से पहले स्थिर और स्वीकृत होना आवश्यक है। हर स्प्रिंट में बदलाव करना, अक्सर स्क्रिप्टिंग के दौरान।
समय उपलब्ध एक समर्पित स्वचालन चरण जो भी एक से चार सप्ताह के स्प्रिंट के भीतर समाहित हो सके
कौन पटकथा लिखता है? स्वचालन विशेषज्ञों की एक अलग टीम डिलीवरी टीम, परीक्षक और डेवलपर एक साथ
प्राथमिक लक्ष्य एक बड़े रिग्रेशन सूट में दीर्घकालिक लागत में कमी अभी-अभी निर्मित वृद्धि पर त्वरित प्रतिक्रिया
रखरखाव जोखिम कम, क्योंकि आवश्यकताएं धीरे-धीरे बदलती हैं उच्च, क्योंकि आवश्यकताएँ लगातार बदलती रहती हैं

एजाइल मेथोडोलॉजी में ऑटोमेशन कैसे करें

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

एजाइल उबाऊ दस्तावेज़ीकरण को नकारता है और खोजपूर्ण परीक्षण को प्राथमिकता देता है।

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

एजाइल टेस्ट ऑटोमेशन के लिए मूलभूत बिंदु

स्प्रिंट की पूरी क्षमता को स्वचालन के लिए समर्पित करने से पहले, उन बिंदुओं पर विचार करें जो यह तय करते हैं कि कोई स्क्रिप्ट पूरी हो पाएगी या नहीं:

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

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

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

एजाइल स्वचालन उपकरण

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

लाइसेंस प्राप्त स्वचालन उपकरण संसाधनों को बांधकर रखते हैं जबकि एजाइल कार्यप्रणाली कम प्रतिबंधात्मक रहती है।

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

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

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

स्वचालन परीक्षण Concepts जब इसे एजाइल पर लागू किया जाता है

नीचे दी गई तालिका परीक्षण को स्वचालित करने के लिए उपयुक्त सात क्लासिक स्थितियों को लेती है और प्रत्येक के लिए एजाइल समाधान देती है। इनमें से केवल तीन ही एजाइल स्प्रिंट में स्पष्ट रूप से परिवर्तित होती हैं, और तीनों ही प्रतिगमन-आधारित हैं:

# स्वचालन परीक्षण अवधारणा एजाइल कार्यप्रणाली का उत्तर
1 इस परीक्षण को बार-बार दोहराना होगा। यहीं पर रिग्रेशन टेस्टिंग की अवधारणा सामने आती है।
2 परीक्षण की कार्यप्रणाली और उसका सत्यापन समय के साथ धीरे-धीरे विकसित और परिवर्तित होते रहते हैं। एजाइल टेस्टिंग के लिए यह उपयोगी नहीं है, क्योंकि एजाइल टेस्टिंग का मतलब आवश्यकताओं में बार-बार बदलाव करना होता है।
3 यह परीक्षण किसी व्यावसायिक प्रक्रिया या कार्यप्रवाह को मान्य करता है, न कि उसके स्वरूप, रंग या टेबल लेआउट को। इस परिदृश्य को मैन्युअल परीक्षण से संबंधित माना जा सकता है।
4 यह परीक्षण एक नियामक निकाय के लिए परिणाम उत्पन्न करता है, जो यह मांग करता है कि उन परिणामों को अनुपालन के औपचारिक प्रमाण के रूप में इलेक्ट्रॉनिक रूप से रिकॉर्ड और संग्रहीत किया जाए। यह एजाइल कार्यप्रणाली के लिए उपयुक्त नहीं है, क्योंकि व्यापक स्तर का दस्तावेज़ीकरण एजाइल कार्यप्रणाली का हिस्सा नहीं है।
5 यह परीक्षण बहुत दोहराव वाला है या इसमें कई ऐसे चरण हैं जिन्हें हर बार बिल्कुल उसी तरह से करना होता है, जिससे मैनुअल परीक्षक की थकान से बचना आवश्यक है। एजाइल कार्यप्रणाली के लिए उपयुक्त नहीं है।
6 चयनित स्वचालन उपकरण की सहायता से परीक्षा के उत्तीर्ण या असफल होने का परिणाम आसानी से निर्धारित और दर्ज किया जा सकता है। यह एजाइल टेस्टिंग के दौरान उन रिग्रेशन टेस्ट के लिए उपयुक्त है जिनमें दोहराव और श्रमसाध्य क्षमताओं की आवश्यकता होती है।
7 इस परीक्षण के लिए एप्लिकेशन में काफी मात्रा में डेटा डालने की आवश्यकता है। इसे रिग्रेशन टेस्टिंग के रूप में शामिल किया जा सकता है।

ऑटोमेशन टेस्टिंग की सात अवधारणाओं को उनसे संबंधित एजाइल कार्यप्रणाली के उत्तरों के साथ प्रस्तुत किया गया है।

अक्सर पूछे जाने वाले प्रश्न

एक लेयरिंग नियम: सबसे नीचे कई तेज़ यूनिट टेस्ट, बीच में कम संख्या में इंटीग्रेशन और API टेस्ट, और सबसे ऊपर एंड-टू-एंड UI टेस्ट की एक पतली परत। इससे स्प्रिंट के आकार के टेस्ट सूट को तेज़ और रखरखाव में सस्ता रखा जा सकता है।

किसी स्टोरी के लिए स्वचालित जाँच उसी स्प्रिंट में लिखी जाती है जिसमें वह स्टोरी लिखी जाती है। टीमें आमतौर पर पहले स्प्रिंट में यूनिट टेस्ट से शुरुआत करती हैं, क्योंकि उत्पाद के पर्याप्त रूप से स्थिर होने तक प्रतीक्षा करने से मैन्युअल परीक्षण का ढेर लग जाता है।

पिरामिड के अनुरूप चरणों को क्रमबद्ध करें। यूनिट परीक्षण सबसे पहले चलाए जाते हैं क्योंकि वे सबसे तेज़ होते हैं, फिर एकीकरण और एपीआई परीक्षण, और फिर छोटे एंड-टू-एंड परीक्षण। विफलताएँ सबसे पहले सबसे निचले स्तर पर सामने आती हैं। Guru99 में यांत्रिकी को शामिल किया गया है निरंतर एकीकरण.

इसका सबसे आम कारण पिरामिड का उल्टा होना है — धीमे और कमज़ोर UI परीक्षणों में भारी निवेश और यूनिट स्तर पर लगभग कोई निवेश नहीं। अन्य कारणों में स्टोरी एस्टिमेट से ऑटोमेशन को बाहर रखना और ऐसे सूट पर भरोसा न करना शामिल है, जिन पर रिलीज़ को रोकने का कोई कारण नहीं है।

पूरी डिलीवरी टीम। डेवलपर्स यूनिट टेस्ट की ज़िम्मेदारी लेते हैं, टेस्टर्स एपीआई और एंड-टू-एंड लेयर्स की ज़िम्मेदारी लेते हैं, और दोनों एक-दूसरे के काम की समीक्षा करते हैं। एक अलग डाउनस्ट्रीम ऑटोमेशन टीम उस हैंड-ऑफ विलंब को फिर से लागू करती है जिसे स्क्रम का उद्देश्य दूर करना है।

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

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

यह उन्हें जल्दी से तैयार कर देता है। गिटहब कोपिलॉट यह मौजूदा कोड से पेज ऑब्जेक्ट, फिक्स्चर और असर्शन को स्केफोल्ड करता है, जिससे बहुत सारी जटिलताएँ दूर हो जाती हैं।ping. Revप्रत्येक ड्राफ्ट की समीक्षा करें, क्योंकि उत्पन्न परीक्षण अपेक्षित व्यवहार के बजाय वर्तमान व्यवहार की पुष्टि कर सकता है।

इस पोस्ट को संक्षेप में इस प्रकार लिखें: