क्या ऑटोमेशन मैनुअल टेस्टिंग की जगह लेगा?

नमस्कार, हेब्र!

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

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




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

स्वचालन के इतिहास के बारे में संक्षेप में

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

2010 में वापस, जब मैं सिर्फ आईटी की दुनिया में अपना पहला कदम रख रहा था, तब हर कोई सेलेनियम जैसे उपकरण को नहीं जानता था। उस समय, इसका पहला संस्करण उपयोग में था, जिसे सेलेनियम रिमोट कंट्रोल कहा जाता था।

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

मुझे अभी भी याद है कि हमारे बॉस ने उन्हें "चुटकुले" कहा था। यह देखते हुए कि हम कैसे बैठते हैं और इन परीक्षणों को लिखते हैं, उन्होंने कहा: फिर से, अपने चुटकुले लिखें? जैसे, मैंने इसकी जाँच नहीं की और इसे बहुत पहले अपने हाथों से जारी किया।

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

फिलहाल दोनों वेब और मोबाइल अनुप्रयोगों के स्वचालन के परीक्षण के लिए कई समाधान हैं।

अब यह सिर्फ चुटकुले नहीं रह गए हैं, अब एचआर से लेकर क्यूए स्थिति तक की औसत बातचीत इस तरह दिखती है (अतिशयोक्तिपूर्ण, बेशक):

- शुभ दोपहर। आपके फिर से शुरू के अनुसार, यह स्पष्ट नहीं है, क्या आप जानते हैं कि ऑटोटेस्ट कैसे लिखना है?

"नहीं, लेकिन मैं अच्छा हूँ ..."

- * पहले से ही लटका हुआ है *

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

बेशक, इस तरह के रुझानों के साथ, सवाल उठता है: क्या मैनुअल परीक्षण स्वचालन की जगह लेगा? और यह कब होगा?

डेवलपर्स की आंखों के माध्यम से ऑटोटेस्ट

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

मैं यह मान लेना चाहूंगा कि अंतर कोड में है। जैसे, चूंकि वे डेवलपर हैं, वे कोड को बेहतर लिखते हैं। इसलिए - उनके परीक्षण बेहतर हैं। लेकिन यह पूरी तरह सच नहीं है।

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

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

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

मैं तर्क देता हूं कि ऑटोटेस्ट लिखने की जिम्मेदारी से हटे 90% डेवलपर्स वहीं रुक जाएंगे। वे मामलों का हिस्सा नहीं बताएंगे क्योंकि वे उन्हें अनिवार्य रूप से कवर किए गए पहले से अलग नहीं मानते हैं। कुछ को ध्यान में नहीं रखा जाएगा। वैसे भी, "मैंने खुद प्रोडक्शन कोड लिखा था, वहां सब कुछ विश्वसनीय है और हमेशा के लिए।"

समतुल्यता वर्ग, सीमा मूल्य, नकारात्मक मामले - यह सब कहीं न कहीं किनारे बना हुआ है।

क्यूए इंजीनियर दृष्टिकोण

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

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

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

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

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

खैर, मैनुअल सत्यापन के बारे में क्या?

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

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

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

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

परिणाम

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

और यैंडेक्स के एक सहकर्मी ने उन लोगों के लिए एक ऑनलाइन पाठ्यक्रम विकसित किया जो मोबाइल परीक्षण के स्वचालन में खुद को विसर्जित करना चाहते हैं। जानकारी और लिंक मेरे प्रोफाइल पेज पर देखे जा सकते हैं। :)

आपका ध्यान के लिए धन्यवाद!