तेजी से और कुशल सॉफ्टवेयर विकास आज अच्छी तरह से सम्मानित वर्कफ़्लोज़ के बिना अकल्पनीय है: प्रत्येक घटक स्थापना के समय विधानसभा में स्थानांतरित किया जाता है, उत्पाद निष्क्रिय नहीं खड़ा होता है। दो साल पहले, M.Video के साथ, हमने रिटेलर में विकास की प्रक्रिया में इस तरह के दृष्टिकोण की शुरुआत की और आज हम इसे विकसित करना जारी रखते हैं। उप योग क्या हैं? परिणाम पूरी तरह से भुगतान किया गया: कार्यान्वित परिवर्तनों के लिए धन्यवाद, 20-30% द्वारा रिलीज की गति को तेज करना संभव था। कुछ विवरण चाहिए? हमारे बैकस्टेज में वेलकम।

स्क्रम से कानबन तक

सबसे पहले, कार्यप्रणाली में बदलाव लागू किया गया था - स्क्रम से संक्रमण, यानी स्प्रिंट मॉडल, कानबन के लिए। पहले, विकास की प्रक्रिया इस तरह दिखती थी:



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

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



नतीजतन, हम सही, प्रतिगमन की शर्तों की निरंतर पारियों से छुटकारा पाने में कामयाब रहे
देरी नहीं हुई, रिलीज उम्मीदवार को समय पर भेज दिया गया।

सर्वव्यापी स्वचालन

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

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

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

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

M.Video के साथ, हमने शेष परिदृश्यों के 95% द्वारा ब्लॉकर्स के परीक्षण को स्वचालित किया - लगभग 50%। लगभग आधे स्वचालित क्यों नहीं हैं? इसके कई कारण हैं, और अलग-अलग। ऐसे परिदृश्य हैं जो स्वचालन के लिए प्राथमिकता नहीं हैं। जटिल एकीकरण मामले हैं, जिसके लिए तैयारी के लिए मैनुअल काम की आवश्यकता होती है, उदाहरण के लिए, बैंक को कॉल करना और ऋण आवेदन को रद्द करना, बिक्री विभाग से संपर्क करना और उत्पादक वातावरण में आदेशों को रद्द करना।
प्रतिगमन परीक्षणों के स्वचालन से उनकी अवधि कम हो गई। लेकिन हम मास्टर शाखा के साथ कमांड शाखाओं के प्रत्येक विलय के बाद ब्लॉकर्स के लिए आगे और स्वचालित धुआं परीक्षण गए।

परीक्षणों को स्वचालित करने के बाद, हमने अंततः मास्टर शाखा के साथ संघों को पूरा करने में देरी से छुटकारा पा लिया।

बचाव के लिए घेरकिन

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

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

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

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

हम वहीं नहीं रुके।

फ़ंक्शन ब्लॉक

मान लीजिए कि रिलीज़ 1 ऐसी कार्यक्षमता है जो पहले से ही साइट पर है। रिलीज़ 2 में, हम उपयोगकर्ता और व्यावसायिक परिदृश्यों में कुछ बदलाव करना चाहते थे, और परिणामस्वरूप, परीक्षणों का हिस्सा काम करना बंद कर दिया क्योंकि कार्यक्षमता बदल गई।

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

इसके लिए धन्यवाद, मास्टर शाखा के साथ संयोजन के बाद, डेवलपर्स न केवल ब्लॉकर्स के काम की जांच कर सकते हैं, बल्कि विषय क्षेत्र से संबंधित स्क्रिप्ट भी कर सकते हैं जो परिवर्तन प्रभावित करते हैं।

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

स्टैंड के साथ समस्या

स्वीकृति परीक्षण से पहले किसी के भी प्रदर्शन का परीक्षण करने के लिए उपयोग नहीं किया गया। उदाहरण के लिए, वे हमें कुछ परीक्षण बेंच देते हैं, हम कई घंटों के लिए उस पर प्रतिगमन परीक्षण चलाते हैं। वे गिरते हैं, समझते हैं, ठीक करते हैं, फिर से परीक्षण चलाते हैं। यानी हम डिबगिंग और बार-बार रन बनाने में समय गंवाते हैं।

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

इससे बहुत समय बचाने में मदद मिली है। दरअसल, स्वचालन से पहले, हमारे पास 14 परीक्षक थे, चेक बोझिल और लंबे थे, लगभग पूरे काम के लिए स्क्रिप्ट थे, जिसमें 150 चरण शामिल थे। और यहाँ आप परीक्षण कर रहे हैं, और कहीं-कहीं ३०-४०-११ वें पायदान पर आपको एहसास होता है कि स्टैंड काम नहीं कर रहा है। हम 14 लोगों द्वारा खोए हुए कार्य समय को गुणा करते हैं और भयभीत होते हैं। और ऑटोमेशन की शुरुआत और स्टैंड्स के परीक्षण के बाद, हमने परीक्षकों की संख्या को आधा करने और डाउनटाइम से छुटकारा पाने में कामयाबी हासिल की, जिससे मुख्य लेखाकार को बहुत खुशी मिली।

केक पर चेरी

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

सामान्य तौर पर, प्रक्रिया इस तरह दिखती है: उन्होंने एक घटना पाई, इसे काम पर ले गए, इसे पूरा किया, इसे परीक्षण के लिए सौंप दिया, इसका परीक्षण किया, और इसे बंद कर दिया।



हम समझते हैं कि दोष बंद हो गया है, समस्या हल हो गई है। और उन्होंने एक और स्थिति जोड़ी: "प्रतिगमन परीक्षण के लिए।" इसका मतलब यह है कि विश्लेषण के बाद, महत्वपूर्ण बग का पता लगाने वाले परिदृश्यों को 900 परिदृश्यों के प्रतिगमन सेट में जोड़ा जाता है। यदि वे वहां नहीं थे, या यदि उनके पास अपर्याप्त विस्तार था, तो हमारे पास उत्पादक या पायलट की स्थिति पर त्वरित प्रतिक्रिया है।



यही है, हम समझते हैं कि कोई समस्या है, और किसी कारण से हमने इसे ध्यान में नहीं रखा। और अब बग चेक स्क्रिप्ट जोड़ने से बहुत समय बचता है।

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

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

परिणाम

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

स्वचालन परिणाम:

• 4 दिनों तक (पिछले 10 के बजाय) प्रतिगमन परीक्षणों की अवधि कम कर दी;
• मैनुअल परीक्षण टीम में 50% की कमी हुई;
• 30-35 से 25 दिनों तक, बाजार की अवधि का समय कम हो गया था - उस समय से एक फीचर टीम के बैकलॉग में प्रवेश किया जब तक कि यह पायलट में प्रवेश नहीं कर गया।

टेस्ट ऑटोमेशन टीम, जेट इंफोसिस्टम्स