बीडीडी/टीडीडी बनाम जेएडी?

Question

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

मुझे पता है कि टेस्टेबल विनिर्देशों के खिलाफ काम करना increase developer productivity है। और मैं पहले से ही कई उदाहरणों के बारे में सोच सकता हूं जहां यह हमारी परियोजना पर होगा।

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

ऐसा इसलिए है क्योंकि हमारे पास पहले से ही एक संयुक्त अनुप्रयोग विकास (जेएडी) प्रक्रिया है, जिसमें डेवलपर्स, प्रबंधन, उपयोगकर्ता अनुभव और परीक्षक सभी आवश्यकताओं के एक सामान्य सेट पर सहमत होने के लिए मिलकर मिलते हैं।

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

यह कहते हैं, डेवलपर्स के लिए पर्याप्त है और चश्मा कैसे लिखे जाते हैं इसे बदलने की जरूरत नहीं है।

उनके पास एक बिंदु है।

क्या BDD/TDD की वास्तविक लाभ, यदि आप पहले से ही एक परीक्षण टीम है जो है परीक्षण मामलों वर्तमान में डेवलपर को दिए गए उच्च स्तर चश्मा के साथ पूरी तरह से संगत कर रहे हैं है?

Answer 1

यदि आप उन्हें मनाने के लिए चाहते हैं कि इससे मदद मिलेगी, तो आपको जिस चीज को करने की ज़रूरत है वह एक समस्या की पहचान करेगी जो इसे हल करेगी।

आपकी स्थिति में क्या हो रहा है जो आपको लगता है कि इससे सुधार होगा?

बीडीडी का मुख्य लाभ हितधारकों और डेवलपर्स के बीच संचार में सुधार करना है।

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

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

Answer 2

यह अपने सबसे हल्का रूप में BDD के बारे में सोच करने के लिए मदद कर सकते हैं, विशेष परिदृश्यों के आसपास चर्चा के रूप में।

आप अपने उपयोग के मामलों मिल गया है। आपको अपनी आवश्यकताएं मिली हैं अब आप यह सत्यापित करना चाहते हैं कि आपको उन लोगों की वास्तव में अच्छी समझ मिली है। तो कोई - शायद एक डेवलपर, शायद एक परीक्षक - कहता है, "ठीक है। बस यह सत्यापित करने के लिए कि मैं समझता हूं ... दिया गया है कि हम < से > के साथ शुरू करते हैं, जब कोई उपयोगकर्ता < करता है तो यह > तब < यह > होना चाहिए। सही?"

और परीक्षक कहेंगे, "हाँ, यह सही है।"

फिर यूएक्स या विश्लेषक कहते हैं, "ठीक है, यह सही है जब तक कि < यह अन्य संदर्भ > मौजूद है"।

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

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

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

Answer 3

यह एक उत्कृष्ट सवाल है, वास्तव में जब यह बीडीडी की बात आती है तो यह "नीचे पंक्ति" प्रश्न है। टीडीडी या लिखित यूनिट-टेस्ट की प्रमुख चुनौतियों में से एक यह है कि डेवलपर्स को कभी भी चीजों की बड़ी तस्वीर और व्यावसायिक परिप्रेक्ष्य नहीं मिलता है। वास्तविक 'व्यापार' परिदृश्यों का परीक्षण करने के लिए चश्मा लिखने और इकाइयों के उत्पादन के परीक्षणों का अभ्यास, डेवलपर्स को उनकी 'शिल्प कौशल' से ऊपर उठाने और व्यापार परिप्रेक्ष्य को समझने में सहायता करता है। बाहर अधिक जानकारी के लिए इस पोस्ट पर की जाँच करें,

http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/

Answer 4

मैं सिर्फ इस सवाल में आए और सोचा था कि मैं वजन था क्योंकि यह वास्तव में एक बहुत ही दिलचस्प सवाल है।

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

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

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

दिन के अंत में, एक पद्धति केवल अंतिम परिणाम के रूप में उतनी ही अच्छी है। कार्य सॉफ्टवेयर, और सभी हितधारकों की संतुष्टि।

:-)