बीडीडी का उपयोग करने का अनुभव

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

हालांकि, अब केवल कंपनियों का एक छोटा हिस्सा BDD का उपयोग करने का निर्णय लेता है। क्यों?

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

चलो एक बार अंतर देखते हैं, और यह स्पष्ट हो जाएगा:

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

कई तरीकों की तुलना करें

नीचे दिया गया आरेख तीन दृष्टिकोणों की तुलना दिखाता है: TDD, TLD (टेस्ट अंतिम विकास) और BDD:

• जब हम BDD कार्यप्रणाली के अनुसार काम करते हैं, तो सॉफ्टवेयर विकास चक्र के प्रत्येक चरण में ऑटोटेस्टिंग और ड्राफ्टिंग स्पेसिफिकेशन साथ होते हैं, जो ऑटोटेस्ट और प्रलेखन की निरंतर प्रासंगिकता सुनिश्चित करता है।
• TDD और ATDD (स्वीकृति परीक्षण) कार्यप्रणाली एक ब्लॉक में एक आरेख में संयुक्त हैं, क्योंकि एनालिटिक्स स्टेज पर लिखा है। जैसा कि ऊपर उल्लेख किया गया है, टीडीडी कार्यक्षमता विकसित करने से पहले परीक्षण लिखने पर आधारित है। परीक्षण के लिए कार्यक्षमता लिखने के लिए डेवलपर को परीक्षण लिखना चाहिए।
• TLD (टेस्ट लास्ट डेवलपमेंट) में कार्यक्षमता के कार्यान्वयन के बाद परीक्षण शामिल है।
• BDD सार्वभौमिक है और इसे विकास के किसी भी चरण में शामिल किया जा सकता है।

दूसरा आरेख स्क्रिप्ट लिखने में विकास प्रक्रिया में प्रतिभागियों की भागीदारी को दर्शाता है।

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

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

यह पेशेवरों के बारे में है। फिर भी, जैसा कि पहले ही कहा जा चुका है, बड़ी संख्या में फायदे के बावजूद, कुछ इस पद्धति को लागू करते हैं।

बीडीडी सभी के लिए अच्छा है, लेकिन इसका उपयोग क्यों नहीं किया जाता है?

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

BDD क्लासिक डेवलपमेंट गाइडलाइन (TLD) को उल्टा कर देता है। इसे खराब तरीके से लागू किया जाता है क्योंकि यह मुश्किल है। विकास चक्र लंबा होता जा रहा है।

BDD निस्संदेह गुणवत्ता प्राप्त करने का एक तरीका है। लेकिन हर कोई इस गुणवत्ता के लिए समय और विशेषज्ञों का भुगतान करने के लिए तैयार नहीं है।

हालांकि, अगर मुझे अभी भी बीडीडी लागू करना है तो मुझे क्या करना चाहिए?

आप तैयार रूपरेखाओं का उपयोग करके देख सकते हैं। उदाहरण के लिए ककड़ी, स्क्विश, यूलुप।

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

BDD ढांचे के साथ शुरुआत करना कठिन और समय लेने वाला है।

हमारा ध्यान गेज नामक यंत्र पर है। यह एक लचीला और हल्का ढांचा है, जिसे मुफ्त लाइसेंस के तहत वितरित किया गया है। सच कहूँ तो, हमने वास्तव में विकल्पों का अध्ययन नहीं किया, क्योंकि गेज का उपयोग हमारे ग्राहक द्वारा आक्रामक रूप से तय किया गया है।

गेज में, परीक्षण विनिर्देश फाइलों (.spec एक्सटेंशन वाली फाइलें) में लिखे जाते हैं। विनिर्देशन में प्राकृतिक भाषा में लिखे गए परीक्षण चरण हैं। ये चरण एक प्रोग्रामिंग भाषा में लागू किए गए हैं (हमने जावा प्रोग्रामिंग भाषा का उपयोग किया है)। चरणों को लागू करते समय, स्क्रिप्ट और कार्यान्वयन फ़ाइलों के नाम दोनों में नामकरण कन्वेंशन का पालन करना महत्वपूर्ण है, और स्क्रिप्ट के कार्यान्वयन के तरीकों और चरणों के नामों में, उन्हें पूरी तरह से समान होना चाहिए। इस उपकरण का एक अतिरिक्त लचीलापन यह है कि चरणों में पैरामीटर हो सकते हैं।

