सिद्धांत रूप में, टेस्ट ऑटोमेशन प्रोग्राम या उपकरण परीक्षकों के लिए चीजों को आसान बनाने, खाली समय और हमारे मूल्यांकन कवरेज के लिए हमें एक अतिरिक्त छूट कंबल प्रदान करने वाले हैं।
और इतने सारे संगठन एक स्केलेबल, मजबूत और अच्छे टेस्ट ऑटोमेशन इन्फ्रास्ट्रक्चर को लागू करने में विफल होते हैं जो निवेश किए गए संसाधनों को वापस कर देते हैं और उन्हें बचा सकते हैं। कुछ "थ्रो अवे" लिखित टेस्ट-ऑटोमेशन जॉब और अन्य एक स्थिर ऑटोमेशन सूट अर्जित करने के लिए अपने लक्ष्यों के साथ चल रहे संघर्ष में बने रहे।
वर्षों से मैंने देखा है कि कई कंपनियां अपने स्वचालन प्रयासों को निष्पादित करने की कोशिश कर रही हैं, मैंने देखा है कि लिखित परियोजनाओं को फेंक दिया गया है, ढांचे को बदल दिया गया है और प्रबंधकों को निकाल दिया गया है क्योंकि वे जो वादा किया गया है या लक्ष्य के रूप में निर्धारित करने में विफल रहे हैं।
विफलता के बहुत सारे कारण हैं, हालांकि ऑटोमेशन लंबी अवधि में सही मायने रखता है, हमें यह समझने की जरूरत है कि यह जितना लगता है उससे कहीं अधिक कठिन है।
आगे बढ़ने और अपनी परीक्षण स्वचालन परियोजना का निर्माण शुरू करने से पहले आपको कुछ कारणों के बारे में पता होना चाहिए:
विश्लेषण और प्रश्न पूछें: एक टेस्ट ऑटोमेशन नौकरी किसी भी अन्य एप्लिकेशन प्रोजेक्ट की तरह एक नौकरी है और इसे एक जैसा ही माना जाना चाहिए; आप एक सॉफ्टवेयर प्रोजेक्ट की योजना बनाने की प्रक्रिया कैसे करेंगे? जब आप अपने टेस्ट ऑटोमेशन प्रोजेक्ट को लागू करने के बारे में सोचते हैं तो इस विचार को आपको निर्देशित करने दें। आप नौकरी के लिए किसे चुनेंगे? उत्पादित उत्पाद का उपयोग कौन करेगा? नौकरी के लिए कौन सी भाषा या ढांचा सबसे उपयुक्त है? क्या आप चुनौतियों और उनके दिशा-निर्देशों को समझेंगे और एक नज़र डालेंगे? क्या आप एक ऐसी वास्तुकला की रचना करेंगे जिसके बारे में आप अपने बारे में कुछ नहीं जानते हैं, या क्या आप कुछ विचारों के साथ सलाह देने के लिए एक सलाहकार को बुलाएंगे?
ये सभी प्रश्न केवल इस हिमशैल का सिरा हैं कि आपको कोड की एक पंक्ति या परीक्षण की स्थिति लिखने से पहले खुद से क्या पूछना चाहिए।
अपर्याप्त कौशल: मैं आपसे एक प्रश्न पूछता हूँ। क्या आप बदतर या गैर-अनुभवी प्रोग्रामर को अनुमति देंगे, जो यह नहीं समझता है कि एक महान स्वच्छ खोज योग्य कोड कैसे बनाया जाए - अपने ऐप के डिज़ाइन को स्टाइल करें और इसे स्क्रैच से लिखें? मुझे लगता है कि जवाब नहीं है। तो इतनी सारी कंपनियां ऐसा क्यों सोचती हैं कि गुणवत्ता को किसी के द्वारा अनुभव और कौशल सेट के बिना मूल्यांकन स्वचालन बुनियादी ढांचे को लागू किया जा सकता है? यदि समर्पित कर्मचारियों के पास अनुभव और ज्ञान नहीं है और आप किसी ऐसे व्यक्ति को काम पर रखने की योजना नहीं बनाते हैं, तो आपको कोडलेस ऑटोमेशन टूल का उपयोग करने के बारे में सोचने की जरूरत है।
अवास्तविक अपेक्षाएं/दृष्टिकोण: मैं उस एक को दो भागों में बांट दूंगा। पहला परीक्षण-स्वचालन के आरओआई (निवेश की वापसी) की गलत समझ है और दूसरा घटक अवास्तविक अपेक्षाएं प्रति-समय ढांचा है। आपके द्वारा बनाई गई एक अच्छी नौकरी है, और आप मूल्य देने के लिए समय का निवेश किए बिना कुछ उम्मीद नहीं कर सकते हैं। मैंने एक क्यूए इंजीनियर से बात की है जिसने मुझे बताया कि उसने एक गुप्त बुनियादी ढांचे की रचना करने के लिए साप्ताहिक 6 घंटे प्राप्त किए। आपको उससे 6 घंटे क्या हासिल करने की उम्मीद करनी चाहिए?
इस काम को करने के लिए आपको पूछताछ करने की आवश्यकता है:
- आप अपने परीक्षण स्वचालन के साथ वास्तव में क्या लक्ष्य प्राप्त करना चाहते हैं?
- प्रयासों/समय के लिए एक शानदार मूल्य के रूप में क्या माना जाएगा?
- उपलब्धि के मानदंड क्या हैं?
- इसे पूरा करने के लिए आप कितना समय/पैसा खर्च करने के लिए तैयार हैं?
स्वचालन एक "लॉन्च और भूल जाओ" असाइनमेंट नहीं है। आप यह स्वीकार करना चाहते हैं कि यह एक सतत प्रक्रिया है जिसके लिए रखरखाव, सामूहिक प्रयास और उन्नति की आवश्यकता होती है।
मुझे यह स्वीकार करना होगा, कि दुख की बात है कि मैंने जो देखा है, कुछ कंपनियां एक क्यूए इंजीनियर को एक अंडरकवर नौकरी प्रदान करने को केवल एक कार्यकर्ता को संरक्षित करने या कुछ " मसाला " को अपनी साप्ताहिक दिनचर्या में डालने का एक तरीका मानती हैं। मुझे गलत मत समझो, मैं यह नहीं कह रहा हूं कि हमें अपने कार्यकर्ताओं का संरक्षण नहीं करना चाहिए या उन्हें सीखने और प्रगति के लिए समय प्रदान नहीं करना चाहिए, मैं केवल यह कह रहा हूं कि इसे उन अपेक्षाओं के साथ जोड़ा जाना चाहिए जो कार्यकर्ता में यथार्थवादी और पारदर्शिता हैं, वह स्वयं .
अपर्याप्त योजना: एक शानदार स्वचालन परियोजना एक उच्च स्तरीय योजना और योजना के साथ शुरू होनी चाहिए, जो एक व्यापक तकनीकी शैली में विकसित होगी। यहां तक कि "एक आकार सभी के लिए उपयुक्त" रणनीति भी आपकी सफलता के लिए विनाशकारी हो सकती है। एक कंपनी के लिए जो अच्छा काम करता है वह जरूरी नहीं दर्शाता है कि यह आपके लिए काम करेगा। यह घोषणा एक उपकरण पसंद के बारे में सच हो सकती है। जब भी आपको वास्तव में इस तकनीक का उपयोग करने की आवश्यकता नहीं होती है, तो यह चर्चा में आ जाता है। यह नोट करना बेहद जरूरी है। वहाँ बड़ी संख्या में खुले स्रोत और वाणिज्यिक उपकरण हैं जो उच्च मूल्य के पैसे प्रदान कर सकते हैं और यहां तक कि विकल्पों और लाभों / विकल्पों पर विचार किए बिना ये उपकरण पेश कर सकते हैं। एक उपकरण चुनें जो आपकी आवश्यकताओं को पूरा करेगा। यहां मेरे दो सेंट हैं - समाधान के लिए भुगतान करना बहुत बेहतर है, न कि बहुत समय बर्बाद करना (यह कार्यक्रम के लागत टैग की तुलना में बहुत अधिक मूल्यवान होगा)।
अब, जैसा कि हम अपने डिजाइन की योजना बनाने के तरीके पर चर्चा करना जारी रखते हैं, हमें अपनी संपूर्ण तकनीकी वास्तुकला और व्यावसायिक आवश्यकताओं के बारे में सोचना होगा। यहां कुछ ऐसे पहलू दिए गए हैं जिन पर आपको ध्यान देना चाहिए:
- कल्पना कीजिए कि नौकरी, मॉड्यूल, व्यवसाय प्रवाह क्या लोग जांचेंगे?
- प्रत्येक निष्पादन चरण के लिए नियोजित नीति क्या है? (पवित्रता, प्रतिगमन, सीआई/सीडी समर्पित पैकेज?)
- मुख्य साझा/सामान्य/दोहराए जाने वाले प्रवाह/कार्यक्षमता क्या हैं?
- हम एक संक्षिप्त स्टैंडअलोन आर्टिफ़ैक्ट के लिए प्रत्येक परीक्षण की योजना कैसे बनाते हैं? (सेटअप और टियरडाउन, उत्पन्न मूल्यांकन डेटा के बजाय बाहरी डेटा पर निर्भरता, प्रत्येक परीक्षण से पहले क्या चलाने की आवश्यकता है, सुइट क्लास?)
- यदि वे समवर्ती में चलते हैं तो हम एक मूल्यांकन को "तोड़ने" से कैसे रोक सकते हैं?
- हम एक अच्छा मापनीय, स्वच्छ और उपयुक्त वातावरण कैसे बना सकते हैं? (मॉक सर्वर, डेटाबेस केस, क्लीनअप स्क्रिप्ट, ब्राउज़र प्राथमिकताएं, ग्रिड/सर्वर कॉन्फ़िगरेशन, सेटअप और क्लीनअप, वर्चुअल परिवेश या डॉकटर कंटेनर)।
- यदि हम उपयोग करते हैं तो वास्तव में उपकरण क्या बनाते हैं?
- वास्तव में हमारी निर्भरता कैसे प्रबंधित की जा सकती है?
- हमारी परियोजना कहाँ संग्रहीत है?
- परियोजना पर कितने इंजीनियर काम कर रहे हैं और किस तरह से संस्करण प्रबंधन का प्रबंधन किया जाएगा?
- हमारे निर्माण करने के लिए कौन से सीआई उपकरण सर्वोत्तम हैं?
- क्या आप CI/CD वर्कफ़्लो लागू करेंगे?
- आप अपने परीक्षण और संसाधन कहां चलाएंगे जिनका उपयोग आप अपने स्वयं के निष्पादन मंच को डिजाइन करने के लिए कर सकते हैं? (क्या आपको क्लाउड समाधान परमिट खरीदने के लिए धन की आपूर्ति की गई है? क्या आपके पास अपना स्वयं का सेलेनियम सर्वर अवसंरचना स्थापित करने के लिए उपकरण या समर्थन है?)
- वास्तव में किस तरह के टेस्ट जल्द ही स्वचालित होंगे? (एपीआई, विजुअल कॉन्सेप्ट, सर्वर प्रोसेस, वेब/यूआई ऑटोमेशन, मोबाइल-एंड्रॉयड/आईओएस)।
- क्या कुछ बड़े डेटा संग्रह, लंबे प्रवाह, जटिल प्रक्रियाएं, एकीकरण हैं जो अतिरिक्त मूल्यांकन की मांग करेंगे?
- हमें जीयूआई के माध्यम से क्या परीक्षण करना चाहिए और जो एपीआई के माध्यम से जांचना अधिक सुरक्षित हो सकता है?
- वास्तव में हमें कौन से लॉग, रिपोर्टिंग तंत्र, हैंडलर और श्रोताओं को लागू करने की आवश्यकता होगी ताकि हमारे मूल कारण मूल्यांकन और डिबगिंग को सरल बनाया जा सके? (एक घंटे का ऑटोमेशन सूट क्या है यदि आप परिणाम को समझने के लिए एक दिन समर्पित करते हैं?)
- रन की आपूर्ति क्या मीट्रिक/रिपोर्ट/आउटपुट होनी चाहिए?
- वास्तव में हम वास्तव में क्या एकीकरण चाहते हैं? (रिपोर्टिंग कार्यक्रम, एएलएम उपकरण, बग ट्रैकर, मूल्यांकन प्रबंधन कार्यक्रम)।
- बुनियादी ढांचे की रचना कौन कर सकता है और परीक्षणों को लागू करने वाले कौन हैं? (क्या दोनों के बीच एक शाखा भी हो सकती है?)
- ऑटोमेशन इंजीनियर्स को बिजनेस फ्लो/टेस्ट केस/बिजनेस लॉजिक के साथ पेश करने के लिए कौन जिम्मेदार है जिसे स्वचालित माना जाता है?
- क्या भविष्य के लक्ष्य निर्धारित करने के लिए कोई POC (अवधारणा का प्रमाण) चरण परिभाषित हैं?
संक्षेप में बस यही कुछ प्रश्न हैं और आपको इसमें से क्या निकालना चाहिए वह है
एक उपयुक्त उपकरण विकल्प, बेहतर योजना/डिज़ाइन विफलता और सफलता के बीच अंतर पैदा करने की संभावना है।
सब कुछ स्वचालित करना : ध्यान देने योग्य एक महत्वपूर्ण बात यह है कि वह नहीं जो स्वचालित हो सकता है या होना चाहिए। कभी-कभी धारणा या गलत प्रबंधन निर्णय, हम परीक्षक के दिमाग में आने वाली हर चीज को स्वचालित करते हैं या परीक्षण मामलों को स्क्रिप्ट में आँख बंद करके परिवर्तित करते हैं। सबसे पहले, सभी मूल्यांकन स्वचालित करने के लिए उपयुक्त नहीं हैं। दूसरा, टेस्ट-केस स्वयं नौकरी के लिए स्वीकार्य नहीं हैं। यह स्वचालित परीक्षणों के एक अचूक समूह में समाप्त होता है जिसे रखना असंभव है और दुख की बात है कि अधिकांश अवसरों पर यह हमारे बहुत से लिखित कार्यों को चिह्नित करने वाला है। यदि आपकी कंपनी के पास ऑटोमेशन टीमों को बनाए रखने के लिए धन नहीं है, तो स्वचालित करने में कोई अतिरिक्त मूल्य नहीं है, जो कभी-कभी समान व्यावसायिक तर्क की जांच करने वाले हजारों परीक्षण उदाहरण हैं।
हमें इस बारे में एक स्पष्ट योजना तैयार करने की भी आवश्यकता होगी कि प्रत्येक स्वचालन निर्माण को बनाए रखने की क्या आवश्यकता है। हमारे प्रतिगमन में क्या शामिल है? हमारे विवेक के रूप में क्या वर्णित है? हमारे CI/CD पाइपलाइन में प्रवेश करने के लिए पर्याप्त सुरक्षित और विश्वसनीय क्या है?
टेस्ट-ऑटोमेशन को उचित मूल्य प्रदान करने के लिए ठोस योजना, समझ, प्रतिबद्धता और समर्पण की आवश्यकता होती है।
कौशल/उचित निर्देश का अभाव, गलत उपकरण चयन, अपर्याप्त संसाधन, उपयुक्त तैयारी की कमी, अवास्तविक प्रत्याशा, ये सभी एक परियोजना को विफल कर सकते हैं।
मुझे उम्मीद है कि इस रिपोर्ट का सकारात्मक प्रभाव पड़ेगा और आप में से कुछ को उत्पादक मानसिकता का पालन करने में मदद मिलेगी।