हम यूआई परीक्षणों के साथ ए / बी परीक्षण कवर करते हैं। देशी कोड में भ्रमित कैसे न हों

नमस्कार, हेब्र!

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

यह इस बारे में होगा कि हमने ए / बी परीक्षणों के साथ यूआई परीक्षण की प्रक्रिया को कैसे व्यवस्थित किया, जिसमें से हमारे पास बहुत कुछ है। मैं इस बारे में बात करूंगा कि हमें किन समस्याओं का सामना करना पड़ा और अंत में कौन सी बाढ़ आई। बिल्ली के लिए आपका स्वागत है!

जब तक हम शुरू नहीं हुए ...

इस लेख में शब्द परीक्षण बहुत आम है। ऐसा इसलिए है क्योंकि हम एक ही समय में यूआई परीक्षण और ए / बी परीक्षण के बारे में बात कर रहे हैं। मैंने हमेशा इन दोनों अवधारणाओं को अलग करने और विचारों को तैयार करने की कोशिश की ताकि पाठ को पढ़ने में आसानी हो। अगर कहीं मुझे इस शब्द का पहला भाग याद नहीं है और मैंने केवल "परीक्षण" लिखा है, तो मेरा मतलब था यूआई परीक्षण।

अच्छा पढ़ लो!

ए / बी परीक्षण क्या हैं

तो, सबसे पहले, आइए A / B परीक्षण की अवधारणा को परिभाषित करें। यहाँ एक उद्धरण विकिपीडिया से लिया गया है:

"ए / बी परीक्षण (इंजी। ए / बी परीक्षण, स्प्लिट परीक्षण) विपणन अनुसंधान का एक तरीका है, जिसका सार यह है कि तत्वों के नियंत्रण समूह की तुलना परीक्षण समूहों के एक सेट के साथ की जाती है जिसमें एक या एक से अधिक संकेतक बदल दिए गए हैं, क्रम में यह जानने के लिए कि कौन सा परिवर्तन लक्ष्य को बेहतर बनाता है ” लिंक ।

हमारी परियोजना के संदर्भ में, ए / बी परीक्षण की उपस्थिति का अर्थ है कि विभिन्न उपयोगकर्ताओं के लिए कुछ कार्यक्षमता अलग है। मैं कई विकल्पों पर प्रकाश डालूंगा:

• यह सुविधा एक उपयोगकर्ता समूह के लिए उपलब्ध है, लेकिन दूसरे के लिए उपलब्ध नहीं है;
• यह सुविधा सभी उपयोगकर्ताओं के लिए उपलब्ध है, लेकिन यह अलग-अलग तरीकों से काम करती है;
• यह सुविधा सभी उपयोगकर्ताओं के लिए उपलब्ध है, यह एक ही काम करता है, लेकिन यह अलग दिखता है;
• पिछले तीन विकल्पों में से कोई भी संयोजन।

काम करने के लिए इस सभी तर्क के लिए, हमारे पास हमारी कंपनी में एक उपकरण है, जिसे UserSplit Tool कहा जाता है, और हमारे डेवलपर रिनैट अखमदेव ने इस लेख में इसके बारे में विस्तार से बात की है।

हम अब इस बारे में बात करेंगे कि परीक्षण विभाग और विशेष रूप से स्वचालन के लिए ए / बी परीक्षण के क्या मायने हैं।

यूआई परीक्षण कवरेज

जब हम UI कवरेज के बारे में बात करते हैं, तो हम उस कोड की संख्या के बारे में बात नहीं कर रहे हैं जिसे हमने परीक्षण किया था। यह समझ में आता है, क्योंकि यहां तक ​​कि सिर्फ एक पेज खोलने से कई घटक शामिल हो सकते हैं, जबकि हमने अभी तक कुछ भी परीक्षण नहीं किया है।

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

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

शुरुआत में यूआई परीक्षणों द्वारा कैसे सुविधाओं को कवर किया गया था

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

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

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

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

A / B परीक्षण और QAAPI के लिए बल

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

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

उसी QAAPI का उपयोग करके, हम A / B परीक्षण समूह को बाध्य कर सकते हैं; यह परीक्षण के नाम और वांछित समूह के नाम को इंगित करने के लिए पर्याप्त है। परीक्षण कॉल कुछ इस तरह दिखता है:

QaApi::forceSpliTest(“Test name”, “Test group name”, {USER_ID or DEVICE_ID}); 

