एक ही स्प्रिंट में कोडिंग और परीक्षण


22

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

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

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

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

मुझे यकीन है कि मैं इस दुविधा के लिए पहला व्यक्ति नहीं हूं।

अतीत में, मैंने एक पाइपलाइन किया है: वर्तमान स्प्रिंट में परीक्षण टीम उन विशेषताओं का परीक्षण करती है जिन्हें पिछले स्प्रिंट के दौरान लागू किया गया है। मेरी वर्तमान नौकरी में, पीएम इस दृष्टिकोण को "झरना" के रूप में संदर्भित करते हैं, और जैसे कि अस्वीकार्य है।


2
आप इस दुविधा के लिए पहले व्यक्ति नहीं हैं। आप एक पाइपलाइन का उपयोग कर सकते हैं: वर्तमान स्प्रिंट में परीक्षण टीम उन विशेषताओं का परीक्षण करती है जिन्हें पिछले स्प्रिंट के दौरान लागू किया गया है।
जियोर्जियो

2
पीएम ने टीम को अपने तरीके से ऐसा करने के लिए मजबूर किया, जो अर्ध-सशस्त्र फुर्तीली की
gnat


8
@ मर्क रिचमैन: झरना? आपके पास जलप्रपात में 1-2 सप्ताह के विकास चक्र नहीं हैं। मुझे लगता है कि वह नहीं जानता कि वह किस बारे में बात कर रहा है।
जियोर्जियो

2
@gnat: यदि टीम विशेष रूप से उच्च-कार्यशील नहीं है (और ऐसा लगता है कि यह टीम उस विवरण को फिट करती है), तो आप इसे देख सकते हैं कि पीएम एक अधिक प्रभावी विकास रणनीति विकसित करने के लिए टीम का मार्गदर्शन कर रहे हैं। शायद पीएम को लगता है कि लगातार अनटेड कोड देना बिजनेस के लिए अच्छा नहीं है। चंचलता का मतलब यह नहीं है कि "टीमों को जो कुछ भी करना है वह करने दें", कुछ सीमाएं होनी चाहिए जब तक कि एक टीम खुद के लिए तय करने के लिए पर्याप्त परिपक्व न हो।
ब्रायन ओकले

जवाबों:


13

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

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

बहुत सी चीजें हैं जो आप कर सकते हैं:

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

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

  • परीक्षक और डेवलपर्स के बीच सहयोग सफलता का एक और महत्वपूर्ण हिस्सा है। मेरे पिछले प्रोजेक्ट में जब एक डेवलपर द्वारा अमेरिका को समाप्त किया गया तो एक क्यूए व्यक्ति डेवलपर के साथ "पेयर टेस्टिंग" करता है (मैनुअल हो सकता है, कुछ स्वचालित, या बेहतर दोनों के माध्यम से लॉन्च किया जा सकता है), यह बहुत अच्छी तरह से काम करता है।


8

आवश्यक समस्या यह है कि आपके पास प्रोग्रामर हैं जो कोड करते हैं लेकिन परीक्षण नहीं करते हैं और परीक्षक जो कोड नहीं बल्कि परीक्षण करते हैं।

उस समस्या को हल करें और आपको यह समस्या नहीं होगी, और यकीनन अधिक कुशल टीम।

अतीत में मेरे लिए काम करने का एक तरीका कोडर्स और परीक्षकों को पूरी तरह से परीक्षित कहानी देने के स्पष्ट कार्य के साथ कहानियों पर जोड़ी बनाने का सुझाव देना था। इसके साथ ही मैंने "देव पूर्ण" सोच के सभी रूपों को मिटा दिया है: कोडर द्वारा स्क्रैम / कानबन / ट्रेलो बोर्ड पर कोई "देव पूर्ण" कॉलम नहीं, कोई "देव किया" रवैया नहीं।

क्या हुआ था:

  • कहानियों को वितरित करने के लिए जोड़े जिम्मेदार थे और यदि कोई कहानी पूरी नहीं हुई तो वे दोनों असफल हो जाएंगे। उन्हें सॉफ्टवेयर के वितरण के लिए जिम्मेदार पेशेवरों के रूप में माना जाता था और उन्होंने ज्यादातर मामलों में ऐसा किया।

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

  • कुछ परीक्षण स्वचालित हो गए जब देवताओं ने बेहतर समझा कि परीक्षकों को क्या चाहिए।

  • कुछ लोग परेशान हो गए।

  • कहानियों को औसत रूप से त्वरित रूप से वितरित किया गया क्योंकि कोड-कमिट-पुल-टेस्ट चक्र लगभग तत्काल बन गया

बेशक, यह केवल मेरा एक महत्वपूर्ण अनुभव है, लेकिन यदि आप कर सकते हैं तो आप खुद को आजमाना चाहते हैं।

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

