मेन्यू

टेस्टर्स को TDD, BDD और ATDD तकनीकों में कैसे शामिल किया जाता है

how testers are involved tdd

समस्याओं को खत्म करने के लिए हमारे साधन का प्रयास करें

TDD, BDD और ATDD तकनीकों का अवलोकन:

TDD, BDD और ATDD ऐसे शब्द हैं जिन्होंने एजाइल में परीक्षक की दुनिया में क्रांति ला दी है और गति भी प्राप्त की है। परीक्षकों की मानसिकता में बदलाव नए कौशल सीखने और अधिक महत्वपूर्ण बात, दृष्टिकोण को बदलने और काम करने के तरीके की भी आवश्यकता है।

अलगाव में काम करने के विपरीत, परीक्षकों को प्रोग्रामर के साथ मिलकर काम करने की आवश्यकता होती है जिसका अर्थ है

  • परीक्षण मामलों को साझा करना
  • कहानियों की स्वीकृति मानदंड लिखने में भाग लेना
  • हितधारकों को निरंतर प्रतिक्रिया प्रदान करना
  • समय पर दोषों के समाधान के लिए सहयोग करना।
  • डिलिवरेबल्स की गुणवत्ता में सुधार के लिए सुझाव और इनपुट प्रदान करें
  • स्वचालन

चुस्त में शामिल परीक्षकों

इससे पहले कि मैं इन प्रथाओं में एक परीक्षक की भागीदारी की चर्चा में कूदूं, पहले इन शर्तों के पीछे की अवधारणाओं को समझने की कोशिश करूं:

आप क्या सीखेंगे:

परीक्षण संचालित विकास

सॉफ्टवेयर विकास के पारंपरिक दृष्टिकोण पर विचार करें जहां कोड पहले लिखा गया है और फिर परीक्षण किया गया है। टेस्ट-संचालित विकास या टीडीडी एक दृष्टिकोण है जो पारंपरिक विकास की सटीक समीक्षा है। इस दृष्टिकोण में, परीक्षण पहले किया जाता है, और फिर, कोड लिखा जाता है।

उलझन में है? !!

हम सॉफ्टवेयर के एक टुकड़े का परीक्षण कैसे कर सकते हैं जिसे अभी विकसित किया जाना है?

हाँ!! यह परीक्षण संचालित विकास या TDD है।

TDD छोटे वेतन वृद्धि में काम करता है:

  • परीक्षा पहले लिखी जाती है
  • परीक्षण निष्पादित किया जाता है - जो विफल हो जाएगा (स्पष्ट कारणों के लिए)
  • कोड केवल परीक्षण मामले को पास करने के लिए (या फिर से लिखा गया) लिखा जाता है
  • परीक्षण फिर से निष्पादित किया जाता है
  • यदि परीक्षण पास हो जाता है, तो अगले परीक्षण के लिए आगे बढ़ें ELSE फिर से लिखने / परीक्षण पास बनाने के लिए कोड को संशोधित करें

मुझे एक फ़्लोचार्ट के माध्यम से समझाने की कोशिश करें:

टीडीडी फ्लोचार्ट

अब, हमें इस तथ्य को समझना होगा कि टीडीडी परीक्षण के बारे में बात नहीं करता है जो परीक्षक करते हैं। बल्कि यह दृष्टिकोण वास्तव में परीक्षण के बारे में बात करता है जो प्रोग्रामर करते हैं।

हाँ!! आपने सही अनुमान लगाया !! यह इकाई परीक्षण है।

जो परीक्षण पहले लिखा जाता है वह परीक्षण ऐसा नहीं है जिसे परीक्षक लिखते हैं, बल्कि यह इकाई परीक्षण है जिसे प्रोग्रामर लिखते हैं। इसलिए, मैं निम्न चरणों का पालन करूंगा:

  • UNIT टेस्ट पहले लिखा जाता है
  • UNIT परीक्षण निष्पादित किया गया है - जो विफल हो जाएगा (स्पष्ट कारणों के लिए)
  • कोड सिर्फ टेस्ट पास करने के लिए (या रिफैक्टेड) ​​लिखा जाता है
  • UNIT परीक्षण को फिर से निष्पादित किया जाता है
  • यदि परीक्षण पास हो जाता है, तो अगले परीक्षण के लिए आगे बढ़ें ELSE फिर से लिखना / परीक्षण पास बनाने के लिए कोड को संशोधित करें

अब, यहां जो सवाल उठता है वह है - अगर टीडीडी एक प्रोग्रामर का काम है, तो इस दृष्टिकोण में परीक्षक की भूमिका क्या है?

वैसे, यह कहते हुए कि TDD एक प्रोग्रामर का काम है, इसका मतलब यह नहीं है कि परीक्षक इसमें शामिल नहीं हैं। परीक्षक परीक्षण परिदृश्यों को साझा करके सहयोग कर सकते हैं:

  • सीमा मूल्य मामलों
  • समतुल्य वर्ग परीक्षण के मामलों
  • महत्वपूर्ण व्यापारिक मामले
  • त्रुटि-प्रवण कार्यक्षमता के मामले
  • स्तर के मामलों को सुरक्षित करना

