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

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

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

सही उत्पाद और सही उत्पाद एक ही बात नहीं हैं!

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

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

उदाहरण द्वारा विशिष्टता के मुख्य तत्व:

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

मुख्य बात हाइलाइट करें (लक्ष्यों से स्कोपिंग स्कोप)

अधिकांश लोगों को यह बनाने में सक्षम है कि उन्हें वास्तव में क्या चाहिए। ज्यादातर मामलों में, आप इस तथ्य का सामना करेंगे कि ग्राहक "मेरे पास एक लक्ष्य है, हम इसे कैसे प्राप्त कर सकते हैं?" क्लाइंट आपको बताएगा कि वह समस्या का समाधान कैसे देखता है, और कार्यान्वयन विवरण में गहराई से गोता लगाएँ।

यहाँ पहली और सबसे महत्वपूर्ण गलती है । आमतौर पर एक और एक ही समस्या को कई तरीकों से हल किया जा सकता है, और आवश्यकताओं के रूप में हमें पहले से ही संभव समाधानों में से एक को लागू करने का अनुरोध प्राप्त होता है। लेकिन सभी समाधान ~~योगर्ट~~ समान रूप से ~~उपयोगी~~ नहीं हैं।
इंजीनियरों के रूप में हमारा काम ग्राहक द्वारा पूछे जाने वाले समाधान की तुलना में बेहतर और सस्ता समाधान प्रदान करना है। यह सिद्धांत हेनरी फोर्ड द्वारा तैयार किया गया था:

"अगर मैंने लोगों से पूछा कि वे क्या चाहते हैं, तो वे एक तेज घोड़े के लिए कहेंगे।"

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

30 से अधिक साल बीत चुके हैं, और ये सेनानियों अभी भी उत्पादन कर रहे हैं। 25 देशों में बिके 4400 विमान यह एफ -16 पर है कि वे अधिकांश हॉलीवुड फिल्मों में उड़ते हैं: स्वतंत्रता दिवस से ट्रांसफॉर्मर तक ... एफ -16 अभी भी मच 2 से अधिक गति तक नहीं पहुंच सकता है।
एफ -16 इतना सफल साबित हुआ क्योंकि इंजीनियर ने ग्राहक द्वारा अनुरोध किए गए समाधान की तुलना में बेहतर और सस्ता समाधान पेश किया।

लक्ष्यों पर ध्यान दें, निर्णय पर सीधे न जाएं। लक्ष्य प्राप्त करने के कई तरीके हैं।

मुख्य बात को कैसे उजागर करें

अल्बर्ट आइंस्टीन ने एक बार कहा था:

"किसी समस्या का समाधान अक्सर हल करने से अधिक महत्वपूर्ण होता है।"

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

यहां असफल वस्तुओं के कुछ उदाहरण दिए गए हैं जो विनिर्देशन में शामिल हैं:

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

उपयोगकर्ता-कहानियों का उपयोग करें

उपयोगकर्ता-कहानियों को समझने के लिए सबसे अच्छे तरीकों में से एक है कि वास्तव में क्या आवश्यक है। उपयोगकर्ता-कहानियों को थोड़ा अलग तरीके से स्वरूपित किया जा सकता है, लेकिन इसमें 3 बिंदु होने चाहिए:
के क्रम में - क्यों?
एक के रूप में - कौन?
मुझे क्या चाहिए?

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

यह ऑनलाइन स्टोर की वफादारी बढ़ाने के लिए ~~स्पैमिंग~~ कार्यक्रमों की उपयोगकर्ता-कहानियों की तरह लग सकता है (मैं उन पाठकों से माफी मांगता हूं जो अंग्रेजी अच्छी तरह से नहीं जानते हैं, लेकिन मुझे विश्वास है कि प्रलेखन अंग्रेजी में होना चाहिए):

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

सहयोगी रूप से निर्दिष्ट करें

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

समस्या से बेहतर तरीके से निपटें और सबसे अच्छा समाधान निकालें।
पूरी टीम को नई आवश्यकताओं को समान रूप से समझने का प्रयास करें
प्रक्रिया में सभी प्रतिभागियों को शामिल करें

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

उदाहरण दें (उदाहरणों का उपयोग करके उदाहरण दें)

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