गेज ने हमें बीडीडी के लाभों का उपयोग करने की अनुमति दी। हालांकि, हमें अभी भी समस्याओं का सामना करना पड़ा है जो कार्यान्वयन की जटिलता हैं: उपकरण की समस्याएं और प्रक्रिया का कार्यान्वयन।

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

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

परीक्षक का काम पहले इस तरह दिखता था:

1. प्रलेखन की परीक्षा, यदि कोई हो;
2. एक चेकलिस्ट तैयार करना;
3. तदर्थ परीक्षण
4. एक परीक्षण योजना तैयार करना;
5. विश्लेषक की विश्वदृष्टि का शोधन;
6. डेवलपर द्वारा दुनिया की तस्वीर को परिष्कृत करना;
7. यदि सब कुछ एक साथ बड़ा हो गया है, तो परीक्षण प्रलेखन लिखना, परीक्षण के साथ समानांतर में;
8. फिक्स कीड़े, परीक्षण कीड़े की प्रतीक्षा कर रहा है;
9. वेब-ड्राइवर का उपयोग करते हुए पेज पर तत्वों का विवरण, नियंत्रण, खोज। परीक्षण प्रणाली में पहले से ही लागू किया गया है के लिए खोज;
10. परीक्षण तर्क लिखना;
11. जारी;
12. समर्थन बग / रेग बग;
13. विनिर्देश अद्यतन;
14. बग को ठीक करें
15. ऑटोटेस्ट अपडेट, बड़ी संख्या में परिवर्तित नियंत्रणों को अपडेट करना;
16. जारी;
17. ...
    इटैलिक्स (1, 5, 6, 7, 9, 13, 15) में आइटम समय की लागत का नेतृत्व करते हैं। उन्हें अनुकूलित किया जा सकता है।

इस सूची को संक्षेप में विकास प्रक्रिया के आरेख में चित्रित किया गया है:

हमारी कंपनी इंटरफेस के वेब कार्यान्वयन के साथ परियोजनाओं में माहिर हैं। इसके आधार पर, हम वेब ब्राउज़र के साथ बातचीत करने के लिए वेब ड्राइवर टूल का उपयोग करते हैं।

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

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

इस योजना में, BDD फ्रेमवर्क के बजाय, आप जरूरत के आधार पर jUnit, TestNG या कोई अन्य, कोई भी बंडल काम करेंगे। सेलेनियम और मस्केरडे रहेंगे, प्रोग्रामिंग भाषा को बदला जा सकता है।

कोड राइटिंग को गति देना - कनेक्ट करना बहाना

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

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