मेरे कहने का मतलब यह है - परीक्षकों को इकाई परीक्षण परिदृश्यों को परिभाषित करने में भाग लेना चाहिए और इसे लागू करने के लिए प्रोग्रामर के साथ सहयोग करना चाहिए। परीक्षकों को परीक्षा परिणामों पर अपनी प्रतिक्रिया प्रदान करनी चाहिए।

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

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

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

व्यवहार प्रेरित विकास

व्यवहार प्रेरित विकास या BDD टेस्ट ड्रिवेन डेवलपमेंट का विस्तार है।

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

बीडीडी की कुछ प्रमुख विशेषताएं इस प्रकार हैं:

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

बीडीडी क्यों?

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

यह मूल रूप से होता है क्योंकि हर किसी की आवश्यकताओं को समझने के लिए अलग-अलग दृष्टिकोण होते हैं। इसलिए, तकनीकी और गैर-तकनीकी लोग एक ही आवश्यकता की अलग-अलग व्याख्या कर सकते हैं, जिससे दोषपूर्ण डिलीवरी हो सकती है। इसलिए, यह महत्वपूर्ण है कि विकास टीम में हर कोई एसएएमई की आवश्यकता को समझे और इसे उसी तरह से व्याख्या करे।

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

BDD दृष्टिकोण विकास टीम को ऐसा करने की अनुमति देता है: -

  • सरल अंग्रेजी में आवश्यकता को परिभाषित करने के लिए एक मानक दृष्टिकोण को परिभाषित करना
  • आवश्यकताओं को स्पष्ट करने वाले उदाहरणों को परिभाषित करने का प्रावधान
  • एक इंटरफ़ेस / मंच प्रदान करें जो तकनीकी (प्रोग्रामर / परीक्षक) और गैर-तकनीकी (पीओ / बीए / ग्राहक) को सहयोग करने और एक साथ आने और आवश्यकताओं को समझने और लागू करने के लिए एक ही पृष्ठ पर होने में सक्षम बनाता है।

बीडीडी कैसे लागू करें?

BDD को लागू करने के लिए बाजार में कई उपकरण उपलब्ध हैं। मैं यहाँ कुछ नामकरण कर रहा हूँ:

  • खीरा
  • स्वास्थ्य
  • सामंजस्य
  • जेबेहेव
  • विशिष्ट प्रवाह

उदाहरण:

एक उदाहरण के साथ बीडीडी को समझने की कोशिश करते हैं। मेरे मामले के लिए, मैं गेरकिन (ककड़ी) का उपयोग कर रहा हूं:

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

गेरकिन फ़ाइल (फ़ीचर फ़ाइल) इस प्रकार होगी:

फ़ीचर: टेस्ट पंजीकरण पोर्टल

परिदृश्य की रूपरेखा: मान्य उपयोगकर्ता ने लॉगिन किया

दिया हुआ: ग्राहक पंजीकरण पोर्टल खोलता है

कब: उपयोगकर्ता 'और' के रूप में पासवर्ड के रूप में उपयोगकर्ता नाम दर्ज करता है

फिर: ग्राहक को फॉर्म देखने में सक्षम होना चाहिए।

उदाहरण :

| उपयोगकर्ता | पासवर्ड |

| उपयोगकर्ता 1 | pwd1 |

| उपयोगकर्ता 2 | pwd2 |

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

BDD दृष्टिकोण प्रयास और लागतों और जाँचों को बचाता है, यदि कोई कमी है तो उत्पादन परिनियोजन के बाद ग्राहकों और डेवलपर्स के सहयोग से इस सुविधा के विकास चक्र में थे।

विकास दल इन फीचर फ़ाइलों का उपयोग कर सकते हैं और उन्हें एक विशेष सुविधा का परीक्षण करने के लिए निष्पादन योग्य कार्यक्रमों में बदल सकते हैं।

कैसे?

ठीक है, आपको इसके लिए ककड़ी / फिटनेस सीखने की ज़रूरत है !!

स्वीकृति टेस्ट प्रेरित विकास

स्वीकृति टेस्ट ड्रिवेन डेवलपमेंट या ATDD एक ऐसी तकनीक है जहां पूरी टीम वास्तव में शुरू होने से पहले एक महाकाव्य / कहानी की स्वीकृति मानदंडों को परिभाषित करने के लिए सहयोग करती है। ये स्वीकृति परीक्षण उचित उदाहरण और अन्य आवश्यक जानकारी द्वारा समर्थित हैं।

ज्यादातर समय, बीडीडी और एटीडीडी का उपयोग एक-दूसरे से किया जाता है। ATDD दृष्टिकोण को दिए गए-जब-तब प्रारूप का उपयोग करके भी लागू किया जा सकता है, ठीक उसी तरह जैसे हम BDD दृष्टिकोण में कैसे लिखते हैं।