यह एक संचार समस्या है, फुर्तीली समस्या नहीं। फुर्तीली कार्यप्रणाली को अपनाने से यह स्पष्ट हो जाता है। साइलोइड टीमें एक ज्ञात प्रबंधन विरोधी पैटर्न हैं , इसलिए इस मामले में फुर्तीली की गैर-अनुकूलन क्षमता को गले लगाओ!


2
इस संगठन ने "डेवलपर्स" और "परीक्षकों" के लिए स्पष्ट सीमाएं और भूमिकाएं बनाई हैं, और एन ट्वेन को पूरा करेगा;)
मार्क

तो, नियम को बदलो!
स्कालिव्ज़

3
@MarkRichman मेरी पिछली नौकरियों में "डेवलपर्स" और "परीक्षकों" की भूमिकाओं में स्पष्ट सीमाएं भी थीं, लेकिन उस संगठन ने n'er नहीं रखा था ताकि वे संवाद करने के लिए ब्लॉक मिलें (क्या एक लंगड़ा विचार btw!); मुझे याद है कि "असाइन किए गए परीक्षक" के साथ जोड़ी में स्प्रिंट करना और यह बहुत अच्छा हुआ। क्या आपकी कंपनी बस अलग-अलग भूमिकाएँ या अतिरिक्त रूप से इन भूमिकाओं को पूरा करने वाले इंजीनियरों के बीच एक संचार / सहयोग अवरोध स्थापित करती है?
गत

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

@ जियोर्जियो कि एक झरना दृश्य है। फुर्तीले, जो लोग स्वतंत्र रूप से मूल्य वितरित कर सकते हैं, वे बहुत पसंदीदा हैं। कोई कारण नहीं है कि विकास और परीक्षण अलग-अलग पेशे होने चाहिए। यह एक विकल्प है, सम्मानजनक है, लेकिन खराब रूप से फुर्तीले विकास के अनुकूल है।
स्किलिविज़

4

आपके QA की वास्तविक भूमिका स्वीकृति परीक्षण के करीब है। मैं कल्पना करूंगा कि यह एक अलग टीम द्वारा किया जाएगा, जो विकास टीम के एक हिस्से के बजाय उत्पाद स्वामी के रूप में अधिक कार्य करता है।

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

  • स्प्रिंट के दौरान:

    1. टीम नई सुविधा के डिजाइन और वास्तविक कोड आधार पर प्रभाव का मसौदा तैयार करती है।

    2. डेवलपर्स इकाई परीक्षण लिखते हैं जो यह सुनिश्चित करते हैं कि आदेश अपेक्षित रूप से काम कर रहा है, और उसी समय वास्तविक कोड लिखता है।

    3. नई सुविधा को यह सुनिश्चित करने के लिए सावधानीपूर्वक परीक्षण किया जाता है कि यह कुछ भी (प्रतिगमन परीक्षण) नहीं तोड़ती है और यह अपेक्षित (यूनिट परीक्षण) के रूप में काम कर रही है।

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

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

मेरा मानना ​​है कि आपके वास्तविक मुद्दे निम्नलिखित हैं:

  • स्कोप । एक स्प्रिंट आपकी टीम और आपकी टीम की चिंता करता है, न कि आपके वास्तविक क्यूए जो एक उत्पाद के मालिक के रूप में अधिक कार्य करता है।

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


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

@MarkRichman हर घंटे के लिए वे आपको कोडबेस में बकवास टाइप करने के लिए भुगतान करते हैं, वे न केवल आपके द्वारा भुगतान किए जाने वाले घंटे को खो रहे हैं, बल्कि सभी घंटों को कोडबेस से बाहर निकालने के लिए लेता है।
मोद

4

यदि स्प्रिंट के अंत तक सभी या अधिकांश कोडिंग नहीं की जाती है?

इसे जल्द खत्म क्यों नहीं किया जा रहा है? यह मुख्य सीमा आपकी परेशानियों का स्रोत है, और मैंने देखा है कि दो दृष्टिकोण सफल होंगे। एक फुर्तीले दृष्टिकोण (लेकिन अन्य सामान्य प्रथाओं) में अच्छी तरह से फिट नहीं होता है और दूसरा दाग थोड़ा चुस्त होता है (लेकिन अधिक सामान्य है)।

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

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


1
मैं क्यूए उनके परीक्षण में पीछे स्प्रिंट होने के लिए इस्तेमाल कर रहा हूँ। यहाँ के लोग हर दो हफ्ते में पूरे SDLC को पूरा होते देखना चाहते हैं । मैं सिर्फ यह नहीं देखता कि यह कैसे संभव है।
मार्क रिचमैन

