⚛️ 🌄 😻 क्या ऑटोटेस्ट्स इलेक्ट्रिक बग्स के बारे में सोचते हैं 🧙🏾 🌑 👨‍🎨

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

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

इस लेख में मैंने कोशिश की:

परीक्षण प्रबंधन के "बच्चों के घावों" को रोशन करने के लिए, हर उस चीज को स्वचालित करने की मांग की जाती है जिसे पिन नहीं किया गया है,
बताएं कि परीक्षण स्वचालन परियोजना के बजट को उसके दायरे के विस्तृत विश्लेषण और उचित तैयारी के बिना कैसे लाभ दे सकता है,
प्रोजेक्ट ऑटोमेशन की तैयारी के लिए रोडमैप तैयार करें।

स्रोत

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

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

दरअसल, इन विचारों के साथ, मैं "स्ट्राइक -2019" पर एक प्रस्तुति देने गया और फिर इस पर आधारित यह पोस्ट लिखी।

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

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

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

एक छोटा सा विषयांतर। स्वचालन के तरीके

UI परीक्षण को स्वचालित करने के दो मुख्य तरीके हैं।

स्रोत

हाथ परीक्षकों द्वारा स्वचालन

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

बनावट तक पहुंचना

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

नीचे मैंने इन दृष्टिकोणों की विशेषताओं का वर्णन किया है, लेकिन मैं विशेष रूप से उन्हें "प्लसस" या "माइनस" के रूप में चिह्नित नहीं करता हूं - हर कोई खुद के लिए संकेत निर्धारित करेगा।

स्वचालन की विशेषताएं "अपने दम पर"

स्रोत

1) जब हम मैन्युअल परीक्षकों की मदद से स्वचालित करते हैं, तो हमें एक त्वरित प्रभाव मिलता है "देखो, यह परीक्षा एक दिन पहले हुई थी, अब मैं इसे रोबोट के साथ बदल सकता हूं, इसमें 2 दिन लगते हैं, लेकिन मेरी भागीदारी यहां नहीं है"। स्वाभाविक रूप से, यह योग्यता में सुधार करता है और विशेषज्ञों के क्षितिज को व्यापक बनाता है: वे कोड को समझना शुरू करते हैं। लेकिन व्यवसाय के लिए कोई स्पष्ट, ठोस परिणाम नहीं है। विकास पर कितने घंटे बिताए गए थे, और अगर अनुभव वाले व्यक्ति ने ऐसा किया तो कितना खर्च हो सकता है? कितने घंटे बचते हैं? परीक्षण मामले को कितनी बार लॉन्च किया जाएगा? कहाँ पे? कौन साथ दे? इसकी कीमत कितनी होती है? यह मेरे लिए बहुत अच्छा नहीं है, क्योंकि, दुर्भाग्य से, मैंने अभी तक ग्राहकों को नहीं देखा है जो इस प्रक्रिया के लिए अंतहीन रूप से पैसे देने को तैयार हैं। इसलिए, एक स्पष्ट, ठोस परिणाम मेरे लिए हमेशा महत्वपूर्ण है।

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

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

परियोजना के दृष्टिकोण की विशेषताएं

स्रोत

1) इस मामले में, हम पहले से ही परियोजना के बारे में बात कर रहे हैं। और परियोजना क्या है? ये संसाधन हैं, समय, पैसा। तदनुसार, इस परियोजना में होने वाली सभी बारीकियों को ध्यान में रखते हुए बजट की गणना की जा रही है। सभी जोखिमों की गणना की जाती है, सभी अतिरिक्त कार्यों की गणना की जाती है। और बजट की सहमति के बाद ही लॉन्च करने का निर्णय लिया जाता है।

2) इसके आधार पर, तैयारी का चरण तेज नहीं होने की संभावना है, क्योंकि किसी चीज के लिए बजट की गणना का निर्माण किया जाना चाहिए।

3) स्वाभाविक रूप से, बढ़ी हुई मांगें उन विशेषज्ञों पर रखी जाती हैं जो परियोजना में भाग लेंगे।

4) यहां मैं जटिल बुनियादी ढांचे के समाधान भी लिखूंगा, लेकिन बाद में इस पर और अधिक।

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

6) परियोजना दृष्टिकोण नियमितता, स्थिरता देता है, हालांकि, दूसरी ओर, इसका कार्यान्वयन पहले दृष्टिकोण के कार्यान्वयन की तुलना में धीमा हो सकता है।