आइए 3 दृष्टिकोणों के बीच अंतरों को संक्षेप में बताने का प्रयास करें:

  • टीडीडी अधिक तकनीकी है और उसी भाषा में लिखा जाता है जिसमें यह सुविधा लागू होती है। यदि सुविधा जावा में कार्यान्वित की जाती है, तो हम JUnit लिखते हैं परीक्षण के मामलों । जबकि BDD & ATDD को सरल अंग्रेजी भाषा में लिखा गया है
  • TDD दृष्टिकोण एक सुविधा के कार्यान्वयन पर केंद्रित है। जबकि BDD सुविधा के व्यवहार पर केंद्रित है, और ATDD आवश्यकताओं को कैप्चर करने पर केंद्रित है
  • टीडीडी को लागू करने के लिए हमें तकनीकी ज्ञान होना चाहिए। जबकि BDD और ATDD को किसी भी तकनीकी ज्ञान की आवश्यकता नहीं होती है। BDD / ATDD की सुंदरता इस तथ्य में निहित है कि दोनों तकनीकी, साथ ही गैर-तकनीकी लोग, विकासशील विशेषता में भाग ले सकते हैं
  • चूंकि टीडीडी विकसित है, यह अच्छी डिजाइन की गुंजाइश देता है और गुणवत्ता की 'बैठक की आवश्यकता' पहलू पर केंद्रित है; जबकि BDD / ATDD 2 पर ध्यान केंद्रित करता हैएन डीगुणवत्ता का पहलू जो 'उपयोग के लिए फिट' है

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

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

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

एंड्रॉइड पर बिन फ़ाइल कैसे खोलें

मुझे इस चर्चा को Agile में प्रसिद्ध टेस्ट पिरामिड के साथ संक्षेप में प्रस्तुत करें:

एजाइल में टेस्ट पिरामिड

इस पिरामिड की सबसे निचली परत इकाई परीक्षण परत से बनी है। यह परत नींव की परत है; इसलिए यह शाही है कि यह परत ठोस है। अधिकांश परीक्षणों को इस परत में धकेल दिया जाना चाहिए। यह सबसे निचली परत केवल TDD पर केंद्रित है।

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

पिरामिड की इस परत में उपयोग किए जाने वाले उपकरण सभी एक्सनिट उपकरण हैं।

पिरामिड की मध्य परत सेवा स्तर की जांच बताते हुए, सेवा परत है। यह परत एप्लिकेशन यूजर इंटरफेस और निचले स्तर की इकाई / घटक के बीच एक सेतु का काम करती है। इस परत में अधिकतर API शामिल होते हैं जो UI से अनुरोध स्वीकार करते हैं और प्रतिक्रिया वापस भेजते हैं। पिरामिड की इस परत में BDD और TTDD दृष्टिकोण सक्रिय है।

पिरामिड की मध्य परत में उपयोग किए जाने वाले उपकरण हैं - फिटनेस, ककड़ी और रोबोट फ्रेमवर्क ।

पिरामिड की सबसे ऊपरी परत वास्तविक यूआई है, जो यह दर्शाती है कि इस परत में कम से कम परीक्षण शामिल होने चाहिए, या मुझे कहना चाहिए, इस विशेष परत पर परीक्षण का प्रयास न्यूनतम होना चाहिए। जब हम पिरामिड की सबसे ऊपरी परत पर पहुँचते हैं, तो फीचर का अधिकांश परीक्षण पूरा हो जाना चाहिए था।

शीर्ष परत में प्रयुक्त उपकरण हैं - सेलेनियम , QTP , और RFT।

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

वास्तव में, इन तरीकों को वास्तव में स्वचालन के माध्यम से निष्पादित किया जाता है। हर स्प्रिंट के अंत में, नई सुविधाओं को जोड़ा जा रहा है, इसलिए यह महत्वपूर्ण हो जाता है कि पहले से लागू फीचर उम्मीद के मुताबिक काम करें; इसलिये, स्वचालन यहाँ HERO बन जाता है।

निष्कर्ष

लेख के अंत तक, आपने यह जाना होगा कि टीडीडी, बीडीडी और एटीडीडी तकनीकों में परीक्षक कैसे शामिल किए जाते हैं।

श्रृंखला के तीसरे भाग में, मैं एक फुर्तीली दुनिया में स्वचालन पर अपनी चर्चा पर ध्यान केंद्रित करूँगा।

लेखक के बारे में: यह लेख एसटीएच लेखक शिल्पा का है। वह इंटरनेट विज्ञापन, निवेश बैंकिंग और दूरसंचार जैसे डोमेन में पिछले 10+ वर्षों से सॉफ़्टवेयर परीक्षण क्षेत्र में काम कर रही है।

और अधिक अपडेट के लिए इस स्पेस को देखते रहें।

अनुशंसित पाठ

^