5
@ मर्करिचमैन - क्यों नहीं? योजना के लिए 1 दिन, कोडिंग के लिए 5 दिन और यूनिट परीक्षण, प्रलेखन, बग फिक्स और अगले स्प्रिंट के लिए डिज़ाइन के लिए 4 दिन। चुनौती वास्तव में इसे पूरा नहीं कर रही है, लेकिन एक कंपनी के रूप में पर्याप्त रूप से अनुशासित होने के लिए एक छोटी राशि का काम अच्छी तरह से करना है।
तेलस्टिन

1
क्योंकि वे उन 5 दिनों पर ध्यान केंद्रित नहीं करेंगे जो मैं कोडिंग कर रहा हूं, लेकिन अन्य 5 दिन मैं नहीं कर रहा हूं। मैं निश्चित रूप से कोडिंग के साथ अन्य 5 दिनों को भर दूंगा, लेकिन चूंकि वे सभी कोडिंग कार्यों "सूप-टू-नट्स" को पूरा करने की इच्छा रखते हैं (परीक्षण सहित), यह समय के भौतिकी के तीर के अनुरूप नहीं है :)
मार्क रिचमैन

1
@markrichman - अच्छा है, तो अन्य सभी चीजों को इंगित करना आसान होना चाहिए जो कोडिंग नहीं कर रहे हैं जो आपको वास्तव में करने की आवश्यकता है
तेलस्तीन

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

1

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

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

अंगूठे के एक मोटे नियम के रूप में, स्प्रिंट में 5 और 15 उत्पाद बैकलॉग आइटम के बीच लाने की उम्मीद है। इससे आप अंदाजा लगा सकते हैं कि प्रत्येक उत्पाद का बैकलॉग आइटम कितना बड़ा होना चाहिए। यह आपको स्प्रिंट के भीतर काम करने का एक शानदार मौका भी देता है।

अंत में, टीम का कार्य एक उत्पाद बैकलॉग आइटम को 'किया' और फिर अगले एक पर ले जाना है। कभी-कभी, ऐसा करने का अर्थ है कि लोग एक-दूसरे के पैर की उंगलियों पर फैल रहे हैं और इसलिए यह एक समय में एक से अधिक उत्पाद बैकलॉग को स्पिन करने के लिए समझ में आता है। आपकी गाइडलाइन हालांकि आपके कार्य प्रगति (WIP) को कम करने और उत्पाद बैकलॉग आइटम को स्थानांतरित करने के लिए होनी चाहिए।


0

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


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

0

मेरा जवाब, जो शायद पहली बार में काफी अजीब है, यह होगा: आपको परीक्षण करने का समय नहीं मिला क्योंकि आपको लगता है कि कोड के साइड इफेक्ट्स पर परीक्षण करना होगा । और साइड इफेक्ट के साथ मेरा मतलब है कि कंप्यूटर विज्ञान शब्द :

एक फ़ंक्शन (...) को साइड इफ़ेक्ट कहा जाता है यदि, मान वापस करने के अलावा, यह (...) बाहरी दुनिया के साथ (...) एक नमूदार बातचीत भी करता है।

मैंने "बाहरी दुनिया के साथ बातचीत" भाग पर जोर देने के लिए उद्धरण लाया: आप यूआई पर परीक्षण करना चाहते हैं क्योंकि यह स्क्रीन पर मुद्रित होता है ("परीक्षण शुरू करने के लिए] वास्तव में संभव नहीं है क्योंकि आपको आमतौर पर एक कार्यात्मक की आवश्यकता होती है UI को ") से स्वचालित परीक्षण रिकॉर्ड या बनाने के लिए।

अन्य उत्तरों ने आपको इस "स्वीकृति परीक्षण" को स्वचालित करने के लिए कहा है, ताकि यह जल्दी से हो सके। यह सही है, लेकिन आपकी मूल समस्या को पूरी तरह से संबोधित नहीं करता है: क्या होगा यदि उन स्वीकृति परीक्षणों को लिखने के लिए पर्याप्त समय नहीं है?

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

उस "अस्थिरता" का समाधान यह समझना है कि, यदि आपने एक बार साबित कर दिया है कि कथन काम करता है, तो आप इसका उपयोग हर जगह कर सकते हैं और इस पर भरोसा कर सकते हैं कि यह अपना काम कर सके। इसे एक फंक्शन में अलग करें और बाकी सब चीजों को टेस्ट करें ।

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

UI के बारे में "विदेशी क्षेत्र" वास्तव में देखने का एक सही बिंदु है, क्योंकि आपको किसी ऐसे पुस्तकालय के तर्क का परीक्षण करने की आवश्यकता नहीं है जो आपके द्वारा प्रदान नहीं किया गया है, और शायद आश्चर्य की बात है, यह एक यथार्थवादी दृष्टिकोण है: क्या आप वास्तव में हैं कभी भी यह परीक्षण करने की अपेक्षा करें कि कॉलिंग उदा MyWidget.draw()एक एकल पिक्सेल के स्तर पर आपसे क्या उम्मीद करता है?

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.