यहाँ एक विनिर्देश पर एक सहयोग प्रक्रिया क्या लग सकती है। उदाहरण के लिए, ऑनलाइन स्टोर "सींग और खुरों" को लें।

बारबरा - ग्राहक प्रतिनिधि
वासिया एक डेवलपर है
ओलेआ - क्यूए

वरवारा: तो, हमने एबीसी प्रेस पब्लिशिंग हाउस के साथ एक समझौता किया है कि हम मुफ्त में खरीदी गई किताबें वितरित करेंगे।
वास्या: पूरे रूस में?
बारबरा: नहीं, आप क्या हैं। केवल मास्को में।
ओला: और हमारे एडमिन एरिया में हर जगह सही पब्लिशिंग हाउस भरा हुआ है? वैरिया, आप हमें पुस्तकों की पूरी सूची दे सकते हैं, मुझे डर है कि हम इसे गलत पा सकते हैं, डेटाबेस में "प्रकाशन गृह" फ़ील्ड एक पंक्ति है।
बारबरा: हां, ज़ाहिर है, वहाँ बहुत सारी किताबें नहीं हैं।
वास्या: हम कितनी किताबें मुफ्त में दे सकते हैं? क्या हमारे पास कोई प्रतिबंध है: 5-10? यदि टोकरी में अन्य प्रकाशकों की किताबें हैं तो क्या होगा?
बारबरा: यह तब तक मायने नहीं रखता, जब तक टोकरी में कम से कम एक किताब है, डिलीवरी मुफ्त है।
वास्या: अच्छा, यदि ग्राहक किसी पुस्तक और फ्रिज का आदेश दे तो क्या होगा? महंगी होगी ऐसी डिलीवरी ...
बारबरा: हां, हमने किसी तरह इसके बारे में नहीं सोचा। आइए हम नीचे लिखें और स्पष्ट करें, और हम एक सप्ताह में इस पर चर्चा करेंगे, क्या काम शुरू करने के लिए पर्याप्त जानकारी है?
वास्या: बिल्कुल, मैं स्केचिंग आर्किटेक्चर शुरू करूँगा।
ओला: और मैं जांच करूंगा कि प्रकाशकों के साथ क्या है।
3 दिनों के बाद।
बारबरा (फोन द्वारा): हमने बात की और फैसला किया कि मुफ्त शिपिंग केवल पुस्तकों के लिए उपलब्ध होगा। यदि टोकरी में कुछ और है, तो केवल सामान्य डिलीवरी। और हमने ऊपर से पुस्तकों की संख्या को 10 से अधिक नहीं करने का निर्णय लिया।
वस्या: ठीक है।

परिणामस्वरूप, हमें प्रमुख उदाहरण मिलते हैं :

ग्राहक प्रकार	गाड़ी की सामग्री	वितरण
वीआईपी	1 पुस्तक	मुक्त
वीआईपी	10 किताबें	मुक्त
वीआईपी	11 किताबें	मानक
नियमित	10 किताबें	मानक
वीआईपी	5 वाशिंग मशीन	मानक
वीआईपी	1 वॉशिंग मशीन, 5 किताबें	मानक

विनिर्देशन को परिष्कृत करना

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

चर्चा के दौरान, टीम का प्रत्येक सदस्य अपने ऊपर एक कंबल खींचेगा।

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

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

स्वीकृति मानदंड
स्वीकृति परीक्षण
भविष्य के प्रतिगमन परीक्षण

गलतफहमी की संभावना को कम करने के लिए, हम दिए गए जब तब के संदर्भ में स्क्रिप्ट लिखेंगे। यदि आप लेखन के इस रूप से परिचित नहीं हैं, तो स्कूल में गणित के पाठ याद रखें: दिए गए, खोजें, समाधान । यहाँ उसी के बारे में है।

दिया - प्रारंभिक संदर्भ (पूर्व शर्त)
कब - घटना (एक स्क्रिप्ट ट्रिगर क्या है)
फिर वह परिणाम है जिसे हम प्राप्त करना चाहते हैं

पुस्तकों के साथ हमारे उदाहरण के लिए, यह इस तरह दिखेगा:

