एक परीक्षक एक पेशे से अधिक है

परीक्षण के क्षेत्र में अपने काम के दौरान, मैंने इस क्षेत्र के बारे में अपनी विशेष राय विकसित की, एक जूनियर परीक्षक (जूनियर परीक्षक) की स्थिति से परीक्षण विभाग के प्रमुख (परीक्षण प्रबंधक) के लिए शुरू किया। और, सामान्य तौर पर, यह राय इस अद्भुत पेशे के लिए प्यार और प्रशंसा की हिस्सेदारी के साथ काफी महत्वपूर्ण है।

एक परिचय के रूप में

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



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



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



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

थीसिस नंबर 1: परीक्षक एक बंदर नहीं है

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



मेरी नौकरी की जिम्मेदारियों में शामिल हैं: एक परीक्षण डिजाइन, परीक्षण मामलों, परीक्षण रणनीतियों (अगर यह मेरे लिए सौंपा गया एक परियोजना था) को संकलित करना, बग की रिपोर्टिंग करना, प्रलेखन की जांच करना और परीक्षण प्रलेखन बनाना। यह मेरे लिए निश्चित रूप से एक मामला था, हालांकि यह कुछ आश्चर्यजनक था कि पश्चिमी सहयोगियों ने इन जिम्मेदारियों को साझा किया। बाजार में, यह पता चला कि CTE / UML (सबसे अच्छा) टेस्ट लीड / सीनियर टेस्टर / टेस्ट डिज़ाइनर का उपयोग करके डिज़ाइन किया जाना काफी सामान्य था। परीक्षण मामले (विभिन्न सीमा सत्यापन रणनीतियों, फ्रंट-एंड परीक्षण, लोड परीक्षण, बेंच मामले) - वरिष्ठ परीक्षक। और अंत में, "कलाकार" के निचले स्थान हैं - परीक्षक। कुछ कंपनियों और विभागों में, उनकी संख्या 20 या अधिक लोगों तक पहुँच सकती है! दूसरे शब्दों में, परियोजना के कर्मचारियों में बंदर, सबसे अच्छे रूप में, कंप्यूटर उपयोगकर्ता कौशल और कुछ प्रकार के उत्पाद शामिल थे।



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





परीक्षण स्वचालन की लागत तुरंत भुगतान नहीं करती है।



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

थीसिस # 2: परीक्षक एक इंजीनियरिंग पेशा है

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



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



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



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

थीसिस नंबर 3: अगर टीम वर्क नहीं है तो मेट्रिक्स बकवास हैं

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



व्यवहार में, इसका मतलब यह है कि विकसित परीक्षणों की संख्या पर विचार करना बेकार है (यह प्रगति का मीट्रिक है), परीक्षण टीम की प्रभावशीलता के एक संकेतक के रूप में पाए जाने वाले कीड़े (सबसे खराब स्थिति में), यहां तक ​​कि प्रतिगमन की दर, यहां तक ​​कि परियोजना पर सिंथेटिक मैट्रिक्स (महत्व और श्रम की कसौटी का उपयोग करके) का उल्लेख नहीं है। बेवकूफ लोगों के बारे में (लेकिन अभी भी KSLOC \ घंटे परीक्षण टीम के लिए उपयोग किया जाता है)। प्रोजेक्ट मैनेजर के लिए, यह प्रोजेक्ट KPI के रूप में एक अच्छा CPI / SPI मीट्रिक हो सकता है, जो परीक्षण प्रबंधक द्वारा इंगित और एकत्र किए गए सभी मैट्रिक्स पर आधारित हो सकता है। यह एक बल्कि सारगर्भित और उच्च-स्तरीय मूल्यांकन है, जो किए गए प्रयास और प्राप्त परिणाम पर निर्भर करता है। लेकिन बशर्ते कि टीमें एकल जीव के रूप में काम करें।



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



यहां हम परीक्षक और डेवलपर के बीच महत्वपूर्ण अंतर पर आते हैं, जो मेरे लेख में बहुत करीब और समान हैं। हालांकि, कार्य की शैली से, डेवलपर्स आमतौर पर या तो पूर्णतावादी या "विशेषताएं" होते हैं (जो कोड, कार्यक्षमता और एल्गोरिदम के लिए कोड करना पसंद करते हैं); परीक्षक या तो पेडेंट या ऑटोमेशन इंजीनियर हैं (ऑटोमेशन को ऑटोमेट करना चाहते हैं)। इसलिए, प्रोजेक्ट में, परीक्षक जानता है कि यह कैसे करना है, और डेवलपर जानता है कि कैसे।



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

№4: —

V- , .



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

थीसिस नंबर 5: परीक्षण कीवर्ड पर ठीक करने का स्थान नहीं है

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



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





(QA) .



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



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

निष्कर्ष के बजाय

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