परीक्षण स्वचालन प्रतिरोध

इस तथ्य के बावजूद कि यूनिट परीक्षण प्रौद्योगिकियां लगभग 30 वर्षों से हैं (केंट बेक ने 1989 में "सिंपल स्मॉलटाकल टेस्टिंग: विद पैटर्न") लेख लिखा था, सभी प्रोग्रामर इस तकनीक के मालिक नहीं हैं और सभी कंपनियों ने स्वचालित परीक्षण को अपनी कॉर्पोरेट संस्कृति का हिस्सा नहीं बनाया है। । स्वचालित परीक्षण के स्पष्ट लाभ के बावजूद, व्यवहार प्रतिरोध अभी भी काफी मजबूत है। जिसने भी स्वचालित परीक्षणों को लागू करने का प्रयास किया है, वह जानता है कि हमेशा कुछ कारण है कि ऐसा क्यों नहीं किया जा सकता है।

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

मैंने सभी आपत्तियों को विश्वसनीय प्रोग्रामिंग के पिरामिड में वर्गीकृत किया, जिसमें चार स्तर शामिल हैं:

• व्यावसायिक संस्कृति (उच्चतम स्तर, विश्वसनीय प्रोग्रामिंग का आधार) मानदंडों का एक समूह है, अलिखित नियम, कर्मचारी विश्वास जो उसे अपने काम में मार्गदर्शन करते हैं। उदाहरण के लिए: "रिपॉजिटरी के परीक्षण के लिए खुला कोड भेजना बुरा है", "कोड में मिली त्रुटियों के बारे में जानकारी देना एक शर्म की बात है"।
• प्रबंधन संगठन द्वारा अपनाई जाने वाली प्रक्रियाएं, नीतियां, नियम हैं, साथ ही नेताओं की इच्छा (निर्णय) भी है। उदाहरण के लिए: “प्रत्येक विकसित अनुप्रयोग फ़ंक्शन को एक समीक्षा कोड पास करना होगा। कोई अपवाद नहीं! ”
• तरीके वैज्ञानिक दृष्टिकोण हैं, किसी विशेष समस्या को हल करने के तरीके। उदाहरण के लिए: "यदि एप्लिकेशन के फ़ंक्शन का परीक्षण करना मुश्किल है, तो आपको डिपेंडेंसी सेंसर टेम्पलेट लागू करके एप्लिकेशन की परीक्षण क्षमता बढ़ाने की आवश्यकता है।"
• प्रौद्योगिकियां (निम्नतम स्तर) प्रोग्रामिंग भाषाएं, पुस्तकालय, रूपरेखा, उपकरण हैं। उदाहरण के लिए, JUnit, सेलेनियम, XCTest और इतने पर।

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

सांस्कृतिक आपत्तियाँ

“मेरे कार्यक्रम नहीं टूटते। मुझे परीक्षण की आवश्यकता नहीं है।

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

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

मेरे द्वारा आयोजित साक्षात्कारों में से एक में, निम्नलिखित संवाद हुआ:

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

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

कोड की गुणवत्ता के लिए जिम्मेदारी लेने की अनिच्छा, परीक्षण के लिए।

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

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

"त्रुटियों के बिना अभी लिखें"

जो लोग सॉफ़्टवेयर विकास कार्यों से बहुत परिचित नहीं हैं वे डेवलपर्स के प्रति नकारात्मक रवैया रख सकते हैं जो किसी प्रकार की गलतियों का उल्लेख करते हैं।

- चलो स्वत: परीक्षण के साथ आवेदन को कवर करते हैं।
- क्यों?
- यह सुनिश्चित करने के लिए कि सब कुछ सही ढंग से काम करता है और कोई त्रुटि नहीं है।
- क्या आप त्रुटियों के साथ लिखते हैं? क्या आपके पास कम योग्यता है? त्रुटियों के बिना तुरंत लिखें।
"हाँ, लेकिन हर कोई गलती करता है ..."
- लेकिन कंपनी XYZ ने एक दोस्त से कहा कि उनके पास शीर्ष प्रोग्रामर हैं जो त्रुटियों के बिना लिखते हैं!

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

प्रबंधन की आपत्तियां

“परीक्षणों के साथ, एक कार्यक्रम लिखना दो बार लंबा है। हम समयसीमा को पूरा नहीं करेंगे। ”

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

स्वचालित परीक्षणों के कई कार्य हैं:

1. जाँच हो रही है ।
   1.1। परीक्षण सत्यापित करते हैं कि परीक्षण ऑब्जेक्ट सही तरीके से काम कर रहा है।
   1.2। परीक्षण प्रोग्रामर के काम की गुणवत्ता की जांच करते हैं: क्या कार्य हल किया जाता है, चाहे रेजगारी के रूप में कोई दुष्प्रभाव हो।
2. निदान करना । नैदानिक ​​परीक्षण एक दोष की खोज करने के लिए समय को काफी कम कर सकते हैं। टेस्ट आपको कक्षा और विधि के लिए त्रुटि का स्थान निर्धारित करने की अनुमति देते हैं, और कभी-कभी कोड की रेखा तक भी।
3. स्वचालित । टेस्ट आपको डिबगिंग के लिए वांछित राज्य में परीक्षण ऑब्जेक्ट में जल्दी और आसानी से प्रवेश करने की अनुमति देते हैं।
4. दस्तावेजीकरण ।
   4.1। स्वीकृति परीक्षण उत्पाद के विकास के लिए ग्राहकों की आवश्यकताओं को रिकॉर्ड करते हैं।
   4.2। परीक्षण विकसित घटक का उपयोग करने के उदाहरण दिखाते हैं, जिससे किसी अन्य प्रोग्रामर द्वारा सिस्टम के काम का अध्ययन करने में लगने वाले समय को कम किया जा सकता है।

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

- लेकिन आखिरकार, लंबे समय तक परीक्षण लिखना! हम समय सीमा को पूरा नहीं करेंगे!
- क्या आपके पास त्रुटियां हैं जो आप बहुत लंबे समय से देख रहे हैं और ठीक कर रहे हैं?
- हां, कुछ हैं।
- सबसे कठिन मामला क्या है?
- हमने 80 घंटों के लिए एक त्रुटि खोजी।
- 80 घंटे प्रोग्रामर के काम के दो सप्ताह हैं। यदि आपने पूरे एक सप्ताह का परीक्षण स्वचालन बिताया है, तो यह आपके आवेदन के निदान और डिबगिंग में महीनों की बचत करेगा!

हमारे संगठन का दृष्टिकोण है: "परीक्षणों के साथ, एक कार्यक्रम लिखना दो बार तेज़ है!" और इस पोस्ट की चर्चा नहीं है। केवल गुणांक 2 पर चर्चा की गई है - कभी-कभी 3 और 4 होते हैं। और कुछ परियोजनाएं बिना सक्षम स्वचालित परीक्षण के पूरी नहीं हो सकती हैं (अभिभूत परियोजना देखें)।

"हमारे पास पहले से ही एक मैनुअल परीक्षण विभाग है, उन्हें परीक्षण करने दें।"

पहली नज़र में, परीक्षण और प्रोग्रामिंग में विशेषज्ञता का अलगाव तर्कसंगत लगता है।

लेकिन मैनुअल परीक्षण के नुकसानों पर नजर डालते हैं:

• यह बहुत महंगा है।
• इसमें बहुत लंबा समय लगता है। उदाहरण के लिए: मोबाइल एप्लिकेशन "ऑनलाइन सिनेमा" परीक्षक के लिए परीक्षण स्क्रिप्ट 40 घंटे बनाती है। और यह केवल एक मंच के लिए है! यदि आपको आईफोन, आईपैड, ऐप्पल टीवी, एंड्रॉइड, फायर टीवी पर एप्लिकेशन का परीक्षण करने की आवश्यकता है, तो आपको 40 × 6 = 240 घंटे काम करने का समय बिताने की जरूरत है, यह एक डेढ़ महीना है, जो छोटे विकास चक्रों के लिए अस्वीकार्य है।
• मैनुअल परीक्षण आम मानवीय त्रुटियों के अधीन है - यह एक उद्देश्य और सही परिणाम नहीं देता है।

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

1. CSV फ़ाइलों को आयात करने का कार्य।
2. पाठ दस्तावेजों के लिए पार्सर्स।
3. वित्तीय साधन।

विधि स्तर की आपत्तियाँ

स्वचालित परीक्षण विधियों की अज्ञानता।

शिक्षा के संकट के कारण विश्वविद्यालयों में कहीं भी स्वत: परीक्षण के विषय नहीं हैं। वाणिज्यिक आईटी स्कूलों में ऐसे बहुत कम पाठ्यक्रम हैं। और मौजूदा पाठ्यक्रम सतही और खराब गुणवत्ता के हैं। इसलिए, मैं अक्सर प्रोग्रामर्स के बीच एक स्तूप से मिलता था: वे नहीं जानते कि गैर-तुच्छ अनुप्रयोगों का परीक्षण कैसे करें (2 + 2 = 4 से अधिक कठिन)।

वास्तव में, परीक्षण का विज्ञान काफी व्यापक है। उदाहरण के लिए, प्रत्येक प्रोग्रामर तुरंत सवालों के जवाब नहीं देगा: ए) परीक्षण क्षमता क्या है? बी) नियंत्रणीयता और अवलोकन क्या है? ग) कौन से डिजाइन पैटर्न आवेदन की परीक्षण क्षमता में सुधार करते हैं? और इसी तरह।

प्रोग्रामर नहीं जानते कि वे क्या लिखते हैं, कैसा दिखता है, क्या फ़ंक्शन और इंटरफेस होंगे।

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

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

अनुचित कोड।

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

उदाहरण के लिए, एसएमएस का उपयोग करने वाले दो-कारक प्रमाणीकरण स्वचालित रूप से परीक्षण करना बहुत मुश्किल है, क्योंकि एसएमएस प्राप्त करने का कार्य स्वचालित परीक्षण वातावरण के दायरे से बाहर है। ऐसी व्यवस्था अनुपयुक्त है।

एक अनुपयुक्त प्रणाली के साथ सामना, प्रोग्रामर को छोड़ देता है और ऐसी प्रणाली का परीक्षण करने से बचता है।

परीक्षण डेटा की तैयारी।

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

समाधान:

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

परीक्षण सेवा।

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

समाधान:

• इंटरफ़ेस से परीक्षण के तर्क को विघटित करने के लिए "एडेप्टर" टेम्पलेट का उपयोग करना;
• उच्च-स्तरीय परीक्षणों (गेरकिन, ककड़ी, दिया-जब-तब) का उपयोग;
• "परीक्षण डेटा तैयारी" प्रतिरोध का समाधान देखें।

निष्कर्ष

इसमें कोई संदेह नहीं है कि सॉफ्टवेयर विश्वसनीय होना चाहिए: ग्राहकों की अपेक्षाओं से अधिक। विश्वसनीय सॉफ़्टवेयर के विकास में स्वचालित परीक्षण एकमात्र, लेकिन महत्वपूर्ण घटक नहीं हैं।

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

लेख केवल समस्याओं की रूपरेखा देता है और उन्हें हल करने के तरीकों पर मुश्किल से छूता है। सामान्य तौर पर, इन समस्याओं को हल करने की रणनीति मुझे इस तरह लगती है:

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

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

मैं आपके अभ्यास से उदाहरण के लिए आभारी रहूंगा कि आपके संगठन में स्वचालित परीक्षणों को लागू करना कितना आसान या कितना मुश्किल था। आपको किन समस्याओं का सामना करना पड़ा? आपने उन्हें कैसे हल किया?