Feature: Free delivery In order to save money As a VIP customer I want the system to offer free delivery on certain items to me Scenario: Free delivery Given I am a VIP customer And I am on product detail page And There are only books in my shopping cart And There are <= 10 books in my shopping cart And I have added 'ABC Press' book to my shopping cart When I press 'Go to checkout' button And I have chosen 'Moscow' in 'Ship To' dropdown Then I can choose free delivery

रिकॉर्डिंग का यह रूप, एक तरफ, गैर-तकनीकी विशेषज्ञों (प्रबंधकों, ग्राहक प्रतिनिधियों, व्यापार विश्लेषकों) के ~~केवल नश्वर लोगों के~~ लिए पठनीय बना रहता है, और दूसरी ओर, अस्पष्टता से बचने के लिए पर्याप्त सख्त है।
हम क्यूए को खुश करने के लिए स्क्रिप्ट को थोड़ा संशोधित कर सकते हैं।

 Scenario Outline: Free delivery Given I am a VIP customer And I am on product detail page And There are only books in my shopping cart And There are <bookQuantity> books in my shopping cart And I have added 'ABC Press' book to my shopping cart When I press 'Go to checkout' button And I have chosen 'Moscow' in 'Ship To' dropdown Then <deliveryType> is available Examples: |bookQuantity|deliveryType| |5 |Free | |10|Free | |11|Standard |

इस मामले में, स्क्रिप्ट का उपयोग परीक्षण मामलों की सूची के रूप में किया जा सकता है।
इस स्क्रिप्ट को लिखने के लिए, मैंने SpecFlow, .NET प्लेटफ़ॉर्म के लिए एक समाधान का उपयोग किया। इसी तरह के उपकरण जावा, रूबी, पीएचपी के लिए हैं।

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

 namespace ProjectName.Specification { public class FreeDeliverySteps { [Given("I am a VIP customer")] public void GivenIAmVipCustomer() { throw new NotImplementedException(); } [Given("I am on product detail page")] public void GivenIAmOnProductDetailPage() { throw new NotImplementedException(); } [Given("I have added \'ABC Press\' book to my shopping cart")] public void GivenIHaveAddedAbcPressBookToMyShoppingCart() { throw new NotImplementedException(); } [Given("There are only books in my shopping cart")] public void GivenThereAreOnlyBooksInMyShoppingCart() { throw new NotImplementedException(); } [Given("There are (.*) books in my shopping cart")] public void GivenThereAreBookQuantityBooksInMyShoppingCart(int bookQuantity) { throw new NotImplementedException(); } [When("I press 'Go to checkout' button")] public void WhenIPressGoToCheckoutButton() { throw new NotImplementedException(); } [When("And I have chosen 'Moscow' in 'Ship To' dropdown")] public void WhenIHaveChosenMoscowInShipToDropdown () { throw new NotImplementedException(); } [Then("Then (.*) is available")] public void ThenDeliveryTypeIsAvailable(string deliveryType) { throw new NotImplementedException(); } } }

आप इस प्रतिमान के संस्थापक की वेबसाइट पर BDD के बारे में अधिक पढ़ सकते हैं।

परिवर्तन विनिर्देश के बिना स्वचालन परीक्षण को लागू करें

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

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

काम के इस संगठन के साथ, आप एक ही स्थान पर विनिर्देश और परीक्षण बदल देंगे। यही है, विनिर्देश ही निष्पादन योग्य हो जाएगा।

निर्माण प्रक्रिया में परीक्षण निष्पादन को एम्बेड करें और प्रलेखन विकसित करें (बार-बार मान्य करना, प्रलेखन प्रणाली विकसित करना)

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

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

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

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

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

मैं क्यों हूँ?

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

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

संदर्भ

पुस्तक साइट: विनिर्देशनबाहर.कॉम
निकोलाई अलिमेनकोव की रिपोर्ट जिसके माध्यम से मैं पुस्तक से परिचित हुआ ( थ्यूसीडाइड्स - नई पीढ़ी स्वीकृति परीक्षण): video.yandex.ru/users/ya-events/view/809/?cauthor=ya-events&cid=75
उदाहरण के लिए कल्पना के बारे में हब्रे पर एक और लेख

उदाहरण के लिए विशिष्टता - प्रगतिवादियों के लिए बीडीडी