हमारे द्वारा निर्दिष्ट अंतिम पैरामीटर user_id या device_id है, जिसके लिए इस बल को काम करना शुरू करना चाहिए। हम एक अनधिकृत उपयोगकर्ता के मामले में device_id पैरामीटर निर्दिष्ट करते हैं, क्योंकि user_id पैरामीटर अभी तक नहीं है। यह सही है, अनधिकृत पृष्ठों के लिए हमारे पास ए / बी परीक्षण भी हैं।

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

और इसलिए हम लंबे समय तक जीवित रहे। यूआई परीक्षण केवल ए / बी परीक्षणों के नियंत्रण समूहों को कवर करते हैं। तब बहुत सारे नहीं थे, और यह काम किया। लेकिन समय बीतता गया; ए / बी परीक्षणों की संख्या में वृद्धि होने लगी और लगभग सभी नई सुविधाएँ ए / बी परीक्षणों के तहत चलने लगीं। सुविधाओं के केवल नियंत्रण संस्करणों को कवर करने के दृष्टिकोण ने हमें संतुष्ट कर दिया। और यहाँ क्यों है ...

ए / बी परीक्षण क्यों कवर करें

समस्या एक - कवरेज

जैसा कि मैंने ऊपर लिखा था, समय के साथ, लगभग सभी नई विशेषताएं ए / बी परीक्षणों के तहत सामने आने लगीं। नियंत्रण के अलावा, प्रत्येक सुविधा में एक और दो या तीन अन्य विकल्प होते हैं। यह पता चला है कि ऐसी सुविधा के लिए सर्वश्रेष्ठ मामले में कवरेज 50% से अधिक नहीं होगा, और सबसे खराब स्थिति में यह लगभग 25% होगा। पहले, जब ऐसी कुछ विशेषताएँ थीं, तो कुल कवरेज दर पर इसका कोई महत्वपूर्ण प्रभाव नहीं पड़ा। अब - यह प्रस्तुत करना शुरू किया।

समस्या दो - लंबे ए / बी टेस्ट

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

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

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

तीसरी समस्या यूआई परीक्षणों की प्रासंगिकता है

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

मान लीजिए कि गैर-नियंत्रण संस्करण जीत गया और बेहतर हो गया। यूआई परीक्षणों का क्या होगा जिसने इसे कवर किया है? यह सही है: वे टूट जाएंगे। लेकिन क्या होगा अगर वे निर्माण के रिलीज होने से एक घंटे पहले टूट जाते हैं? क्या हम इस निर्माण का प्रतिगमन परीक्षण कर सकते हैं? नहीं। जैसा कि आप जानते हैं, टूटे हुए परीक्षणों के साथ आप बहुत दूर नहीं जाएंगे।

तो, आपको अग्रिम में किसी भी ए / बी परीक्षण को बंद करने के लिए तैयार रहने की आवश्यकता है ताकि यह यूआई परीक्षणों के प्रदर्शन में हस्तक्षेप न करे और, परिणामस्वरूप, बिल्ड की अगली रिलीज़।

निष्कर्ष

ऊपर से निष्कर्ष स्पष्ट है: हमें ए / बी परीक्षणों को उनकी संपूर्णता में यूआई परीक्षणों के साथ कवर करने की आवश्यकता है, सभी विकल्प। क्या यह तर्कसंगत है? हाँ! आप सभी को धन्यवाद, विचलन!

... मजाक! इतना सरल नहीं है।

ए / बी परीक्षणों के लिए इंटरफ़ेस

पहली चीज़ जो असुविधाजनक लग रही थी, वह थी नियंत्रण जिस पर ए / बी परीक्षण और सुविधाएँ पहले से ही कवर थीं, और जो अभी तक नहीं थीं। ऐतिहासिक रूप से, हम निम्नलिखित सिद्धांत के अनुसार UI परीक्षण कहते हैं:

• सुविधा या पृष्ठ का नाम;
• केस विवरण;
• टेस्ट।

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

कोडी विधि को कॉल करने के लिए हर समय कोड को हथियाना अभी भी एक खुशी है।

इसलिए हमने UI परीक्षणों के कोड से QAApi :: forceSplitTest () के लिए सभी कॉल को हटाने का निर्णय लिया और डेटा को इस बारे में स्थानांतरित कर दिया कि MySQL टेबल के लिए कौन सी सेना की आवश्यकता है। उसके लिए, हमने सेलेनियम मैनेजर पर यूआई प्रस्तुति दी (मैंने इसके बारे में यहां बात की)।

यह कुछ इस तरह दिखता है:



तालिका में आप इंगित कर सकते हैं कि कौन सा UI किस ए / बी परीक्षण के बल का परीक्षण करता है और हम किस समूह में आवेदन करना चाहते हैं। आप यूआई टेस्ट का नाम खुद बता सकते हैं, टेस्ट क्लास, या ऑल।