7) खैर, रिपोर्टिंग। बहुत सारी रिपोर्टिंग। क्योंकि किसी भी बजट के लिए आपसे पूछा जाएगा। तदनुसार, आपको यह समझना चाहिए कि ऑटोटैस्ट्स कैसे काम करते हैं (खराब, अच्छा), क्या रुझान, क्या रुझान, क्या वृद्धि की आवश्यकता है, क्या सुधार किया जाना चाहिए। इसे रिपोर्टिंग द्वारा नियंत्रित किया जाता है।

एक उज्जवल भविष्य के लिए लंबी सड़क

डिस्क्लेमर: हम अभी बहुत स्मार्ट थे (वास्तव में नहीं)।

स्रोत

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

स्रोत

अलग-अलग टीम - अलग-अलग दृष्टिकोण।
कार्यात्मक में स्वचालन के कमजोर विसर्जन।
परीक्षण मामलों की गैर-इष्टतम संरचना।
फ्रेमवर्क का दस्तावेजीकरण।
संचार असुविधाए।
लाइसेंस की समय पर खरीद।

स्वचालन के विभिन्न दृष्टिकोण

स्रोत

कई बार अत्याचार

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

स्रोत

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

यह कहने का नहीं कि यह प्रयास एक विफलता थी, यह बस खुद को रेखांकित करता था और समाप्त हो गया। जब हमें एहसास हुआ कि हमें एक बजट की आवश्यकता है, हमें अतिरिक्त बलों की आवश्यकता है, हमें कौशल की आवश्यकता है, हमें एक और टीम संगठन की आवश्यकता है। हमने लगभग 100 मामलों को स्वचालित किया, देखा कि यह काम करता है, और बंद हो गया।

नंबर दो का प्रयास

स्रोत

कुछ भी नहीं एक काट सैंडविच की तरह beckons।

थोड़ी देर बाद, हम फिर से स्वचालन के विषय पर लौट आए।

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

"हम इसे स्वचालित करना चाहते हैं!"
- शायद हम इसके बारे में सोचेंगे।
- नहीं, हम कुछ भी सोचना नहीं चाहते हैं, हम इन ऑटोटेस्ट को चाहते हैं।

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

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

इसका परिणाम क्या है। हमने एक और टुकड़ा, लगभग 300 मामलों को स्वचालित किया, जिसके बाद परियोजना समाप्त हो गई, क्योंकि लॉन्च की कोई स्थिरता नहीं थी और इस बात की कोई समझ नहीं थी कि इसके साथ कैसे हो। और हम समझ गए कि यह कैसे नहीं करना है ... दूसरी बार।

नंबर तीन का प्रयास

स्रोत

तीसरे प्रयास के लिए, हम एक शर्मनाक डो की तरह एक पानी के छेद के पास पहुंचे।

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

रेक पहले से ही झूठ बोल रहा था और हमारा इंतजार कर रहा था।

कार्यात्मक में स्वचालन के कमजोर विसर्जन

स्रोत

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

और जब हमने कार्यात्मक में ऑटो-टेस्टर को विसर्जित करना शुरू किया, यह समझाने के लिए कि हम मामलों में वास्तव में क्या जांचते हैं, तो वे इन "बच्चों की" गलतियों को समझने लगे, उनसे कैसे बचें, उनके आसपास कैसे पहुंचें। हां, टाइपोस हैं, कुछ विसंगतियां हैं, लेकिन ऑटोटेस्ट गिरता नहीं है, यह बस उन्हें लॉग करता है।

गैर-इष्टतम परीक्षण केस संरचना

Source

यह शायद हमारा सबसे बड़ा सिरदर्द है। उसने सबसे अधिक समस्याएं दीं, सबसे अधिक समय खर्च किया, सबसे अधिक घंटे और पैसे हमने उन पर खो दिए। नतीजतन, अब हम इस तरह की समस्या को सबसे पहले हल करेंगे, अगर हम कुछ और स्वचालित करेंगे।

हमारी परियोजना काफी बड़ी है, कई दर्जन सूचना प्रणालियां इसमें घूम रही हैं, वे काम करने वाले समूहों द्वारा एकजुट हैं। और ऐसा लगता है कि मामले लिखने के मानक सभी के लिए समान हैं, लेकिन एक समूह में इस टुकड़े को "फ़ंक्शन" कहा जाता है, दूसरे में इसे "प्राधिकरण" कहा जाता है, और ऑटोटेस्टर "फ़ंक्शन" और "प्राधिकरण" दोनों को पढ़ता है, और एक स्तूप में गिर जाता है। यह सिर्फ एक उदाहरण है। वास्तव में, ऐसी सैकड़ों परिस्थितियाँ थीं। मुझे यह सब मानकीकृत करना था, मेरे बालों में कंघी करनी थी।

