🔰 🕴🏽 ⚠️ उत्पाद रिलीज में तेजी लाने और स्थिर करने के लिए परीक्षण का आयोजन कैसे करें। भाग 1 💪 👩🏾‍⚕️ 🛤️

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

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

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

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

ऐसी स्थिति में, समझौतों की भूमिका तेजी से बढ़ती है: यदि टीम का एक हिस्सा नहीं जानता कि दूसरा क्या कर रहा है, और प्रत्येक टीम के अपने नियम हैं, तो समस्याएं अनिवार्य रूप से उत्पन्न होंगी।

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

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

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

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

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

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

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

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

हमारे उत्पाद में क्या प्रक्रियाएँ बदली हैं

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

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

कोड लेआउट

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

इस सब से बचने के लिए, हमें शाखाओं और वातावरणों की संख्या निर्धारित करने की आवश्यकता है, साथ ही परीक्षण के लिए कोड डालने की प्रक्रिया पर सहमत होना चाहिए।

सबसे आसान तरीका प्रक्रिया को "साफ" और "गंदे" कोड के साथ दो शाखाओं में विभाजित करना होगा। लेकिन हमें कई शर्तों को पूरा करना था:

« », « »
,
.

हमने एक नई योजना पर चर्चा करने के लिए 2 घंटे बिताए और निम्नलिखित पर आए: हम तीन शाखाएँ शुरू करते हैं, उनमें से दो (रिलीज़ और मास्टर) स्वच्छ कोड के साथ होंगी। "मास्टर" में "रिलीज़" में वर्तमान उत्पाद संस्करण है - ऐसी विशेषताएं जो बाहर रोल करने के लिए तैयार हैं। देव में, परीक्षण होता है, यहां परीक्षण के लिए तैयार कार्य हैं, स्थानीय स्तर पर विकास होता है। प्रत्येक शाखा को रोलआउट परीक्षक के साथ समझौते में होता है। यहाँ यह है: इसने

हमें परीक्षण के संदर्भ में क्या दिया:

प्रत्येक कार्य के लिए व्यक्तिगत रूप से परीक्षण का समय 20% कम किया गया था। चेक को फिर से शुरू करना अब आवश्यक नहीं था, अगर कोई नया कार्य बिना किसी चेतावनी के परीक्षण के लिए चला गया, तो नए कार्यों ने पहले से किए गए चेक को ब्लॉक नहीं किया, और दोषों के स्थानीयकरण का समय तेज हो गया।
रिलीज़ को ठीक करने के नियोजित दिन तक, 4 के बजाय 1-2 कार्य अनियंत्रित रहे (यानी, उन्हें जांचने का समय आधा कर दिया गया था)।
एकीकरण परीक्षण और रिहाई के उम्मीदवार परीक्षण का समय 6 घंटे से घटाकर 2 (सबसे कम गिनती) किया गया है।
रिलीज़ स्टेज पर पाए जाने वाले दोषों की संख्या में कमी आई है। पहले, पहले रिलीज़ संस्करण पर, हमने 10 से अधिक पाया, लेकिन अब 4 से अधिक नहीं। रिटायर होने का समय 2 घंटे कम हो गया है।
परीक्षण के समानांतर विकास जारी रखने का अवसर था।

कुल समय, जो हमने परीक्षण पर खर्च किया, ठेस के लिए रोलआउट में देरी हुई, 8 घंटे कम हो गए। टीम के साथ काम करने के लिए एक नई योजना पर चर्चा करने के सिर्फ 2 घंटे - और एक पूरे कार्य दिवस को बचाने में कामयाब रहे, जो हर दो सप्ताह में खर्च होता था। बुरा नहीं?

लेकिन समस्याएं बनी रहीं।

, .
- , , .
.
, .

नीचे पंक्ति: हम रिलीज के दिन काम पर बने रहे।

हम फिर से इकट्ठा हुए। विकास प्रक्रिया को परिष्कृत करके और सीआई को जोड़कर समस्याओं का एक हिस्सा हल किया गया था:

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

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

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

विकास और परीक्षण की योजना बनाना

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

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

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

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

नए प्रारूप में चर्चा को बोझिल बनने से रोकने के लिए, हमने ऐसा 2 सप्ताह पहले नहीं, बल्कि एक सप्ताह के लिए करना शुरू किया।

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

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

इन उपायों ने हमें रिलीज़ चक्र को 2.5 सप्ताह से 1 तक छोटा करने की अनुमति दी । गति में वृद्धि छोटी लग सकती है, लेकिन मुख्य उपलब्धि यह थी कि हमारी रिलीज़ अधिक स्थिर और अनुमानित हो गई - हमें "कमांड पर" रिलीज को रोल करने का अवसर मिला: हम एक साथ मिल सकते हैं किसी भी दिन, कार्यों को पूरा करें और शाम तक सब कुछ तैयार और डीबग हो जाएगा।

उत्पाद रिलीज में तेजी लाने और स्थिर करने के लिए परीक्षण का आयोजन कैसे करें। भाग 1

हमारे उत्पाद में क्या प्रक्रियाएँ बदली हैं

कोड लेआउट

विकास और परीक्षण की योजना बनाना

More articles: