होम्योपैथिक परीक्षक या पुरानी भर्ती समस्याएं

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

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

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

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

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

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

1. परीक्षणकर्ताओं को परियोजना की वास्तुकला के बारे में कोई जानकारी नहीं है

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

साक्षात्कार के दौरान, उम्मीदवार आपत्ति कर सकते हैं, वे कहते हैं, हमें वास्तुकला के ज्ञान की आवश्यकता नहीं है। हम एक ब्लैक बॉक्स के साथ काम करते हैं। आंतरिक संरचना का ख्याल क्यों रखें?

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

मार्टिन फॉलर द्वारा पिरामिड संस्करण

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

ब्लैक बॉक्स परीक्षण का लाभ यह है कि परीक्षण कार्यान्वयन से स्वतंत्र हैं। वाह। लेकिन इस कृत्रिम प्रतिबंध को इनसाइड को समझने में हस्तक्षेप नहीं करना चाहिए। जब परीक्षक जानता है कि उत्पाद कैसे काम करता है:

• बग के साथ सामना, यह समस्या को स्थानीय बनाने में सक्षम है, और परिकल्पना का निर्माण नहीं करता है।
• एक नई सुविधा की चर्चा में, वह प्रतिक्रिया देने के लिए तैयार है, क्योंकि वह समझता है कि नई सुविधा मौजूदा घटकों के साथ कैसे एकीकृत करती है।

मालेविच ब्लैक बॉक्स के परीक्षण के लिए आंदोलन करता है

संभवतः ब्लैक बॉक्स के लिए एक ही प्यार दूसरी समस्या का कारण बना।

2. परीक्षक समझ नहीं पाते हैं कि ब्राउज़र के अंदर क्या हो रहा है

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

अधिकांश आवेदक HTTP कोड और HTTP अनुरोधों के प्रकार के उदाहरणों का नाम देते हैं। अगला सवाल अक्सर चकरा देने वाला होता है।

एक लॉगिन पेज है। उपयोगकर्ता प्राधिकरण डेटा के लिए सही डेटा दर्ज करता है और लॉगिन बटन पर क्लिक करता है। ब्राउज़र में इस समय क्या हो रहा है? साइट के साथ बाद की कार्रवाइयों को पुन: प्राधिकरण की आवश्यकता क्यों नहीं है?

यदि परीक्षक ने इन सवालों का जवाब नहीं दिया, तो उसकी क्षमता के बारे में संदेह पैदा हो जाएगा। इससे पता चलता है कि उम्मीदवार:

• UI के बिना किसी उत्पाद का परीक्षण नहीं किया जा सकता;
• ब्राउज़र में डेवलपर टूल का उपयोग करना नहीं जानता;
• मुझे बग (कारण या बैकएंड) के कारण का पता लगाने की आदत नहीं है।

तकनीकी विवरण के साथ वर्णन करने पर डेवलपर के लिए बग को ठीक करना आसान होगा।

3. परीक्षण कोड के प्रति लापरवाह रवैया

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

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

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

उम्मीदवारों को छोड़ने के लिए, हमने समय सीमा के बिना एक परीक्षण कार्य भेजा:

   Java           http://todomvc.com/examples/react/ 

सामान्य त्रुटियों की सूची

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

  
  

• नामकरण वर्गों, विधियों, चर के लिए सम्मेलनों का उल्लंघन
  कैमलकेस को अंडरस्कोर के साथ मिलाया गया। इसलिए वे अब इसे नहीं पहनते हैं। लाइनर और आईडीई संकेत बचाते हैं।

  
  

• हार्डकोड असिस्ट पथ

  
  

   String exePath = "Chrome_driver/chromedriver.exe"; System.setProperty("webdriver.chrome.driver", exePath); 

  
  

  क्लासिक "मेरी मशीन पर काम करता है।"

  
  

• भंडार के अंदर बाइनरी फ़ाइलों का भंडारण
  इस समस्या को हल करने के लिए git-lfs है।

  
  

• विधियों में निरंतरता का अभाव
  एक समाधान में, उम्मीदवार ने इस तरह "किए गए" को हटाने और चिह्नित करने के तरीकों का वर्णन किया:

  
  

   public void DeleteTask(String task) ... public void CompleteTask(int taskno) 

  
  

  पहली विधि में, कार्य पाठ संचरित होता है, दूसरे में, सूची में सूचकांक। ऐसे एपीआई का उपयोग करना दर्दनाक है।

  
  

• लॉगिंग के लिए System.out.println()
  यह सहायक जानकारी प्रदान नहीं करता है कि घटना किस वर्ग में हुई है।

  
  

• Thread.sleep का उपयोग Thread.sleep
  इस समस्या को हल करने के लिए एक प्रतीक्षित पुस्तकालय है। यह आवश्यक स्थिति की पूर्ति की अपेक्षा से प्रतिक्रिया जोड़ने में मदद करता है।

  
  

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

  
  

• बर्टिक एसिड का दुरुपयोग
  मुखर या मुखर पंक्ति में सब कुछ के लिए प्रयोग किया जाता है:

  
  

   assertTrue("One To Do item should be added", toDosPage.getToDoListCount(false) == 1); 

  
  

  परीक्षण क्रैश होने पर संदर्भ के लिए यहां दावे का उपयोग करना बेहतर है।

  
  

• परीक्षण चलाने के लिए कोई पैरामीटर नहीं है
  उदाहरण: परीक्षण के लिए साइट URL कोड में किसी का नाम नहीं लिया गया है।

  
  

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

निष्कर्ष

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

मुझे खुशी होगी कि अगर आपकी किराए की कंपनी में सब कुछ अलग है तो मैं गलत और खुश रहूंगा।

UPD 11/02/20 : वेबिनार में "एक परीक्षक का चित्र" मैं अंदर से पेशे को कैसे देखता हूं, इस पर अपनी राय साझा करता हूं।

• व्यवसाय को परीक्षकों की आवश्यकता क्यों है?
• टीम में परीक्षक की भूमिका
• मैनुअल वीएस स्वचालित परीक्षण
• पेशे के आकर्षक पहलू और अनुभव की कीमत
• आवश्यक कठिन / नरम कौशल
• नौसिखिए पेशेवरों के फिर से शुरू में त्रुटियां
• परीक्षण में Devops
• कैरियर में वृद्धि