इस तरह की अस्पष्टताओं के अलावा आपके पास और क्या है? हमें परमाणु परीक्षण के मामले नहीं मिले। ये परीक्षण के मामले हैं, जिनमें से कुछ चरणों में अलग-अलग तरीके से प्रदर्शन किया जा सकता है। उदाहरण के लिए, स्थिति में, यह कहता है कि "आप इस तरह के एक प्राधिकरण के तहत और इस तरह के एक प्राधिकरण के तहत चरण 2 का प्रदर्शन कर सकते हैं", और चरण 3 में, उदाहरण के लिए, उपयोग किए गए प्राधिकरण के आधार पर, "या तो बटन" ए "या बटन" सी "दबाएं। एक मैनुअल परीक्षक की दृष्टि से, सब कुछ ठीक है। परीक्षक समझता है कि इसे कैसे पारित किया जाए, ऑटोटेस्टर यह नहीं समझता कि इसे कैसे पारित किया जाए। एक बुरे संस्करण में, वह खुद ही रास्ता चुन लेगा, एक अच्छे में, वह स्पष्टीकरण के साथ आएगा। हमने गैर-परमाणु परीक्षण मामलों को परिवर्तित करने में काफी समय बिताया।

फ्रेमवर्क प्रलेखन

Source

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

संचार असुविधाए

स्रोत

1. बातचीत के लिए नियमों का अभाव।

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

2. इंटरैक्शन के लिए विनियमों की उपस्थिति

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

यही है, पहले तो लड़कों को बस एक दूसरे के साथ संवाद करने का तरीका नहीं पता था, वे एक ही चैट रूम में थे, लेकिन वे सवाल पूछ सकते थे या नहीं, उन्हें नहीं पता था। और जब वे पहले से ही ऐसी परिस्थितियों में कुछ समय के लिए काम करते थे, तो उन्होंने अपने स्वयं के अनौपचारिक, बंद समुदायों को विकसित किया: हम "हैंड-गार्ड" हैं, हम ऑटोमेटर्स हैं। संवाद कैसे करें? यहां हमारे पास विनियमन है - विनियमन के अनुसार।

विशेष सॉफ्टवेयर लाइसेंस की समय पर खरीद

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

रोडमैप

Istonik

तदनुसार, अब हमारे पास रोडमैप है, इस तरह की परियोजनाओं को कैसे लॉन्च किया जाए, इसमें शामिल हैं, वास्तव में, चरणों के प्रत्येक चरण को कुछ बिंदुओं में विभाजित किया गया है।

प्रारंभिक अवस्था

स्रोत

हमें टीम लीड की जरूरत है

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

एक फ़ोकस समूह होना चाहिए

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

परीक्षण मामले आधार की स्थिति का आकलन

मैंने पहले ही ऊपर परीक्षण मामले के आधार की स्थिति के आकलन के बारे में बात की थी, यह भी बहुत प्रारंभिक चरण में किया जाता है।

हमें पता चलता है कि स्वचालन के अधीन क्या नहीं है

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

एक पायलट परियोजना का मूल्यांकन

हम प्रारंभिक चरण में पायलट प्रोजेक्ट का मूल्यांकन करते हैं (यह कितना खर्च होगा) और इसे सबसे कठिन (नोट) मामलों पर निष्पादित करता है।

पायलट

स्रोत

परीक्षण मामलों का सामान्यीकरण

एकत्र मामला पूल सामान्यीकरण के अधीन है। अस्पष्टताओं और अनावश्यक पूर्व शर्त को समाप्त कर दिया जाता है।

ढांचा तैयार करना

हम अपने ढांचे को लिखते हैं, मौजूदा एक को जोड़ते हैं या खरीदे गए किसी प्रकार का उपयोग करते हैं।

भूमिकारूप व्यवस्था

हम बुनियादी ढांचा समाधान तैयार कर रहे हैं।

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

उप-योग और समायोजन

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

पायलट को समेटना

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

