परीक्षक - सहायक भूमिका?

पूर्व USSR के देशों में, सहायक भूमिका के रूप में परीक्षक के प्रति एक निश्चित रवैया है:

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

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

वेतन पर बचत करते हैं

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

• अकुशल परीक्षकों को एक विस्तृत विश्लेषण के बिना बग मिलते हैं। ऐसी त्रुटियों को स्थानीय बनाना और सही करना मुश्किल है। उदाहरण के लिए, प्रति सप्ताह किए गए 50 त्रुटियों में से प्रत्येक के लिए, डेवलपर्स औसत 15 मिनट का एक अतिरिक्त विश्लेषण करते हुए खर्च करते हैं। असली असंगत छोटी चीजें! प्रति वर्ष सिर्फ 600 डेवलपर घंटे - या 3.5 व्यक्ति महीने !
• समय के साथ, जब आपका समर्थित कोड आकार में बढ़ता है, तो आपको यह सत्यापित करने के लिए नियमित प्रतिगमन परीक्षण की आवश्यकता होती है कि कुछ भी नहीं टूटा है। आपके छात्र परीक्षकों का उद्देश्यपूर्ण और विधिपूर्वक एक ही परीक्षण को जारी करने से लेकर जारी करने तक करते हैं, कभी-कभी त्रुटियां पाते हैं (हाय, एक कीटनाशक का प्रभाव !) जब कोई स्वचालन के विचार के साथ आता है (सबसे अधिक बार, आरएम), तो ये लोग लिखेंगे आपके लिए कॉपी-पेस्ट के साथ कई सौ स्क्रिप्ट - और फिर, मैन्युअल परीक्षण के बजाय, ऑटोटेस्ट प्रत्येक रिलीज़ को अपडेट करेगा। कुछ बिंदु पर, इस सभी खुशी को बनाए रखने के लिए, आपको अधिक परीक्षकों की आवश्यकता होगी: बहुत कुछ और बहुत कुछ के बीच । और बहुत कुछ हमेशा महंगा होता है।
• अंत में, परीक्षकों की बढ़ती संख्या के बावजूद, आप एक उत्पादक वातावरण में त्रुटियों का सामना करेंगे। उपयोगकर्ताओं के साथ शपथ लेना, विश्वास खोना, अपना समय बर्बाद करना। सामान्य तौर पर, आप अतिरिक्त संसाधन खर्च करना जारी रखेंगे ।

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

परीक्षकों को उत्पाद को जल्द ही एक्सेस करने की अनुमति नहीं दी जानी चाहिए।

"अभी हम परीक्षण के एक योग्य संस्करण लिखेंगे, और उन्हें केवल यह जांचना होगा कि सब कुछ ठीक है और छोटे से छोटे को ढूंढना शुरू करें!"
यहाँ, किसी कारण से, समस्याएं फिर से शुरू होती हैं:

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

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

परीक्षक उत्पाद की गुणवत्ता को प्रभावित नहीं कर सकते।

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

• अधिक सक्षम स्वचालन के लिए, उत्पाद को आसानी से समर्थित लोकेटरों की आवश्यकता है - pffff! "फिर से, परीक्षण पर अतिरिक्त समय बिताएं!", आरएम कहेंगे, और कार्य को स्थगित कर देंगे, जब तक कि वे कभी-कभी-कभी-जब-जब-तब-तब-तक-कुछ नहीं करते।
• परीक्षण कवरेज और इसके कमजोर क्षेत्रों का अधिक सटीक मूल्यांकन करने के लिए, हमें विस्तृत विघटित आवश्यकताओं की आवश्यकता है - pffff! "नौकरशाही को बढ़ावा देने के लिए पर्याप्त है, हमारे पास एक चुस्त है!"
• हमें उपयोगकर्ताओं को बेहतर ढंग से समझने और व्यावसायिक परिदृश्यों के विकास के स्तर पर लक्षित दर्शकों को आकर्षित करने, उपयोगिता का मूल्यांकन करने की आवश्यकता है - pfffff! "यह 2 सप्ताह के लिए रिलीज को स्थगित कर देगा, उपयोगकर्ता की समीक्षाओं के बाद इसे फिर से करना बेहतर होगा!"

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

और जितनी जल्दी आप गुणवत्ता और कुशल प्रक्रियाओं को सुनिश्चित करने में संसाधनों का निवेश करना शुरू करते हैं, उतनी ही, अंततः, आपने नई कार्यक्षमता विकसित करना छोड़ दिया है! कोई फर्क नहीं पड़ता कि यह कितना अप्रत्याशित हो सकता है।

निष्कर्ष

संक्षेप में:

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

यह अभी भी दुर्लभ है, लेकिन पूर्व-यूएसएसआर में समझदार गुणवत्ता आश्वासन प्रक्रियाएं होने लगती हैं। क्या आप बेहतर के लिए कुछ बदलने के लिए तैयार हैं?