क्या डेवलपर्स को परीक्षण चरणों में शामिल होना चाहिए?

Question

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

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

अपने विचार साझा करने के लिए धन्यवाद।

(*) अस्पष्ट कारणों से, परीक्षकों की संख्या बढ़ाना आज की तरह कोई विकल्प नहीं है।

(बस उल्टा, यह नहीं होना चाहिए की नकल करने वाले प्रोग्रामर को डिजाइनिंग टेस्ट में परीक्षार्थियों की मदद करते हैं; जो परीक्षण की तैयारी के बारे में बात करते हैं और परीक्षण निष्पादन नहीं करते हैं, जहां हम डेवलपर्स के निहितार्थ से बचते हैं)

Comments

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

— 19

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

— लुडोएमसी

ठीक है, मैंने एक उत्तर को स्वीकार कर लिया, लेकिन कुछ अन्य उत्तरों को भी वोट दिया, जिन्होंने समस्या के अच्छे तर्क दिए। सभी को धन्यवाद।

— लुडोएमसी

Answer 1

आपके प्रश्न को बहुत शाब्दिक रूप से देखना ("में शामिल") मेरा एकमात्र उत्तर एक पूर्ण असमान है

हाँ

देवताओं को अपने कोड पर अंतिम रूप से कभी नहीं कहना चाहिए ।

लेकिन, देवों को अन्य देवताओं के काम का परीक्षण करने में शामिल होना चाहिए। यह दो काम करता है:

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

अंत में, आप अधिक से अधिक आंखों का उपयोग क्यों नहीं करेंगे? क्रंच समय के लिए अतिरिक्त क्यूए लोगों को बोर्ड पर लाने के लिए आप हायरिंग और ऑन-बोर्डिंग प्रक्रिया से गुजरने का जोखिम नहीं उठा सकते। तो, आप अपनी ज़रूरत की अतिरिक्त आँखें कहाँ पाते हैं? या क्या आप सभी के साथ क्यूए की समान संख्या के साथ क्रंच समय के माध्यम से प्राप्त करने की कोशिश करते हैं? भले ही देवता अपना 20% समय परीक्षण और 80% जो भी कीड़े आते हैं, उसे ठीक करते हैं, यह अभी भी ऐप पर आपकी तुलना में अधिक आँखें हैं। स्वचालित परीक्षण केवल आपको एक निश्चित स्तर का आश्वासन देता है और यह कभी भी 100% नहीं होगा।

http://haacked.com/archive/2010/12/20/not-really-interested-in-lean.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+haacked+%28you%27ve+been+HAACKED%29

Comments

+1 चूंकि डेवलपर्स को दूसरे के कोड को देखने में शामिल होना चाहिए

— गैरी रोवे

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

— लुडोएमसी

Answer 2

कुछ भी लेकिन यूनिट परीक्षण के लिए, बिल्कुल नहीं। डेवलपर्स सिर्फ ऐप के बारे में बहुत अधिक जानते हैं और यह कैसे "माना जाता है" कि वस्तुनिष्ठ परीक्षक हों।

Comments

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

— पेमदास

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

— गैरी रोवे

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

— पेमदास

Answer 3

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

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

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

Answer 4

वैसे परीक्षण के संदर्भ में, 3 प्रकार हैं।

ब्लैक बॉक्स, ग्रे बॉक्स और सफेद बॉक्स।

ब्लैक बॉक्स उपयोगकर्ताओं को उत्पाद का परीक्षण करने के लिए संदर्भित करता है, इस बात का ज्ञान नहीं है कि उत्पाद आंतरिक रूप से कैसे काम करता है।

ग्रे बॉक्स उन बिजली उपयोगकर्ताओं को संदर्भित करता है जिन्हें कंप्यूटर प्रोग्रामिंग पर ज्ञान है, लेकिन विकास टीम पर नहीं है। ये लोग परीक्षण करेंगे कि क्या उत्पाद में मेमोरी लीक, सिस्टम की आवश्यकता के मुद्दे और इतने पर हैं।

यहां मुख्य भाग है: कोड स्तर पर उत्पाद पर परीक्षण करने वाले डेवलपर्स को व्हाइट बॉक्स संदर्भित करता है। कहने का मतलब यह है कि वे यूनिट टेस्टिंग, डिबगिंग, ... आदि करते हैं।

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

Answer 5

UNIT TESTING सभी डेवलपर्स के लिए जरूरी है

आपके लाभ के लिए इसका उपयोग कैसे किया जा सकता है, इसकी जानकारी के लिए, यदि आप C ++ विकास में हैं, तो निम्न लिंक के माध्यम से पढ़ें:

• Google C ++ टेस्टिंग फ्रेमवर्क का एक त्वरित परिचय
• ओपन सोर्स C / C ++ यूनिट टेस्टिंग टूल, भाग 1: बूस्ट यूनिट टेस्ट फ्रेमवर्क जानने के लिए प्राप्त करें
• ओपन सोर्स C / C ++ यूनिट टेस्टिंग टूल्स, भाग 3: CppTest को जानें

यहां कोई क्यू लोग नहीं है जो इन मामलों को कर सकता है। बिल्कुल नहीं।

Comments

मैं सहमत हूं लेकिन मैं दूसरे तरीके से सवाल पूछ रहा था। क्या डेवलपर्स को परीक्षण (इकाई परीक्षण को छोड़कर) में शामिल होना चाहिए जहां आमतौर पर केवल क्यूए व्यक्ति शामिल होते हैं।

— लूडो परिषद

Answer 6

यह मानते हुए कि परियोजना में डेवलपर्स की एक महत्वपूर्ण संख्या है, तो हर तरह से डेवलपर्स के परीक्षण पर काम कर रहे हैं। एक चेतावनी यह होगी कि डेवलपर्स अपने कोड के लिए परीक्षण पर काम नहीं करते हैं (इसमें इकाई परीक्षण शामिल नहीं है)।

Comments

+1 डेवलपर्स अपने स्वयं के कोड का परीक्षण नहीं कर रहे हैं (या कम से कम अकेले नहीं)

— लूडोएमसी

Answer 7

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

Answer 8

तुम लिखो:

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

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