24

मैं कई टीमों पर रहा हूं जो चुस्त कार्यप्रणाली का अभ्यास करने की कोशिश करते हैं और अक्सर ये टीम टेस्ट सेंट्रिक होती हैं। चंचल कार्यप्रणाली का अभ्यास करने के लिए एक आवश्यक भाग का परीक्षण कर रहा है या क्या यह सिर्फ एक एक्सपी अभ्यास है जो पिछले कुछ वर्षों में किया गया है?

agile testing extreme-programming

— stevebot
स्रोत

76

परीक्षण किसी भी गुणवत्ता सॉफ्टवेयर विकास का एक आवश्यक हिस्सा है।

— तेलस्टिन

2

TDD (परीक्षण संचालित विकास) किए बिना क्या आप संभव हो सकते हैं? - अगर आप असहमत हैं तो मुझे बताइए ...

— मर्फ़

11

मैं डुप्लिकेट से असहमत हूं। परीक्षण TDD से अधिक व्यापक है और व्यापक प्रश्न के अलग-अलग उत्तर हैं।

— बार्ट वैन इनगेन शेनौ सेप

मैं @BartvanIngenSchenau से सहमत हूं। न केवल टीडीडी करने से कहीं अधिक व्यापक गतिविधि का परीक्षण किया जा रहा है, लेकिन टीडीडी और यूनिट परीक्षण समान नहीं हैं। मुझे आश्चर्य है कि बहुत से लोग अंतिम दो को भ्रमित करते हैं।

— एंड्रेस एफ।

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

— रवांग

33

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

इसका कारण अधिक पारंपरिक, टॉप-डाउन डिज़ाइन प्रकार की प्रोग्रामिंग से अलग है, उस वातावरण में इसका a) परीक्षण करना बहुत कठिन है जब तक कि आपके पास तैयार उत्पाद b नहीं है) सिद्धांत रूप में आप एक ही समय में सभी डिज़ाइन मानदंडों पर विचार कर रहे हैं, और इसलिए आपको डिज़ाइन निर्णय लेने की संभावना कम है जो पिछले डिज़ाइन निर्णयों को तोड़ता है।

— मीका
स्रोत

2

यह भी महत्वपूर्ण है कि भविष्य के वृद्धिशील परिवर्तन पिछली कार्यक्षमता को नहीं तोड़ते हैं, और यूनिट परीक्षण उसके लिए जाँच करने का एक आसान तरीका है।

1

मैं कहता हूं कि सॉफ्टवेयर विकास के लिए परीक्षण अत्यंत आवश्यक है ।

— एंड्रेस एफ।

@Snowman टेस्टिंग! = यूनिट टेस्टिंग। इसके अलावा, इकाई परीक्षण! = टीडीडी (बस मामले में ...)।

— एंड्रेस एफ।

@AndresF। सच है, मैं आमतौर पर यूनिट परीक्षण के बारे में सोचता हूं कि मैं ऊपर उल्लिखित कारणों के लिए एजाइल का एक अभिन्न अंग हूं। पढ़ने में विफलता।

8

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

— कार्तिक टी
स्रोत

8

यदि आपके पास परीक्षण नहीं हैं, तो आप अपने कोड कार्यों को कैसे जानते हैं?

संपादित करें: परीक्षण का दावा करने वाला यह साबित नहीं कर सकता कि कोड कार्य एक महत्वपूर्ण शब्द को परिभाषित करने में विफल रहता है, अर्थात काम करता है । एक कार्यक्रम के काम करने का क्या मतलब है? यदि आप इस शब्द को अस्पष्ट रखते हैं, तो यह साबित करने या सुनिश्चित करने का कोई तरीका नहीं है कि कोई भी कार्यक्रम काम करता है। कभी।

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

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

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

— दीमा
स्रोत

13

जब ग्राहक बग रिपोर्ट दर्ज करना बंद कर देते हैं? :-)

— gbjbaanb

3

आप इसे सही साबित कर सकते हैं। स्वच्छ कक्ष सॉफ्टवेयर इंजीनियरिंग वास्तव में TDD के समान है, लेकिन इसने केवल सांख्यिकीय परीक्षण उत्पन्न किए हैं जो ऐनक और प्रमाण से उत्पन्न होते हैं।

— जार्ज डब्ल्यू मित्तग

1

-1 - "परीक्षण उपस्थिति को दर्शाता है, बग की अनुपस्थिति को नहीं।"

— तेलस्टिन

@ टेलस्टाइन, परीक्षण नहीं होना निश्चितता के साथ बग की उपस्थिति को दर्शाता है। दूसरी ओर, परीक्षणों का एक लिखित सेट आपके कोड क्या करता है के एक निष्पादन योग्य विनिर्देश प्रदान करता है।

— दिमा

मैं असहमत नहीं हूं, लेकिन परीक्षण की कोई भी मात्रा साबित नहीं करती है कि आपका कोड काम करता है।

— तेलस्टाइन

5

नहीं यह जरूरी नहीं है"

चंचल के सिद्धांतों कुछ भी नहीं कहने सीधे परीक्षण के बारे में।

लेकिन यह बहुत ही उचित है

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

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

— स्टीवन ए लोव
स्रोत

4

एजाइल और एक्सपी दोनों बिग डिज़ाइन अप फ्रंट से बचने की कोशिश करते हैं । BDUF में, आवश्यकताओं को इकट्ठा किया जाता है, एक औपचारिक विनिर्देश बनाया जाता है, फिर कोडिंग की जाती है, फिर परीक्षण किया जाता है। यह अच्छी तरह से परिभाषित, मिशन- और जीवन-महत्वपूर्ण प्रणालियों जैसे चिकित्सा उपकरण, अंतरिक्ष जांच, आदि के लिए समझ में आता है।

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

स्वचालित इकाई परीक्षण लिखने के लिए जल्दी, चलाने के लिए त्वरित और बहुत मॉड्यूलर / decoupled हैं। यह औपचारिक रूप से आवश्यकताओं को औपचारिक रूप से निर्दिष्ट करने और जांचने का एक तेज़ तरीका है।

— Warbo
स्रोत

क्या चुस्त कार्यप्रणाली का एक आवश्यक हिस्सा परीक्षण है?

नहीं यह जरूरी नहीं है"

लेकिन यह बहुत ही उचित है