क्या प्रोग्रामर्स को डिजाइनिंग टेस्ट में परीक्षकों की मदद करनी चाहिए?


17

प्रोग्रामर को डिजाइनिंग टेस्ट में परीक्षकों की कितनी मदद करनी चाहिए?

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

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

हर कोई नहीं जानता कि मैं इससे सहमत हूं (और मैं कुछ हद तक उनकी बातों को समझता हूं)। इस बारे में दूसरे क्या सोचते हैं? क्या इसकी चर्चा साहित्य में कहीं है?

जवाबों:


12

मैं सहमत हूँ। प्रोग्रामर परीक्षकों को कार्यात्मक चश्मे को समझने में मदद कर सकते हैं, अनुसंधान के लिए संसाधन ढूंढ सकते हैं लेकिन परीक्षण के दृष्टिकोण के बारे में अपने स्वयं के विचारों के साथ परीक्षकों के दिमाग को प्रदूषित नहीं करना चाहिए।


5
यह एक ऐसा विचित्र विचार है। मेरा मन पहले से ही बहुत प्रदूषित है - मैं एक परीक्षक हूं, परिभाषा के अनुसार मैं एक ऐसा नासमझ किस्म का व्यक्ति हूं जो हर चीज को देखता है। मैं एक ऐसे देव से कभी नहीं मिला जो अपने स्वयं के परीक्षण विचारों के बारे में बात करके मेरे मन को "दूषित" कर सकता है - परीक्षण के विचार मेरे अनुभव में अधिक परीक्षण विचारों को जन्म देते हैं। और जानते हुए भी कि अपने पूर्वाग्रहों और अंधा धब्बे होते हैं हो सकता है बहुत उपयोगी है।
वृष

1
-1, एक परीक्षक को किसी भी विचार के लिए खुला होना चाहिए कि क्या परीक्षण किया जा सकता है, पूरी तरह से स्वतंत्र यदि विचार एक डेवलपर, किसी और से आता है, या यदि यह उसका अपना विचार है। परीक्षकों और देवों के बीच ऐसे विषयों पर चर्चा नहीं करना IMHO बकवास है। "किसी व्यक्ति के दिमाग को प्रदूषित करने" का विचार उन लोगों पर एक विचार है जिन्हें मैं न तो साझा करता हूं और न ही समर्थन करता हूं।
डॉक ब्राउन

11

मुझे लगता है कि क्यूए के दायरे में शांति से सहवास करने के लिए डेवलपर्स और परीक्षकों के लिए जगह है। :)

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

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


6

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

मैं डेवलपर्स की मदद करने वाले परीक्षकों का भी बड़ा प्रशंसक हूं - मैंने डेवलपर्स के साथ विचार विचारों का मंथन किया है और अपने करियर में कई बार बग्स को ठीक करने के लिए उनके साथ जोड़ी (और बग्स का सुझाव दिया और फिक्स किए गए सुझाव दिए हैं), और मुझे नहीं लगता ' कभी टेस्टर cooties के साथ एक डेवलपर दागी है।

यदि आप इसे एक सहयोगी प्रयास के रूप में नहीं देखते हैं, तो आपके पास कोड को "दीवार पर फेंका गया" देव से परीक्षण तक होगा ... और आप कम गुणवत्ता के साथ समाप्त करेंगे। यही सच है मेरी दुनिया में, लेकिन (बेशक), ymmv।


यही स्वीकृत उत्तर होना चाहिए। इसके बजाय, ओपी ने एक जवाब चुना जो "देव और परीक्षकों" के संबंध के बारे में उनके पूर्वाग्रह का समर्थन करता है।
डॉक्टर ब्राउन

5

जिस तरह से मैं देख रहा हूं कि यह मेरे कोड का परीक्षण करने के लिए क्यूए का काम नहीं है। परीक्षक का काम यह सुनिश्चित करना है कि मेरा कोड उस कार्य के लिए सभी आवश्यकताओं को पूरा करता है।

जब मैं क्यूए के लिए कुछ पास करता हूं, तो मुझे यकीन है कि वे जानते हैं कि मैं जो काम कर रहा था, वह मेरे कोड की विशिष्टता नहीं थी। मैं क्यूए के लिए कभी भी कुछ भी पारित नहीं करता हूं जिसमें 'हड्डी के सिर' कीड़े हैं। वह मेरा समय बर्बाद करता है, उनका समय ... और बहुत ज्यादा हर किसी का समय।

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


5

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

जब तक आपका कोड कच्चा सीवेज नहीं है, तब तक कोई "प्रदूषण" नहीं था, और यह पूरी तरह से अलग कारण के लिए होगा।

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

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

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

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

मेरे अनुभव में, क्यूए और विकास के बीच सहयोग बेहतर गुणवत्ता वाले उत्पादों का उत्पादन करता है। मैं केवल एक ब्लैक बॉक्स हैंडऑफ़ करने की सलाह नहीं दूंगा।


3

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

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


3

मुझे परीक्षण योजनाओं की समीक्षा करना और अतिरिक्त परीक्षण मामलों का सुझाव देना पसंद है जो QA ने नहीं सोचा होगा। मुझे यकीन नहीं है कि यह कैसे "अपने पूर्वाग्रहों के साथ परीक्षकों को संक्रमित करेगा"।


2

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

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


0

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.