Yandex.Market में फ्रंटएंड टेस्टिंग की व्यवस्था कैसे की जाती है और हम साप्ताहिक रिलीज से इनकार क्यों करते हैं

सभी को नमस्कार, मेरा नाम सर्गेई है। मैं Yandex.Market फ्रंटएंड का परीक्षण कर रहा हूं। मुझे पता है कि हबर के पाठकों में कई आईटी विशेषज्ञ हैं जो किसी न किसी तरह से रिलीज प्रक्रिया और परीक्षण से जुड़े हैं। मेरे पास आपके लिए एक सवाल है। क्या आपके व्यवहार में कभी ऐसा हुआ है कि उत्पादन में विशेषताएं लंबे समय तक रोल नहीं करती हैं? क्या आप फूला हुआ रिलीज और उनके वॉल्यूमेट्रिक चेक के बारे में जानते हैं?

मुझे लगता है कि हर किसी के पास यह था। मैं 3 साल पहले यैंडेक्स में आया था, हमारी टीम बहुत छोटी थी, प्रक्रियाएं पूरी तरह से स्थापित नहीं थीं। और मैं इन समस्याओं का सामना करने के लिए भाग गया।

जैसा था

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

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

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

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

इसलिए, हल की गई समस्या परीक्षण में गिर गई और 2 दिनों तक परीक्षण किया जा सकता है। फिर वह रिहा हो गई, यह एक और 4 दिनों के लिए जाँच की गई थी। ठेस में, कार्य एक सप्ताह में सबसे अच्छा निकला। कुछ लोगों ने इसे पसंद किया, कुछ को बदलना आवश्यक था। और बदलने के लिए सबसे महत्वपूर्ण चीज है प्रक्रियाएं।

समोच्च

पहली चीज जो हमने की थी, वह विभिन्न क्षेत्रों के विशेषज्ञों की टीमों के साथ एक विभाजन था। पिछली टीमों के विपरीत, परियोजना के अंत के बाद कंटूर टूट नहीं जाते हैं। वे अपने उत्तरदायित्व के क्षेत्र में नई परियोजनाएं और विचार उत्पन्न करते रहते हैं।

प्रत्येक सर्किट में परीक्षण के लिए 1 से 3 परीक्षक जिम्मेदार हैं। प्रत्येक जिम्मेदार सर्किट टेस्टर उत्पाद विकास के सभी चरणों में एक विचार से डीब्रीफिंग तक मौजूद है।

ड्यूटी पर

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

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

प्रलेखन

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

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

प्रत्येक प्रयोग को करते समय, हमारे पास एक चेकलिस्ट होती है, क्योंकि हम पहले से नहीं जानते हैं कि क्या प्रयोग सफल होगा।



एक चेकलिस्ट एक प्रयोग की सुविधाओं पर सकारात्मक जांच का एक सेट है। प्रयोग के कार्य के दौरान रिलीज़ परीक्षक हर रिलीज़ के साथ इसका उपयोग करता है। यह चेकलिस्ट भविष्य के स्वचालन कार्यों के लिए एक रिक्त हो सकती है यदि प्रयोग सफल होता है और हम इसे 100% उपयोगकर्ताओं के लिए रोल आउट करते हैं।

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

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



वह सब डॉक के लिए है।

हम कार्यों का परीक्षण कैसे करते हैं

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

जाँच कार्य में एक महत्वपूर्ण भूमिका ऑटोटेस्ट द्वारा निभाई जाती है। हम प्रत्येक कार्य के लिए कार्यात्मक ऑटोटेस्ट चलाते हैं जो हम कार्यान्वित करते हैं, क्रैश का विश्लेषण करते हैं और बग की रिपोर्ट करते हैं।



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



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

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

हम रिलीज़ की जाँच कैसे करते हैं

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

टेस्ट खुद से भी मर सकते हैं। इस मामले में, हम ऑटोटेस्ट रन से परीक्षण को बंद कर देते हैं और यदि आवश्यक हो तो इसे ठीक करने और मोक्स बनाने का कार्य शुरू करते हैं।

रिलीज़ में कार्यों के आधार पर, हम पूर्ण रिलीज़ टेस्ट किट का उपयोग कर सकते हैं, या हम मैन्युअल प्रतिगमन को पूरी तरह से मना कर सकते हैं। निर्णय रिलीज टेस्टर द्वारा किया जाता है।

यदि रिलीज़ में कई छोटे संपादन होते हैं, तो कार्य की जाँच स्थानीय स्तर पर की जाती है, और मैन्युअल प्रतिगमन को ऑटो परीक्षण रिपोर्ट के चेक से बदल दिया जाता है।

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

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



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

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



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

सर्वश्रेष्ठ के लिए प्रयास कर रहा है

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



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

सीडी का अगला चरण "ग्रीन घाव" की शुरूआत होगी। परीक्षक द्वारा चेक किए गए प्रत्येक टिकट के लिए, दोनों प्लेटफार्मों के लिए 2 प्रकार के परीक्षण लॉन्च किए जाएंगे: कार्यात्मक परीक्षण और स्क्रीन परीक्षण। सभी परीक्षणों के लिए मोकी की आवश्यकता होगी। यदि किसी एक प्लेटफ़ॉर्म के लिए परीक्षण विफल हो जाते हैं, तो कार्य को सत्यापित नहीं माना जाएगा। यदि परीक्षण क्रैश हो जाता है, तो आपको यह समझने की आवश्यकता होगी कि ऐसा क्यों हुआ। केवल गिरते परीक्षणों और सभी जाँचों के सफल समापन के अभाव में कार्य को ठेस के लिए भेजा जाएगा।

आपका ध्यान के लिए धन्यवाद। मुझे उम्मीद है कि हमारा अनुभव आपके लिए उपयोगी था, मैं टिप्पणियों में आपकी प्रतीक्षा कर रहा हूं।