कैसे QA एक परियोजना पर परीक्षण स्वचालन का आयोजन करता है। एक व्यावहारिक तरीका है

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

पढ़ाई के लिए तैयार हो रही है

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

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

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

इसे इस तरह से तैयार किया गया है:


और इस तरह:


सभी को अपनी वास्तुकला के लिए एक विकल्प मिलेगा।

क्यूए में परीक्षण के सिद्धांतों को लगाना

सबसे पहले, कोई फर्क नहीं पड़ता कि कितना आलसी और असामान्य हो सकता है, सफेद-चमड़ी परीक्षण का मास्टर करें और "आंशिक रूप से डेवलपर" बनें।

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

दूसरे, डेवलपर्स द्वारा स्वयं लिखे गए ऑटोटैस्ट से निपटें।

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

तीसरा, साहस करें, डेवलपर्स के पुल अनुरोध की समीक्षा करें।

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

चौथा, और भी साहसी बनें और उत्पाद कोड में सीधे ऑटोटेस्ट लिखें।

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

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

पांचवां, UI अंत-टू-एंड ऑटोटेस्ट्स का एक सीमित छोटा सेट बनाएं जो एक ब्राउज़र में अंतिम उपयोगकर्ता की क्रियाओं की नकल करता है।

ये ऐसे परीक्षण होंगे जो केवल क्यूए टीम द्वारा समर्थित होंगे। उन्हें मूर्त रूप दिया जा सकता है

• सबसे लोकप्रिय, महत्वपूर्ण ग्राहक परिदृश्य
• तथ्य यह है कि मुख्य कोड में एकीकरण परीक्षणों में पूरी तरह से लागू करना संभव नहीं है, उदाहरण के लिए, तीसरे पक्ष की सेवाओं के साथ काम करना

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

इसका क्या आता है?

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

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

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

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

अंतिम विदाई

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

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