मुझे कुछ सिस्टम एडमिन के बारे में पता चला और उनके अनुसार, डेवलपर्स की तुलना में किसी संगठन में परीक्षण करने वालों को प्राथमिकता नहीं दी जाती है। कोई शक नहीं सॉफ्टवेयर रिलीज परीक्षकों के बिना संभव नहीं हैं, लेकिन मैंने कभी भी परीक्षण के बारे में अपने हाथ नहीं रखे हैं, इसलिए इसके बारे में ज्यादा जानकारी नहीं है। कोई अपराध नहीं।
जवाबों:
मेरे अनुभव में, दुर्भाग्यवश, उन्हें अक्सर द्वितीय श्रेणी के कर्मचारियों की तरह व्यवहार किया जाता है और यहां तक कि प्रोग्रामर के लिए भी बुरा व्यवहार होता है।
यह कई चीजों से उपजा है:
जब परीक्षक अपना काम सही तरीके से कर रहे हैं, तो सभी के लिए आसान है लेकिन प्रोग्रामर यह भूल जाते हैं कि वे भी मौजूद हैं। एक नेटवर्क व्यवस्थापक की तरह, आप केवल उन्हें नोटिस करते हैं जब वे अपना काम नहीं कर रहे हैं, या उन्हें बुरी तरह से कर रहे हैं। इसलिए बाकी संगठन के दृष्टिकोण से, उन्हें केवल अपनी गलतियों के लिए याद किया जाता है।
यह गलती से उन लोगों के लिए प्रवेश-स्तर की नौकरी के रूप में देखा जाता है जो प्रोग्रामर बनने की ख्वाहिश रखते हैं, लेकिन उन नौकरियों के लिए अभी तक योग्य नहीं हैं। वास्तव में, एक कंपनी में मैंने काम किया था कि उन्हें क्यू एंड ए की नौकरी का खिताब पाने के लिए उनकी दलीलों के बावजूद जूनियर प्रोग्रामर की नौकरी का खिताब दिया गया था। यहां तक कि तथ्य यह है कि वे एक क्यूए विभाग में थे कि उस पर हिलने के लिए एचआर प्राप्त करने के लिए पर्याप्त नहीं था।
# 2 के कारण, यह माना जाता है कि परीक्षक सभी प्रवेश स्तर के लोग हैं, और उसी के अनुसार भुगतान किया जाना चाहिए।
किसी को भी आलोचना करना पसंद नहीं है, और यह रक्षात्मक प्रोग्रामर के लिए परीक्षकों को नापसंद करने के लिए बहुत आम है क्योंकि उनकी नौकरियों को पूरे दिन प्रोग्रामर गलतियों को इंगित करने की आवश्यकता होती है। एक प्रबंधक के रूप में, मैं लगातार प्रोग्रामर को याद दिलाने के लिए एक पीआर मिशन पर था कि क्यूए टीम उन्हें अच्छा दिखने के लिए थी, न कि उन्हें बाहर करने के लिए।
यह कम से कम शुरू में एक नौकरी लोगों को दुर्घटना और पसंद से नहीं, हो जाता है। मुझे लगता है कि सॉफ्टवेयर क्यू एंड ए के लिए तैयार लोगों में से किसी भी स्कूल में मुझे कोई भी डिग्री योजना याद नहीं है। वे मौजूद हैं, लेकिन आमतौर पर निचले-छोर व्यावसायिक स्कूलों में, जो केवल इस विचार में योगदान करते हैं कि वे कम कुशल पेशेवर हैं।
परीक्षण नौकरियों को अपतटीय भेजे जाने वाले प्रोग्रामिंग नौकरियों की तुलना में बहुत अधिक संभावना है। कम से कम प्रोग्रामर यह तर्क दे सकते हैं कि स्थानीय रूप से डिजाइन की जरूरतों को संप्रेषित करने के लिए यह अधिक कुशल है और यह जानना महत्वपूर्ण है कि कंपनी के प्रमुख ऐप कंपनी के अंदर कैसे काम करते हैं। हालाँकि, परीक्षण को संशोधित करना बहुत आसान है और इस प्रकार आउटसोर्स करना आसान है।
उपरोक्त सभी कारणों से, परीक्षक दीवार पर लेखन को देखते हैं और अन्य नौकरियों (जैसे प्रोग्रामिंग) में स्थानांतरित होते हैं, विशेष रूप से वास्तव में अच्छे हैं। इसका मतलब यह है कि अधिकांश परीक्षण नौकरियों में अधिक प्रवेश स्तर के लोगों के साथ काम करने की प्रवृत्ति होती है जो अभी तक इसे जला नहीं पाए हैं या अन्य चीजों पर चले गए हैं, जो दुर्भाग्य से उपरोक्त विचारों में से कई को मजबूत करता है।
यह कंपनी पर निर्भर करता है, लेकिन आमतौर पर। उन्हें अक्सर द्वितीय श्रेणी के नागरिकों के रूप में देखा जाता है, और कई कंपनियों में, परीक्षण को एक प्रवेश-स्तर की स्थिति के रूप में देखा जाता है, जहाँ से आप वास्तविक डेवलपर बनने के लिए आगे बढ़ते हैं।
यह, ज़ाहिर है, बकवास है। कुछ अच्छे परीक्षकों के साथ काम करने के बाद, मैं कह सकता हूं कि वे दोनों मूल्यवान और कठिन हैं। मन के साथ कोई ऐसा व्यक्ति जो रचनात्मक रूप से गैर-स्पष्ट कीड़े खोजने के लिए पर्याप्त है और पूरी तरह से काम करने के लिए पर्याप्त है।
एक अपवाद, हालांकि: मैंने कुछ Microsoft परीक्षण लोगों को जाना है, और मैंने सुना है कि परीक्षक प्रथम श्रेणी के नागरिक हैं।
मैंने एक बड़ी परियोजना पर एक वर्ष के लिए एक कार्यात्मक परीक्षक के रूप में काम किया है। लगभग 10 सदस्यों की प्रत्येक टीम में 2-3 परीक्षक थे। मुझे कहना होगा कि हमें डेवलपर्स के रूप में परियोजना के लिए समान रूप से महत्वपूर्ण माना गया था।
बग ढूंढना आसान नहीं है। सबसे पहले, परीक्षकों को यह समझना होगा कि कोड क्या करना है। इसका मतलब है कि आवश्यकताओं को पढ़ना और समझना। यहां कुंजी आवश्यकताओं को समझ रही है - अगर परीक्षक सकारात्मक परीक्षण मामलों को लिखने के तरीके को जानने के लिए आवश्यकताओं को अच्छी तरह से समझ नहीं सकते हैं, तो आपको चिंतित होना चाहिए। इसका मतलब यह है कि डेवलपर्स ने कुछ कोड लिखे हैं जो वह करते हैं जो उन्होंने ऐसा करने के लिए मान लिया है। क्या यह धारणा सही है? जब तक आप आवश्यकताओं को हल नहीं करते हैं, तब तक आप नहीं जानते हैं, और आप अपने दोषियों को उस दोष को खोजने के लिए धन्यवाद कर सकते हैं।
दूसरा, परीक्षकों को झूठे परीक्षण मामलों को लिखना पड़ता है, जो यह सुनिश्चित करता है कि कोड वह नहीं करता है जो वह करने वाला नहीं है। अंगूठे का एक उचित नियम यह है कि आप प्रत्येक सकारात्मक परीक्षण मामले के लिए 5-10 झूठे परीक्षण मामले लिखते हैं। इसका मतलब यह है कि आवश्यकताओं को आगे भी समझना, और अक्सर यहजानकारी, कम से कम हमारी परियोजना में, भ्रामक और अस्पष्ट है। (और आवश्यकताओं को इकट्ठा करने के लिए कम प्रयास के कारण यह नहीं था - हमारे पास अकेले हमारी टीम में 13,000 की तरह कुछ था।) फिर, डेवलपर्स ने अपनी मान्यताओं का उपयोग करते हुए अपना कोड लिखा होगा, या इससे भी बदतर, इस पर भी विचार नहीं किया। तो इन शर्तों के तहत कोड क्या करता है जो सामान्य नहीं हैं? जब तक आप इसका परीक्षण नहीं कर लेते, आपको पता नहीं चलता। शायद कार्यक्रम का जवाब नहीं; शायद यह दुर्घटनाग्रस्त हो जाए; शायद यह डेटा को नष्ट कर देता है; शायद यह उपयोगकर्ता को रूट उपयोगकर्ता के रूप में कमांड चलाने की अनुमति देता है। जो भी करता है, आप जानना चाहते हैं। अन्यथा आप खुद को एक दिन समाचार पत्र में निम्नलिखित शीर्षक पढ़ते हुए पा सकते हैं - बग इन [आपकी कंपनी का नाम] का फ्लैगशिप प्रोग्राम लीडर सीक्शंस 'क्रेडिट कार्ड नंबर्स।
इसलिए अपने परीक्षकों से अच्छा व्यवहार करें। उनके साथ अच्छा व्यवहार करें। आखिरकार, वे हैं जो आपके सॉफ़्टवेयर में बग को जड़ देते हैं और आपके और हमारे जीवन को आसान बनाते हैं।
अच्छे परीक्षक जो समस्याओं का कुशलता से विश्लेषण कर सकते हैं और सभ्य परीक्षण स्वचालन कर सकते हैं सोने में उनके वजन के बराबर हैं क्योंकि वहाँ बहुत सारे काउबॉय परीक्षक हैं (जब एक "परीक्षक" का साक्षात्कार करते समय वह वास्तव में हंसते हुए फट जाता है क्योंकि उसे पता चला था कि हम जानते थे कि वह बना रहा है मौके पर सामान को उसके सीवी पर छोड़ दिया जाता है)।
मेरी टीम में परीक्षक को एक समान माना जाता है - जिसमें जिम्मेदारी और वेतन शामिल है। यदि आप एक परीक्षक चाहते हैं जो पूरे दिन क्लिक करता है - तो उन्हें कहीं सस्ते में आउटसोर्स करें (हम भी ऐसा करते हैं)।
अन्य उत्तरों को पढ़ने के बाद अपडेट करें: बहुत सारे क्यूए पेशेवर हैं जो नौकरी से प्यार करते हैं। यदि आप किसी भी सम्मानित क्यूए पदों पर नहीं आए हैं, तो एक और परिप्रेक्ष्य देने के लिए, यहां एक उदाहरण है: अग्रणी ऑटोमेकर्स के लिए एंबेडेड ऐप / मोबाइल ऐप परीक्षण। वे यह सुनिश्चित करते हैं कि बाजार में किसी वाहन को जारी किए जाने से पहले व्यावसायिक आवश्यकताओं को पूरी तरह से पूरा किया जाता है और कोई उपयोगकर्ता धीमी या अनुत्तरदायी कार डैशबोर्ड का अनुभव नहीं करता है। वे प्रबंधकों और उच्च स्तर के प्रबंधन के साथ मिलकर काम करते हैं, और साथ ही डेवलपर्स जो क्यूए प्रक्रिया की योजना बनाने से शुरू करते हैं, डिजाइन सुविधा में सिमुलेटर पर हाथों पर परीक्षण करने के लिए रहते हैं। मैं उनके बारे में सोच नहीं सकता कि वे लो प्रोफाइल हैं, वे बड़ी जिम्मेदारियां और स्वामित्व संभालते हैं और वे सबसे अच्छे इंजीनियरों में से हैं।
अब मेरा पहले वाला जवाब, दूसरा पहलू:
मैंने देखा है कि इंजीनियरिंग स्नातकों को परीक्षण इकाइयों (संदर्भ: भारत, बड़ी सॉफ्टवेयर सेवा फर्मों, जहां सब कुछ 'व्यावसायिक आवश्यकताओं' से प्रेरित है) के लिए आवंटित होने से नफरत है, क्योंकि वे इसे एक गैर-तकनीकी कार्य वातावरण मानते हैं। उन्हें 'वेबपेज में सभी लिंक पर क्लिक करें और सत्यापित करें', गैर-तकनीकी धाराओं (विज्ञान, कला) से स्नातक के साथ काम करने के लिए मजबूर किया जाता है, जिसे वे अपमानजनक मानते हैं और ऐसा महसूस करते हैं कि उनके तकनीकी कौशल नहीं हैं। उपयोग किया। ये आवंटन विशुद्ध रूप से संगठन की आवश्यकताओं पर आधारित होते हैं, और एक फ्रेशर, ज्यादातर समय, अपने करियर पथ पर बातचीत करने की शक्ति नहीं रखता है। इसलिए अगर आप इतनी बड़ी आईटी कंपनी में नौकरी करने वाले हैं, तो आपको चेतावनी दी गई है। आप सही समय पर कंपनी से बाहर निकलने के अलावा, व्यावहारिक रूप से बहुत कुछ नहीं कर सकते।
जब तक स्वचालित परीक्षण, लोड / प्रदर्शन परीक्षण आदि सीखने के अवसर नहीं मिलते हैं, कैरियर एक हद तक स्थिर होता है। व्यक्तिगत रूप से मुझे पता है कि ऑनसाइट कार्य के लिए अवसर (= ऑफशोर प्रोग्रामर बिंदु से धन का भार) परीक्षण इकाई के लिए अधिक हैं किसी भी अन्य इकाई की तुलना में मेरा संगठन। वे सभी उद्योग ऊर्ध्वाधर के साथ एक भराव या गोंद के रूप में काम करते हैं, क्योंकि सभी डोमेन में परियोजनाओं में परीक्षण अपरिहार्य है।
यदि आप आश्वस्त हैं कि आप अपने करियर को उस तरह से चला सकते हैं जैसा आप चाहते हैं, तो परीक्षण कुछ भी कम-प्रोफ़ाइल नहीं है। 4-5 साल के अनुभव और थोड़े से भाग्य के साथ, आपको बहुत अच्छा प्रदर्शन मिल सकता है, कभी-कभी शीर्ष स्तर के व्यावसायिक उपयोगकर्ताओं के साथ बातचीत करना। आपके पास उस उद्योग / डोमेन की भी अच्छी समझ हो सकती है जिसमें आप काम कर रहे हैं (एक डेवलपर की तुलना में जो ज्यादातर सिस्टम के किसी न किसी हिस्से पर ध्यान केंद्रित करेगा)। इस बिंदु पर एक व्यावसायिक विश्लेषक किफ़ो भूमिका में भी स्विच करना चुन सकता है।
मैं उन कंपनियों को जानता हूं जहां क्यूए टीम रिलीज के लिए जिम्मेदार है। इसका मतलब है कि उनके पास गुणवत्ता की कमी के कारण रिलीज को अवरुद्ध करने की शक्ति है। यदि क्षेत्र में एक समस्या की सूचना दी जाती है, तो वे आग की पंक्ति में पहले होते हैं (फील्ड इंजीनियर के ठीक बाद)।
आमतौर पर उन्हें उच्च डोमेन ज्ञान होता है। वे उत्पाद की समग्र कार्यक्षमता को बेहतर तरीके से जानते हैं, जबकि डेवलपर्स अपने मॉड्यूल / सुविधाओं पर ध्यान केंद्रित करते हैं।
इसके अलावा, मैं क्यूए ऑर्गेस के बारे में जानता हूं, जहां उन्हें अपने परीक्षण उपकरण लिखने होंगे। पूरे सामान को स्वचालित करने का उल्लेख नहीं है। मैं एक डेवलपर हूं, और हमेशा क्यूए लोगों को महत्व दिया है जो मेरी विशेषताओं का परीक्षण करते हैं।
कम से कम मेरे संगठन में, क्यूए डेवलपर्स के साथ समान रूप से व्यवहार किया जाता है। मुझे लगता है कि यह डोमेन (दूरसंचार) के कारण है जहां प्रोटोकॉल और नेटवर्क आर्किटेक्चर ज्ञान प्रोग्रामिंग कौशल के साथ समान रूप से मूल्यवान है।
हाँ। इसे पसंद करें या इसे छोड़ दें वे समान रूप से महत्वपूर्ण हैं लेकिन हमेशा कम पसंद किए जाते हैं। हो सकता है क्योंकि उन्हें बदलना आसान है।