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

परीक्षण में एजाइल पद्धति क्या है?
एजाइल कार्यप्रणाली एक ऐसी प्रथा है जो बढ़ावा देती है निरंतर पुनरावृत्ति परियोजना के सॉफ्टवेयर विकास जीवनचक्र के दौरान विकास और परीक्षण की प्रक्रिया। सॉफ्टवेयर परीक्षण में एजाइल मॉडल में, वाटरफॉल मॉडल के विपरीत, विकास और परीक्षण दोनों गतिविधियाँ समवर्ती होती हैं।

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

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

वहाँ विभिन्न रहे हैं चुस्त तरीके एजाइल परीक्षण में मौजूद हैं, और वे नीचे सूचीबद्ध हैं:
जमघट
SCRUM एक एजाइल विकास पद्धति है जो विशेष रूप से टीम-आधारित विकास परिवेश में कार्यों के प्रबंधन पर केंद्रित है। मूलतः, स्क्रम एक रग्बी मैच के दौरान उत्पन्न होने वाली अवधारणा से लिया गया है। स्क्रम विकास टीम को सशक्त बनाने में विश्वास करता है और छोटी टीमों (जैसे, 7 से 9 सदस्यों वाली) में काम करने की वकालत करता है। एजाइल और स्क्रम में तीन भूमिकाएँ होती हैं, और उनकी ज़िम्मेदारियाँ इस प्रकार बताई गई हैं:

मेला मालिक
RSI मेला मालिक टीम की स्थापना, स्प्रिंट मीटिंग और प्रगति में आने वाली बाधाओं को दूर करने के लिए जिम्मेदार है।
उत्पाद मालिक
उत्पाद स्वामी उत्पाद बैकलॉग बनाता है, बैकलॉग को प्राथमिकता देता है, तथा प्रत्येक पुनरावृत्ति पर कार्यक्षमता के वितरण के लिए जिम्मेदार होता है।
स्क्रम टीम
टीम अपने काम का प्रबंधन स्वयं करती है और स्प्रिंट या चक्र को पूरा करने के लिए काम को व्यवस्थित करती है।
उत्पाद बकाया
यह एक रिपॉजिटरी है जहाँ प्रत्येक रिलीज़ के लिए पूरी की जाने वाली आवश्यकताओं (यूज़र स्टोरीज़) की संख्या के विवरण के साथ आवश्यकताओं को ट्रैक किया जाता है। इसे उत्पाद स्वामी द्वारा बनाए रखा जाना चाहिए और प्राथमिकता दी जानी चाहिए, और इसे स्क्रम टीम को वितरित किया जाना चाहिए। टीम किसी नई आवश्यकता को जोड़ने, संशोधित करने या हटाने का अनुरोध भी कर सकती है।
स्क्रम अभ्यास
इस अनुभाग में प्रथाओं का विस्तार से वर्णन किया गया है:

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

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