इसके अलावा, हम यह संकेत कर सकते हैं कि क्या यह बल अधिकृत या अनधिकृत उपयोगकर्ताओं पर लागू होता है।

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

इस प्रकार, हम ए / बी परीक्षणों के सभी जोड़तोड़ को एक जगह इकट्ठा करने में कामयाब रहे। अब कवर ए / बी परीक्षणों की सूची को देखना आसान है।

वहाँ हमने नए A / B परीक्षण जोड़ने के लिए एक फॉर्म बनाया:



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

यूआई टेस्ट आर्किटेक्चर

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

संक्षेप में, मैं आपको बताता हूँ कि हम नियमित UI परीक्षण कैसे लिखते हैं। वास्तुकला काफी सरल और परिचित है:

• परीक्षण कक्षाएं - यह कवर की गई सुविधा के व्यापार तर्क का वर्णन करती है (वास्तव में, ये हमारे परीक्षणों की स्क्रिप्ट हैं: यह किया, यह देखा);
• PageObject वर्ग - UI और लोकेटर के साथ सभी इंटरैक्शन वहां वर्णित हैं;
• टेस्टकेस क्लासेस - ऐसे सामान्य तरीके हैं जो सीधे यूआई से संबंधित नहीं हैं, लेकिन कई टेस्ट कक्षाओं में उपयोगी हो सकते हैं (उदाहरण के लिए, QAAPI के साथ बातचीत);
• कोर-क्लास - सत्र को बढ़ाने के तर्क हैं, लॉगिंग और अन्य चीजें जिन्हें आपको नियमित परीक्षण लिखते समय स्पर्श करने की आवश्यकता नहीं है।

सामान्य तौर पर, यह वास्तुकला पूरी तरह से हमारे अनुकूल है। हम जानते हैं कि यदि UI बदल गया है, तो केवल PageObject वर्गों को बदलने की आवश्यकता है (जबकि परीक्षण स्वयं प्रभावित नहीं होने चाहिए)। यदि किसी विशेषता का व्यावसायिक तर्क बदल गया है, तो हम परिदृश्य को बदलते हैं।

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

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

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

फिर PhpStorm हमारे बचाव में आया (सुविधाजनक IDE के लिए JetBrains से लोगों के लिए धन्यवाद), अर्थात् यह सुविधा ।

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

परिणामस्वरूप, परीक्षण कोड कुछ इस तरह से देखा गया:



प्रत्येक क्षेत्र में एक कोड होता है जो किसी विशेष वर्ग का होता है। निश्चित रूप से अन्य आईडीई में भी कुछ ऐसा ही है।

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

अब हम ए / बी परीक्षण कैसे बंद करते हैं

आप यूआई परीक्षणों के साथ एक बार में सभी ए / बी परीक्षणों को केवल ले और कवर नहीं कर सकते। दूसरी ओर, ऐसा कोई कार्य नहीं है। स्वचालन के संदर्भ में चुनौती केवल महत्वपूर्ण और लंबे समय से चल रहे परीक्षणों को कवर करना है।

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

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

हमने अब तक न्यूनतम परिवर्तनों के साथ प्रबंधन किया है, ताकि लक्ष्य वातावरण को तालिका में निर्दिष्ट करने की क्षमता बढ़े:



यह पर्यावरण मौजूदा रिकॉर्ड में मक्खी पर बदला जा सकता है। इस प्रकार, हम केवल स्टेजिंग के लिए बल जोड़ सकते हैं, व्यक्तिगत कार्यों पर पासिंग टेस्ट के परिणामों को प्रभावित किए बिना।

संक्षेप में देना

इसलिए, इस कहानी की शुरुआत से पहले, हमारे यूआई परीक्षणों ने ए / बी परीक्षणों के केवल मुख्य (नियंत्रण) समूहों को कवर किया। लेकिन हमें एहसास हुआ कि हम और अधिक चाहते हैं, और इस निष्कर्ष पर पहुंचे कि ए / बी परीक्षणों के अन्य संस्करणों को कवर करना भी आवश्यक है।

संक्षेप में:

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

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

क्या आपको पहली नज़र में अराजक स्थिति को कुछ नियंत्रित क्रम में लाने और अपने और अपने सहयोगियों के लिए अपने जीवन को सरल बनाने का कोई अनुभव है? इसे टिप्पणियों में साझा करें। :)

आपका ध्यान के लिए धन्यवाद! और नया साल मुबारक हो!