मैंने पहले ही लिखा था कि ऐसा हो सकता है कि हम न जाएं। यही है, अगर, उदाहरण के लिए, पेबैक 18 साल है, और आपकी परियोजना की अवधि 5 है, तो आपको यह सोचना चाहिए कि आपको इसकी आवश्यकता क्यों है।

मंच का शुभारंभ

स्रोत

आइटम क्रमिक रूप से सूचीबद्ध हैं, लेकिन वास्तव में वे सभी समानांतर में किए जाने चाहिए।

हम टीम का चयन शुरू करते हैं।
हम लीड निर्धारित करते हैं।
चलो मामले के अध्ययन को प्राथमिकता दें।
हम परीक्षण मामलों को सामान्य करते हैं।
हम "बुनियादी ढांचे की कठिनाइयों को हल करते हैं।"
हम नियमों और निर्देशों को लिखते हैं, संचार स्थापित करते हैं, बाधाओं को खत्म करते हैं।
हम कई ऑटोटेस्ट के एक साथ काम के लिए रूपरेखा में सुधार करते हैं और चल रहे परीक्षणों के समूहों को समानांतर करते हैं।
हम एक रिपोर्टिंग और सांख्यिकी मॉड्यूल (एक बार और संचयी) बनाते हैं।
हम ऑटोटेस्ट लिखना शुरू करते हैं।

मुख्य मंच

स्रोत

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

एस्कॉर्ट चरण

स्रोत

एस्कॉर्ट चरण मुख्य चरण से थोड़ा अलग है। एक महत्वपूर्ण अंतर इसकी अवधि में है। इसके अलावा, इसमें नए ऑटोटेस्ट का बहुत कम प्रतिशत विकसित किया जा रहा है। हमारे अनुमानों के अनुसार, प्रति रिलीज़ 6-10%, अन्यथा यह मुख्य चरण के समान है।

इसका परिणाम क्या है?

हमने लगभग 1,500 एंड-टू-एंड मामलों को स्वचालित किया। सफल प्रक्षेपण की स्थिरता लगभग 92-95% पर कई रिलीज हुई है।

भर्ती की लागत लगभग 2.5 गुना कम हो गई। रन स्वयं 3-4 घंटों में होते हैं, यह रात में किया जाता है, ताकि सुबह में तैयार परिणाम हो सकें।

तकनीकी कार्यान्वयन का विवरण मेरे सहयोगियों द्वारा लेखों की एक श्रृंखला में उल्लिखित है:

यदि हम अब शुरू करते हैं, तो मेरे बारे में लिखी गई सभी बातों को ध्यान में रखते हुए, मुझे लगता है कि हम अपनी नसों, समय और बजट को बचाएंगे।

ध्यान देने के लिए आपको धन्यवाद। प्रश्न पूछें, हम चर्चा करेंगे।

स्रोत

और हम भी युवा परीक्षकों की हमारी टीम की प्रतीक्षा कर रहे हैं!

, , .

क्या ऑटोटेस्ट्स इलेक्ट्रिक बग्स के बारे में सोचते हैं

एक छोटा सा विषयांतर। स्वचालन के तरीके

हाथ परीक्षकों द्वारा स्वचालन

बनावट तक पहुंचना

स्वचालन की विशेषताएं "अपने दम पर"

परियोजना के दृष्टिकोण की विशेषताएं

एक उज्जवल भविष्य के लिए लंबी सड़क

स्वचालन के विभिन्न दृष्टिकोण

कई बार अत्याचार

नंबर दो का प्रयास

नंबर तीन का प्रयास

कार्यात्मक में स्वचालन के कमजोर विसर्जन

गैर-इष्टतम परीक्षण केस संरचना

फ्रेमवर्क प्रलेखन

संचार असुविधाए

विशेष सॉफ्टवेयर लाइसेंस की समय पर खरीद

रोडमैप

प्रारंभिक अवस्था

हमें टीम लीड की जरूरत है

एक फ़ोकस समूह होना चाहिए

परीक्षण मामले आधार की स्थिति का आकलन

हमें पता चलता है कि स्वचालन के अधीन क्या नहीं है

एक पायलट परियोजना का मूल्यांकन

पायलट

परीक्षण मामलों का सामान्यीकरण

ढांचा तैयार करना

भूमिकारूप व्यवस्था

उप-योग और समायोजन

पायलट को समेटना

मंच का शुभारंभ

मुख्य मंच

एस्कॉर्ट चरण

इसका परिणाम क्या है?

More articles: