मैनुअल और स्वचालित परीक्षण का संयोजन क्या लाता है: व्रीक अनुभव

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

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

मानक प्रक्रिया

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

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

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

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

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

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

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

विकट मार्ग

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

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

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

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

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

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

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

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

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

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

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

मुख्य बात के बारे में संक्षेप में

सुविधा के लिए, मैं एक स्थान पर एक मैनुअल परीक्षक के लाभों को उजागर करूंगा, ताकि व्यक्तिगत रूप से या सभी को एक साथ उनके महत्व का एहसास करना आसान हो:

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

संक्षेप में देना

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

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

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