सॉफ्टवेयर परीक्षण में एजाइल पद्धति
परीक्षण में एजाइल पद्धति क्या है?
एजाइल कार्यप्रणाली का अर्थ है एक अभ्यास जो बढ़ावा देता है निरंतर पुनरावृत्ति परियोजना के सॉफ्टवेयर विकास जीवनचक्र के दौरान विकास और परीक्षण की प्रक्रिया। सॉफ्टवेयर परीक्षण में एजाइल मॉडल में, वाटरफॉल मॉडल के विपरीत, विकास और परीक्षण दोनों गतिविधियाँ समवर्ती होती हैं।
एजाइल सॉफ्टवेयर डेवलपमेंट क्या है?
RSI Agile सॉफ्टवेयर विकास कार्यप्रणाली किसी व्यावसायिक आवश्यकता के लिए एक दृष्टिकोण को सॉफ़्टवेयर समाधानों में बदलने की सबसे सरल और प्रभावी प्रक्रियाओं में से एक है। एजाइल एक ऐसा शब्द है जिसका उपयोग सॉफ़्टवेयर विकास दृष्टिकोणों का वर्णन करने के लिए किया जाता है जो निरंतर नियोजन, सीखने, सुधार, टीम सहयोग, विकासवादी विकास और शीघ्र वितरण को नियोजित करते हैं। यह परिवर्तन के लिए लचीली प्रतिक्रियाओं को प्रोत्साहित करता है।
एजाइल सॉफ्टवेयर विकास चार मुख्य मूल्यों पर जोर देता है।
- प्रक्रियाओं और उपकरणों पर व्यक्तिगत और टीम की बातचीत
- व्यापक प्रलेखन पर काम कर रहे सॉफ्टवेयर
- अनुबंध बातचीत के बारे में ग्राहक सहयोग
- किसी योजना का पालन करने पर परिवर्तन पर प्रतिक्रिया करना
एजाइल मॉडल बनाम वाटरफॉल मॉडल
एजाइल और वाटरफॉल मॉडल सॉफ्टवेयर विकास प्रक्रिया के लिए दो अलग-अलग तरीके हैं। हालाँकि वे अपने दृष्टिकोण में भिन्न हैं, लेकिन आवश्यकता और परियोजना के प्रकार के आधार पर दोनों विधियाँ कई बार उपयोगी होती हैं।
चुस्त मॉडल | झरना मॉडल |
---|---|
सॉफ्टवेयर परीक्षण में एजाइल कार्यप्रणाली की परिभाषा: एजाइल कार्यप्रणाली सॉफ्टवेयर डिजाइन के लिए वृद्धिशील और पुनरावृत्तीय दृष्टिकोण का प्रस्ताव करती है | वाटरफॉल मॉडल: सॉफ्टवेयर का विकास प्रारंभिक बिंदु से अंतिम बिंदु तक क्रमिक रूप से प्रवाहित होता है। |
RSI चुस्त प्रक्रिया सॉफ्टवेयर परीक्षण को अलग-अलग मॉडलों में तोड़ा जाता है जिन पर डिजाइनर काम करते हैं | डिज़ाइन प्रक्रिया को अलग-अलग मॉडलों में नहीं तोड़ा गया है |
ग्राहक को उत्पाद को देखने और परियोजना में निर्णय और परिवर्तन करने के लिए शुरुआती और लगातार अवसर मिलते हैं | ग्राहक उत्पाद को केवल परियोजना के अंत में ही देख सकता है |
परीक्षण में एजाइल मॉडल को वॉटरफॉल मॉडल की तुलना में असंरचित माना जाता है | वाटरफॉल मॉडल अधिक सुरक्षित हैं क्योंकि वे योजना उन्मुख हैं |
छोटी परियोजनाओं को बहुत तेजी से क्रियान्वित किया जा सकता है। बड़ी परियोजनाओं के लिए, विकास के समय का अनुमान लगाना कठिन है। | सभी प्रकार की परियोजनाओं का अनुमान लगाया जा सकता है और उन्हें पूरा किया जा सकता है। |
परियोजना के मध्य में त्रुटि को ठीक किया जा सकता है। | केवल अंत में, पूरे उत्पाद का परीक्षण किया जाता है। यदि आवश्यकता त्रुटि पाई जाती है या कोई परिवर्तन करना होता है, तो परियोजना को शुरू से शुरू करना पड़ता है |
विकास प्रक्रिया पुनरावृत्तीय है, और परियोजना को छोटे (2-4) सप्ताह के पुनरावृत्तियों में निष्पादित किया जाता है। योजना बहुत कम है। | विकास प्रक्रिया चरणबद्ध है, और चरण पुनरावृत्ति से कहीं अधिक बड़ा है। प्रत्येक चरण अगले चरण के विस्तृत विवरण के साथ समाप्त होता है। |
दस्तावेज़ीकरण को कम प्राथमिकता दी जाती है सॉफ्टवेयर विकास | दस्तावेज़ीकरण सर्वोच्च प्राथमिकता है और इसका उपयोग कर्मचारियों को प्रशिक्षण देने और किसी अन्य टीम के साथ सॉफ्टवेयर को अपग्रेड करने के लिए भी किया जा सकता है |
हर पुनरावृत्ति का अपना परीक्षण चरण होता है। यह हर बार नए फ़ंक्शन या तर्क जारी होने पर प्रतिगमन परीक्षण को लागू करने की अनुमति देता है। | विकास चरण के बाद ही परीक्षण चरण क्रियान्वित किया जाता है, क्योंकि अलग-अलग भाग पूरी तरह कार्यात्मक नहीं होते हैं। |
एजाइल टेस्टिंग में जब पुनरावृत्ति समाप्त होती है, तो उत्पाद की शिप करने योग्य विशेषताएं ग्राहक को वितरित की जाती हैं। शिपमेंट के तुरंत बाद नई सुविधाएँ उपयोग करने योग्य होती हैं। यह तब उपयोगी होता है जब आपका ग्राहकों के साथ अच्छा संपर्क हो। | विकसित की गई सभी सुविधाएं लंबे कार्यान्वयन चरण के बाद एक बार में वितरित की जाती हैं। |
परीक्षक और डेवलपर्स एक साथ काम करते हैं | परीक्षक डेवलपर्स से अलग काम करते हैं |
प्रत्येक स्प्रिंट के अंत में, उपयोगकर्ता स्वीकृति की जाती है | उपयोगकर्ता स्वीकृति है प्रदर्शन परियोजना के अंत में. |
इसके लिए डेवलपर्स के साथ निकट संचार और आवश्यकताओं और योजना का एक साथ विश्लेषण करना आवश्यक है | डेवलपर आवश्यकता और नियोजन प्रक्रिया में शामिल नहीं होता है। आमतौर पर, परीक्षण और कोडिंग के बीच समय की देरी होती है |
यह भी जांचें: - एजाइल बनाम वाटरफॉल: कार्यप्रणाली के बीच अंतर जानें
चुस्त प्रक्रिया
नीचे जाँच करें चंचल कार्यप्रणाली सफल प्रणालियों को शीघ्रता से वितरित करने की प्रक्रिया।
वहाँ विभिन्न रहे हैं चुस्त तरीके एजाइल परीक्षण में मौजूद हैं, और वे नीचे सूचीबद्ध हैं:
जमघट
SCRUM एक चुस्त विकास पद्धति है जो विशेष रूप से टीम-आधारित विकास वातावरण के भीतर कार्यों को प्रबंधित करने के तरीके पर ध्यान केंद्रित करती है। मूल रूप से, स्क्रम रग्बी मैच के दौरान होने वाली गतिविधि से लिया गया है। स्क्रम विकास टीम को सशक्त बनाने में विश्वास करता है और छोटी टीमों (जैसे- 7 से 9 सदस्य) में काम करने की वकालत करता है। एजाइल और स्क्रम में तीन भूमिकाएँ शामिल हैं, और उनकी ज़िम्मेदारियों को इस प्रकार समझाया गया है:
-
मेला मालिक
- मेला मालिक टीम की स्थापना, स्प्रिंट मीटिंग और प्रगति में आने वाली बाधाओं को दूर करने के लिए जिम्मेदार है
-
उत्पाद मालिक
-
उत्पाद स्वामी उत्पाद बैकलॉग बनाता है, बैकलॉग को प्राथमिकता देता है और प्रत्येक पुनरावृत्ति पर कार्यक्षमता के वितरण के लिए जिम्मेदार होता है
-
-
स्क्रम टीम
-
टीम अपने काम का प्रबंधन स्वयं करती है और स्प्रिंट या चक्र को पूरा करने के लिए काम को व्यवस्थित करती है
-
उत्पाद बकाया
यह एक रिपोजिटरी है जहाँ प्रत्येक रिलीज़ के लिए पूरी की जाने वाली आवश्यकताओं (उपयोगकर्ता कहानियों) की संख्या के विवरण के साथ आवश्यकताओं को ट्रैक किया जाता है। इसे उत्पाद स्वामी द्वारा बनाए रखा जाना चाहिए और प्राथमिकता दी जानी चाहिए, और इसे स्क्रम टीम को वितरित किया जाना चाहिए। टीम एक नई आवश्यकता जोड़ने या संशोधन या हटाने का अनुरोध भी कर सकती है
स्क्रम अभ्यास
प्रथाओं का विस्तृत वर्णन इस प्रकार है:
स्क्रम पद्धतियों का प्रक्रिया प्रवाह:
प्रक्रिया प्रवाह स्क्रम परीक्षण इस प्रकार है:
- स्क्रम के प्रत्येक पुनरावृत्ति को किस नाम से जाना जाता है? Sprint
- उत्पाद बैकलॉग एक सूची है जिसमें अंतिम उत्पाद प्राप्त करने के लिए सभी विवरण दर्ज किए जाते हैं
- प्रत्येक के दौरान Sprint, उत्पाद बैकलॉग की शीर्ष उपयोगकर्ता कहानियों का चयन किया जाता है और उन्हें बदल दिया जाता है Sprint बैकलॉग
- टीम निर्धारित स्प्रिंट बैकलॉग पर काम करती है
- टीम दैनिक कार्य की जांच करती है
- स्प्रिंट के अंत में, टीम उत्पाद कार्यक्षमता प्रदान करती है
एक्सट्रीम प्रोग्रामिंग (एक्सपी)
एक्सट्रीम प्रोग्रामिंग तकनीक तब बहुत मददगार होती है जब ग्राहकों की मांग या ज़रूरतें लगातार बदलती रहती हैं या जब वे सिस्टम की कार्यक्षमता के बारे में सुनिश्चित नहीं होते हैं। यह छोटे विकास चक्रों में उत्पाद के लगातार “रिलीज़” की वकालत करता है, जो स्वाभाविक रूप से सिस्टम की उत्पादकता में सुधार करता है और एक चेकपॉइंट भी पेश करता है जहाँ किसी भी ग्राहक की ज़रूरतों को आसानी से लागू किया जा सकता है। XP ग्राहक को लक्ष्य में रखते हुए सॉफ़्टवेयर विकसित करता है।
व्यावसायिक आवश्यकताओं को कहानियों के रूप में एकत्र किया जाता है। उन सभी कहानियों को पार्किंग स्थल नामक स्थान पर संग्रहीत किया जाता है।
इस प्रकार की कार्यप्रणाली में, रिलीज़ 14 दिनों की समय अवधि के साथ पुनरावृत्तियों नामक छोटे चक्रों पर आधारित होते हैं। प्रत्येक पुनरावृत्ति में कोडिंग, यूनिट परीक्षण और सिस्टम परीक्षण जैसे चरण शामिल होते हैं जहाँ प्रत्येक चरण में एप्लिकेशन में कुछ छोटी या बड़ी कार्यक्षमता बनाई जाएगी।
एक्सट्रीम प्रोग्रामिंग के चरण:
एजाइल एक्सपी पद्धति में 6 चरण उपलब्ध हैं, और उन्हें निम्नानुसार समझाया गया है:
प्लानिंग
-
हितधारकों और प्रायोजकों की पहचान
-
बुनियादी ढाँचे की आवश्यकताएँ
-
सुरक्षा संबंधित जानकारी एकत्र करना और एकत्र करना
-
सेवा स्तर समझौते और उसकी शर्तें
विश्लेषण
-
पार्किंग स्थल में कहानियों का कैप्चरिंग
-
पार्किंग स्थल में कहानियों को प्राथमिकता दें
-
आकलन के लिए कहानियों की स्क्रबिंग
-
पुनरावृति SPAN(समय) परिभाषित करें
-
विकास और QA दोनों टीमों के लिए संसाधन नियोजन
डिज़ाइन
-
कार्यों का विभाजन
-
प्रत्येक कार्य के लिए परीक्षण परिदृश्य की तैयारी
-
रिग्रेशन ऑटोमेशन फ्रेमवर्क
निष्पादन
-
कोडन
-
मैनुअल परीक्षण परिदृश्यों का निष्पादन
-
दोष रिपोर्ट तैयार करना
-
मैनुअल से ऑटोमेशन रिग्रेशन परीक्षण मामलों का रूपांतरण
-
मध्य पुनरावृति समीक्षा
-
पुनरावृति की समीक्षा का अंत
रैपिंग
-
छोटी रिलीज़
-
डेमो और समीक्षा
-
आवश्यकता के आधार पर नई कहानियाँ विकसित करें
-
पुनरावृत्ति समीक्षा टिप्पणियों के अंत के आधार पर प्रक्रिया में सुधार
समापन
-
पायलट लॉन्च
-
प्रशिक्षण
-
उत्पादन लॉन्च
-
एसएलए गारंटी आश्वासन
-
Review SOA रणनीति
-
उत्पादन का समर्थन
दैनिक आधार पर कार्य पर नज़र रखने के लिए दो स्टोरीबोर्ड उपलब्ध हैं, जिन्हें संदर्भ के लिए नीचे सूचीबद्ध किया गया है।
-
कहानी कार्डबोर्ड
-
यह दैनिक XP गतिविधियों को ट्रैक करने के लिए स्टिक नोट्स के रूप में सभी कहानियों को एक बोर्ड में एकत्र करने का एक पारंपरिक तरीका है। चूंकि इस मैनुअल गतिविधि में अधिक प्रयास और समय लगता है, इसलिए ऑनलाइन फॉर्म पर स्विच करना बेहतर है।
-
-
ऑनलाइन स्टोरीबोर्ड
-
कहानियों को संग्रहीत करने के लिए ऑनलाइन टूल स्टोरीबोर्ड का उपयोग किया जा सकता है। कई टीमें इसका उपयोग कर सकती हैं विभिन्न उद्देश्यों के लिए।
-
क्रिस्टल के तरीके
क्रिस्टल पद्धति तीन अवधारणाओं पर आधारित है
-
चार्टरिंग: इस चरण में शामिल विभिन्न गतिविधियों में विकास दल का गठन, प्रारंभिक व्यवहार्यता विश्लेषण, प्रारंभिक योजना का विकास और विकास पद्धति को परिष्कृत करना शामिल है।
-
चक्रीय वितरण: मुख्य विकास चरण में दो या अधिक वितरण चक्र शामिल होते हैं, जिसके दौरान
- टीम रिलीज़ योजना को अद्यतन और परिष्कृत करती है
- एक या अधिक प्रोग्राम परीक्षण एकीकृत पुनरावृत्तियों के माध्यम से आवश्यकताओं के एक उपसमूह को कार्यान्वित करता है
- एकीकृत उत्पाद वास्तविक उपयोगकर्ताओं तक पहुंचाया जाता है
- Revपरियोजना योजना और अपनाई गई विकास पद्धति का दृश्य
- लपेटें: इस चरण में की जाने वाली गतिविधियों में उपयोगकर्ता परिवेश में परिनियोजन, परिनियोजन के बाद समीक्षा और प्रतिबिम्बन शामिल हैं।
डायनेमिक सॉफ्टवेयर डेवलपमेंट मेथड (डीएसडीएम)
डीएसडीएम एक रैपिड अनुप्रयोग का विकास (आरएडी) सॉफ्टवेयर विकास के लिए दृष्टिकोण है और एक चुस्त परियोजना वितरण ढांचा प्रदान करता है। डीएसडीएम का महत्वपूर्ण पहलू यह है कि उपयोगकर्ताओं को सक्रिय रूप से शामिल होने की आवश्यकता होती है, और टीमों को निर्णय लेने की शक्ति दी जाती है। डीएसडीएम के साथ उत्पाद की लगातार डिलीवरी सक्रिय फोकस बन जाती है। डीएसडीएम में इस्तेमाल की जाने वाली तकनीकें हैं
- पहर Boxआईएनजी
- MoSCoW नियम
- प्रोटोटाइप
डीएसडीएम परियोजना में 7 चरण शामिल हैं
- पूर्व परियोजना
- व्यवहार्यता अध्ययन
- व्यापार अध्ययन
- कार्यात्मक मॉडल पुनरावृत्ति
- डिज़ाइन और निर्माण पुनरावृत्ति
- कार्यान्वयन
- परियोजना-पश्चात्
फ़ीचर ड्रिवेन डेवलपमेंट (FDD)
यह विधि “डिजाइनिंग और बिल्डिंग” सुविधाओं पर केंद्रित है। सॉफ्टवेयर इंजीनियरिंग में अन्य एजाइल विधियों के विपरीत, FDD कार्य के बहुत विशिष्ट और छोटे चरणों का वर्णन करता है जिन्हें प्रत्येक सुविधा के अनुसार अलग से पूरा करना होता है। इसमें डोमेन वॉकथ्रू, डिज़ाइन निरीक्षण, निर्माण के लिए बढ़ावा, कोड निरीक्षण और डिज़ाइन शामिल हैं। FDD निम्नलिखित बातों को लक्ष्य में रखते हुए उत्पाद विकसित करता है
- डोमेन ऑब्जेक्ट मॉडलिंग
- विशेषता के अनुसार विकास
- घटक/ वर्ग स्वामित्व
- फ़ीचर टीमें
- निरीक्षण
- विन्यास प्रबंधन
- नियमित निर्माण
- प्रगति और परिणामों की दृश्यता
लीन सॉफ्टवेयर डेवलपमेंट
लीन सॉफ्टवेयर डेवलपमेंट विधि "जस्ट इन टाइम प्रोडक्शन" के सिद्धांत पर आधारित है। इसका उद्देश्य सॉफ्टवेयर विकास की गति बढ़ाना और लागत कम करना है। लीन डेवलपमेंट को सात चरणों में संक्षेपित किया जा सकता है।
- अपशिष्ट को खत्म करना
- सीखने को बढ़ाना
- प्रतिबद्धता को स्थगित करना (जितना संभव हो सके उतना देर से निर्णय लेना)
- शीघ्र डिलीवरी
- टीम को सशक्त बनाना
- इमारत Integrity
- संपूर्ण अनुकूलन करें
Kanban
Kanban मूल रूप से जापानी शब्द से निकला है जिसका अर्थ है, एक कार्ड जिसमें उत्पाद पर प्रत्येक चरण में उसके पूरा होने के मार्ग पर किए जाने वाले सभी आवश्यक जानकारी शामिल है। यह ढांचा या विधि विशेष रूप से एजाइल अवधारणाओं में सॉफ्टवेयर परीक्षण विधि में काफी अपनाई जाती है।
स्क्रम बनाम कानबन
जमघट | Kanban |
---|---|
स्क्रम तकनीक में, परीक्षणों को इस प्रकार तोड़ा जाना चाहिए कि उन्हें एक स्प्रिंट में पूरा किया जा सके | कोई विशेष आइटम आकार निर्धारित नहीं है |
प्राथमिकता वाले उत्पाद बैकलॉग को निर्धारित करता है | प्राथमिकता निर्धारण वैकल्पिक है |
स्क्रम टीम पुनरावृत्ति के लिए एक विशेष मात्रा में कार्य करने के लिए प्रतिबद्ध होती है | प्रतिबद्धता वैकल्पिक है |
बर्नडाउन चार्ट निर्धारित है | कोई विशेष आइटम आकार निर्धारित नहीं है |
प्रत्येक स्प्रिंट के बीच, स्क्रम बोर्ड को रीसेट किया जाता है | कानबन बोर्ड स्थायी होता है। यह वर्कफ़्लो स्थिति में आइटम की संख्या को सीमित करता है |
यह चल रहे पुनरावर्तन में आइटम नहीं जोड़ सकता | जब भी क्षमता उपलब्ध हो, यह आइटम जोड़ सकता है |
WIP अप्रत्यक्ष रूप से सीमित | WIP सीधे सीमित |
समयबद्ध पुनरावृत्तियाँ निर्धारित | टाइमबॉक्स्ड पुनरावृत्तियाँ वैकल्पिक |
यह भी जांचें: - कानबैन बनाम स्क्रम: क्या अंतर है?
चुस्त मेट्रिक्स
एजाइल के प्रभावी उपयोग के लिए एकत्रित किए जा सकने वाले मेट्रिक्स हैं:
-
ड्रैग फैक्टर
-
घंटों का प्रयास जो स्प्रिंट लक्ष्य में योगदान नहीं देता
-
साझा संसाधनों की संख्या को कम करके, गैर-योगदानकारी कार्य की मात्रा को कम करके ड्रैग फैक्टर में सुधार किया जा सकता है
-
नये अनुमान को ड्रैग फैक्टर के प्रतिशत से बढ़ाया जा सकता है -नया अनुमान = (पुराना अनुमान+ड्रैग फैक्टर)
-
-
वेग
-
स्प्रिंट की शिप करने योग्य कार्यक्षमता में परिवर्तित बैकलॉग (उपयोगकर्ता कहानियां) की मात्रा
-
-
जोड़े गए यूनिट परीक्षणों की संख्या
-
दैनिक निर्माण पूरा करने में लिया गया समय अंतराल
-
किसी पुनरावृति में या पिछले पुनरावृति में पाई गई बग
-
उत्पादन दोष रिसाव