क्या डेवलपर्स को यूनिट परीक्षणों के अलावा अन्य परीक्षणों के लिए जिम्मेदार होना चाहिए, यदि ऐसा है तो कौन सा सबसे आम हैं?

Question

मैं वर्तमान में एक बड़ी परियोजना पर काम कर रहा हूं, और मैंने JUnit और EasyMock का उपयोग बड़े पैमाने पर इकाई परीक्षण कार्यक्षमता के लिए किया है। मुझे अब दिलचस्पी है कि मुझे अन्य प्रकार के परीक्षण के बारे में क्या चिंता करनी चाहिए। एक डेवलपर के रूप में क्या कार्यात्मक, या प्रतिगमन परीक्षण जैसी चीजों के बारे में चिंता करना मेरी जिम्मेदारी है? मावेन / एंट / ग्रैडल जैसे उपकरणों में प्रयोग करने योग्य तरीके से इनको एकीकृत करने का एक अच्छा तरीका है? क्या ये एक परीक्षक या बीए के लिए बेहतर हैं? क्या अन्य उपयोगी प्रकार के परीक्षण हैं जो मुझे याद आ रहे हैं?

Comments

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

— हारून मैकाइवर

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

— नोनटापिर

एक अच्छा मानदंड यह है कि परीक्षण कैसे स्वचालित हैं। प्रोग्रामर कोड के साथ चीजों को स्वचालित करने में अच्छे हैं।

— rwong

Answer 1

दोष-मुक्त कोड देने का प्रयास करना आपकी ज़िम्मेदारी है। आपको उस कोड को लिखना, सहायता करना या सुनिश्चित करना चाहिए जो आपके द्वारा वितरित किए जा रहे कोड में आपको विश्वास दिलाने के लिए लिखा या निष्पादित किया गया हो।

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

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

नीचे पंक्ति: आपको उच्च गुणवत्ता कोड देने के लिए जिम्मेदार होना चाहिए। यदि इसका मतलब है कि आपको कुछ कार्यात्मक या प्रतिगमन परीक्षण लिखने की आवश्यकता है, तो इसे करें।

Comments

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

— जैकी

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

— हारून मैकाइवर

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

— जॉन आर। स्ट्रोहम

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

— जेसन सेब्रिंग

क्या हर कोई जो इस उत्तर के पहले वाक्य के साथ मुद्दा उठा रहा है, अगर ब्रायन ने इसे " दोष-मुक्त कोड पहुंचाना आपका लक्ष्य है" कहा तो यह खुशी से बढ़ जाएगा ?

— कार्सन 63000

Answer 2

यह आपकी मदद कर सकता है:

Q1 डेवलपर्स द्वारा लिखे गए हैं।

Q2 को डेवलपर्स द्वारा स्वचालित किया जाता है और व्यवसाय और / या परीक्षकों के सहयोग से लिखा जाता है।

Comments

डेवलपर्स अक्सर Q4 परीक्षण में भी शामिल होते हैं।

— नोनटापिर

लिंक की गई फ़ाइल अब नहीं मिल सकती है।

— डुआयन रिच्नोस्की

Answer 3

क्या अन्य उपयोगी प्रकार के परीक्षण हैं जो मुझे याद आ रहे हैं?

वहाँ स्वीकृति परीक्षण है जिसके लिए मैं BDD- शैली चौखटे की सिफारिश करूँगा जो कि Gherkin भाषा का उपयोग करते हैं : JBehave (Java), Cucumber (Ruby), Behat (PHP), आदि। इस प्रकार के परीक्षण में इकाई परीक्षणों पर कुछ फायदे हैं:

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

Answer 4

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

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

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

हम डेवलपर्स के बीच "क्रॉस फंक्शनल टेस्टिंग" भी करते थे, लेकिन इस तरह की टेस्टिंग "रिपीटेबल" नहीं है, इसलिए इसकी उपयोगिता बहुत सीमित है ...

Answer 5

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

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

लेकिन यह एक टीम का काम है, न केवल तुम्हारा।

Answer 6

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

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

Answer 7

वास्तविक दुनिया में आप ही उतने ही जिम्मेदार होते हैं, जितना कि आपकी टीम / बॉस आपके प्रति जवाबदेह होता है। यदि आप प्रत्येक नुक्कड़ और क्रैनी एज मामले को खोजने के लिए अंतहीन भुगतान कर रहे हैं या टालमटोल कर रहे हैं और अपने बॉस की (या बदतर मार्केटिंग की) व्यावसायिक तर्क कीड़े की व्याख्या के लिए कूद जाते हैं, तो हर तरह से, आप सभी के लिए जिम्मेदार हैं।

तो दूसरे शब्दों में, वह करें जो आपके द्वारा दिए गए दायरे के लिए आवश्यक है। कुछ सामान्य अर्थों में फेंकने के लिए एक अच्छा अतिरिक्त या दूसरों को उस उत्पाद का उपयोग करें जिसे आप उपयोग कर रहे हैं मामलों को ठीक करने के लिए उपयोग के मामलों और संभावित मुद्दों की समझ पाने के लिए लेकिन इसे "फिक्सिंग" से पहले अपनी टीम या बॉस तक पहुंचाएं। इसमें आपके चुनने के उपकरण शामिल हैं। आपके सभी प्रयास कुछ ऐसे होने चाहिए जो सभी के साथ हों।

यदि आपका प्रश्न उपयोगी बग ट्रैकिंग का है, तो मुझे संचार प्रणालियों के संदर्भ में बगज़िला, गूगल डॉक्स, ज़ेंडस्कैप या बेसकैंप पसंद है।

Answer 8

मुझे नहीं लगता कि यह पहले से ही कवर किया गया है - अगर मैंने इसे याद किया तो क्षमा करें।

एक समस्या डेवलपर्स समय का कुशल उपयोग है।

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

यह मामला होने के नाते, एक डेवलपर जो समय परीक्षण कर रहा है, लागत में खराब है: लाभ की शर्तें। वह डेवलपर अन्य चीजों को करने में अधिक उत्पादक होगा, और एक विशेषज्ञ परीक्षक परीक्षण करने के लिए अधिक उत्पादक होगा।

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

Answer 9

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

Comments

मुझे लगता है कि मैं जो पाने की कोशिश कर रहा हूं वह वही है जो प्रभावी माना जाता है "हथौड़ा चलाना"।

— जैकी

यह निश्चित रूप से व्यक्तिपरक है। मैं कहता हूं कि किसी भी प्रकार का परीक्षण आपकी परियोजना पर लागू होता है (सभी परीक्षण प्रकार सभी परियोजनाओं पर लागू नहीं होते हैं, निश्चित रूप से)। यहाँ एक सभ्य सूची है: softwaretestinghelp.com/types-of-software-testing । आप खुद क्या करते हैं और कोर्स के लिए क्या चुनते हैं, यह आपके खुद के समय, संसाधनों और क्षमता पर निर्भर करता है। उदाहरण के लिए, आप स्वीकृति परीक्षण करने में सक्षम नहीं हो सकते हैं क्योंकि कुछ नियम हैं जो केवल एक उपयोगकर्ता का पालन करना जानता था। संक्षेप में, आपके पास जो समय है, वह सब आप संभवतः कर सकते हैं।

— हॉनस वैगनर

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

— हॉनस वैगनर

Answer 10

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

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

प्रत्येक टीम के कम से कम एक सदस्य को दूसरों की योजना और कार्यान्वयन बैठकों में भी बैठना चाहिए।

Comments

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

— रॉबर्ट हार्वे

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

— मिशेल कैनन

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

— मिशेल तोप

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

— मिशेल कैनन