$(new By.ByXPath("//*/div/div[2]/div/div[2]/div/div/div[3]/div/div/div[3).click(); 

या जावा में अधिक संक्षिप्त निर्माण, जो, हालांकि, अभी भी बोझिल हैं:

 private static void click(String cssClass, String caption) { $(By.cssSelector(cssClass) .$(byText(caption)) .closest(".v-button") .click(); } 

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

पृष्ठ कोड में, हम एक स्पष्ट रूप से पहचानने योग्य तत्व cuba-id=”loginButton”

चलो बहाना पुस्तकालय का उपयोग करते हुए बटन का वर्णन करें:

 @Wire(path = {"WebHBoxLayout", "loginButton"}) private Button loginButton; 

ज्युनिट फ्रेमवर्क पर एक सरल परीक्षण कार्यान्वयन एक प्राधिकरण ब्लॉक है जो प्रत्येक परीक्षण से पहले चलता है:

 @Before public void loginAdm() { Tests loginTest = _$(Tests.class); loginTest.login(); } 

और लॉगिन विधि के शरीर में, निम्न कोड:

 LoginWindow loginWindow = _$(LoginWindow.class); assertNotNull(loginWindow.getLoginField()); loginWindow.getLoginField() .shouldBe(EDITABLE) .shouldBe(ENABLED); loginWindow.loginField.setValue("admin"); loginWindow.passwordField.setValue("admin"); loginWindow.rememberMeCheckBox.setChecked(true); loginWindow.loginButton().click(); 

सबसे महत्वपूर्ण बात यह है कि हम पृष्ठ का वर्णन कैसे करते हैं, हम तत्वों का उल्लेख कैसे करते हैं। LoginWindow पेज का विवरण:

 public class LoginWindow extends Composite<LoginWindow> { @Wire(path = {"loginField"} ) private TextField loginField; @Wire(path = {"passwordField"} ) private PasswordField passwordField; @Wire(path = {"rememberMeCheckBox"} ) private CheckBox rememberMeCheckBox; @Wire(path = {"loginFormLayout", "loginButton"} ) private Button loginButton; } 

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

 getMaxResultsLayout().openOptionsPopup().select("5000") 

या तालिका को क्रमबद्ध करें:

 Table tb1 = client.getPaymentsTable(); tb1.sort("column_year", Table.SortDirection.ASCENDING); 

कुछ तालिका क्रियाओं की सूची के लिए नीचे स्क्रीनशॉट देखें:

बहाना का उपयोग करके परीक्षणों के लेखन को बहुत सरल बना दिया है, अब नई कार्यक्षमता के लिए परीक्षण लिखने के लिए, आपको आवश्यकता है:

1. किसी पृष्ठ का वर्णन करने के लिए Masquerade का उपयोग करना आसान है और इसके लिए विशेष प्रोग्रामिंग कौशल की आवश्यकता नहीं होती है।
2. कार्यक्षमता की जाँच करते समय उपयोग किए जाने वाले सभी पृष्ठों को एक कक्षा में एकत्रित करें।
3. प्राकृतिक भाषा के तैयार किए गए निर्माणों से, एक परीक्षण स्क्रिप्ट एकत्र करें (वहां आवश्यक तत्वों के नाम का प्रतिस्थापन), अर्थात एक गेज विनिर्देशन लिखें।

बहाना और गेज को एकीकृत करना

BDD का उपयोग करने से पहले, TLD दृष्टिकोण का उपयोग किया गया था और इसके साथ काम करने के लिए हमने परीक्षण कोड लिखने की प्रक्रिया को भी अनुकूलित किया था। ज्यूनिट / टेस्टएनजी + वेबड्राइवर + सेलेनाइड + बहाना बंडल का इस्तेमाल किया।

अब, गेज के साथ काम करने के लिए, हम संबंधित प्लग-इन को intellij IDEA में जोड़ते हैं। उसके बाद, एक नए प्रकार का परीक्षण बनाना संभव होगा - विशिष्टता।

अब हम विनिर्देश (स्क्रिप्ट) बनाते हैं और WebDriver, Masquerade और Java की क्षमताओं का उपयोग करके चरणों को लागू करते हैं।

हम स्क्रिप्ट के चरण पर क्लिक करते हैं और कार्यान्वयन पर जाते हैं:

कार्यान्वयन में, आप मौजूदा लॉगिन () विधि का उपयोग कर सकते हैं।

यह पूर्णता कैसी दिखती है?

उस उदाहरण को याद करें जिसे हमने लेख की शुरुआत में जांचा था:

"Navigation.openMenu(menu)” में Masquerade लाइब्रेरी का उपयोग करके एक मेनू खोलने का कार्यान्वयन है।

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

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

प्रक्रिया परिवर्तन नीचे दिखाए गए हैं:

यह था:

यह बन गया:

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

परिणाम

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

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

लाइब्रेरी की उपस्थिति में परीक्षणों को लागू करने और समर्थन करने का समय जो सामान्य वस्तुओं को साफ-सुथरे वेब-ड्राइवर के साथ काम करने और एक्सपी लिंक को रीमेक करने की लागत की तुलना में पेज ऑब्जेक्ट्स के साथ काम करने को आसान बनाता है।

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

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

लेखक: सुनागतोव इल्डार और युसकोवा जूलिया ( युस्कोवा )