डेवलपर्स को अपने काम का परीक्षण करने दें या न करने दें


81

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

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


6
आपके प्रश्न से लगता है कि डेवलपर्स को कोई परीक्षण नहीं करना चाहिए। मैं यह सुनिश्चित करूंगा कि डेवलपर्स वास्तव में सॉफ़्टवेयर का परीक्षण करें ताकि यह सुनिश्चित हो सके कि यह (केवल संकलन नहीं) काम करता है ताकि परीक्षक समय बर्बाद न करें।
dnolan

4
@dnolan: मैं यहां अंतिम परीक्षण के बारे में बात कर रहा हूं, कोड उत्पादन में जाने से पहले परीक्षण। बेशक विकास के दौरान डेवलपर को परीक्षण करना चाहिए।
पयवी

क्योंकि यह इस प्रकार समाप्त होता है: devopsreactions.tumblr.com/post/88260308392/testing-my-own-code
Michal M

जवाबों:


103

जैसा कि अन्य (और स्वयं) ने उल्लेख किया है, डेवलपर्स को अपने स्वयं के कोड का परीक्षण करना चाहिए। हालांकि, उसके बाद, किसी भी उत्पाद को स्वतंत्र व्यक्ति (एस) (क्यूए विभाग और / या स्वयं ग्राहक) द्वारा भी परीक्षण किया जाना चाहिए।

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


3
मैं सहमत हूँ। घंटों, दिनों या हफ्तों के बाद भी एक समय सीमा के तहत "इस काम को करने" की कोशिश कर रहा है, उस मानसिकता को तोड़ने के लिए बहुत मुश्किल (शायद असंभव भी हो सकता है)। यदि आप अपने काम को अलग करने के लिए और एक अंतराल के बाद इसे वापस करने के लिए समय था, तो उद्देश्यपूर्ण रूप से परीक्षण करना संभव हो सकता है, लेकिन यह शायद ही संभव है।
पीटरअलेनवेब

ब्लैक हैट टेस्टर ...?
मतीन उलहाक

7
? यह कैसे काम करने के लिए "डेवलपर्स सामान्य रूप से के डेवलपर मानसिकता के साथ काम" के लिए +1 कैसे इस तोड़ने के लिए "" "। एक अच्छा परीक्षक के बारे में सोच रही है"
Wipqozn

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

127

डेवलपर जानता है कि उनका कोड कैसे काम करता है और इस ज्ञान के अनुसार उनके कोड का परीक्षण करने की आदत पड़ जाएगी।

डेवलपर को 'यह कैसे काम करना चाहिए' के ​​विपरीत 'कैसे काम करता है' की मानसिकता से खुद को दूर करना मुश्किल होगा।

इस वजह से किसी को प्रोग्राम या क्यूए या टेस्ट इंजीनियर्स का परीक्षण करने के लिए उच्च स्तर की निष्पक्षता के साथ प्राप्त करना बेहतर होता है


3
सहमत, एक डेवलपर उनके आवेदन को "परीक्षण" करने के लिए कम से कम प्रतिरोध का रास्ता अपनाएगा, किनारे के मामलों को शायद ही कभी देखा जाएगा।
dnolan

68
@dnolan, यह न केवल उनके कोड की "रक्षा" कर रहा है, यह भी कि कोडिंग के बारे में उन्होंने कुछ भी नहीं सोचा है, वे परीक्षण के लिए नहीं सोचेंगे।
स्टुपरयूजर

4
डेवलपर भी अपने कामों को निर्देशित करने के बजाय उसी पूर्वाग्रहों के साथ परीक्षण करते हैं। परीक्षकों को उनके साझा करने की संभावना कम है।
एपीग्रामग्राम

4
@ Jörg W Mittag वास्तव में नहीं। जिस तरह हर परीक्षार्थी हर टेस्ट केस के बारे में नहीं सोचेगा, न ही हर डेवलपर को। इसलिए जोड़ी प्रोग्रामिंग आदि और क्यूए टीमों को अलग करें। दो सिर हमेशा एक से बेहतर होते हैं।
स्टुपरयूजर

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

30

तोड़ने के लिए टेस्टर्स टेस्ट, सिंपल। इस तरह के पूर्वाग्रह को वास्तव में शो स्टॉपर्स का पता लगाने की आवश्यकता है।


15

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

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

डेवलपर्स आमतौर पर कीड़े पकड़ने के लिए विशाल छेद वाले जाल का उपयोग करते हैं। नतीजतन, छोटे कीड़े बच जाते हैं।


+1 के लिए "डेवलपर्स को अपने काम का परीक्षण करना चाहिए। यह एक निहित जिम्मेदारी है" - किसी अन्य व्यक्ति द्वारा आपके काम का परीक्षण करने की बात यह है कि आपके द्वारा किए गए कीड़े को पकड़ना है, आपके लिए अपना काम नहीं करना चाहिए (जो कुछ लोगों को लगता है)
Wipqozn

15

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


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

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

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

10

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

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

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

क्यूए टीम के साथ काम किए बिना और, मैं आपको बता सकता हूं कि मैं 100% उस काम की सराहना करता हूं जो वे करते हैं और कहेंगे कि वे सॉफ्टवेयर टीम का एक महत्वपूर्ण हिस्सा हैं। जब आपके पास एक क्यूए टीम होती है, तो यह आपके कोड को जारी करती है जो कि बहुत आसान, b / c आपको पता है कि यह पूरी तरह से परीक्षण किया गया है और इसका मतलब है कि आपको कम से कम 3am कॉल मिलेंगे।


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

के लिए +1 a testing teams knows what should have been written। यह बहुत सच है।
बजे एक CVn

8

डेवलपर्स को यूनिट को अपने स्वयं के कोड का परीक्षण करना चाहिए।

स्वतंत्र परीक्षक न केवल तोड़ने के लिए परीक्षण करते हैं, वे अस्थिर और अपरिभाषित मान्यताओं का परीक्षण करते हैं जिन्हें डेवलपर्स ने कोडिंग करते समय बनाया था।


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

7

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

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

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


5

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

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

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


3

एक डेवलपर के रूप में आप अपने स्वयं के कोड के लिए जिम्मेदार हैं, आपको इसका परीक्षण करना चाहिए। Does the feature work as expected?अगर जवाब हां है, तो आप कर रहे हैं।

आपको परीक्षण-मामले क्यों नहीं करने चाहिए?

  1. आप व्यक्तिपरक हैं , क्योंकि पाया गया कि कीड़े आपके (या आपके सहकर्मियों) द्वारा लिखे गए हैं।
  2. केस-टेस्ट चलाने के लिए आप कंपनी के लिए बहुत महंगे हैं । (मुझे उम्मीद है)।

2
यह विचार कि डेवलपर्स बहुत मूल्यवान हैं <डालने का कार्य आप यहां नहीं करना चाहते हैं> मेरे अनुभव में बल्कि संक्षारक हो सकते हैं।
जेरेमी

3

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

क्या आपकी परियोजना की योजना उपयोगकर्ता परीक्षण के लिए पूरी नहीं होती है? यदि आपको उपयोगकर्ता इसका परीक्षण करने के लिए मिलते हैं, तो आप इसे लागू करने से पहले कीड़े पकड़ सकते हैं जो मेरी दुनिया में कोई बुरी बात नहीं है।


3

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

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


हां, कोड का परीक्षण करने वाले अन्य डेवलपर्स अन्य संसाधनों की अनुपस्थिति में एक न्यूनतम / अस्थायी समाधान है। (यह मानते हुए कि आपके पास कई डेवलपर्स उपलब्ध हैं!)
ताओ

3

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

परीक्षण के लिए तकनीक और कौशल दोनों बहुत अलग हैं।

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


2

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


1
पूर्ण रूप से। कार्य कोड स्थिति के लिए सही कोड के समान नहीं है।
एचएलजीईएम

2

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


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

2

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

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

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

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

जैसा कि ऊपर बताया गया है ये बहुत महत्वपूर्ण हैं और अकेले डेवलपर द्वारा नहीं किया जा सकता है और ठीक काम करने के लिए आवेदन के लिए पूरी तरह से आवश्यक हैं। प्रबंधन कह सकता है कि यह एक रूढ़िवादी दृष्टिकोण है लेकिन यह बेहतर दृष्टिकोण है। हम ऊपर बताई गई कुछ बातें कर सकते हैं लेकिन पूरी तरह से नहीं टाल सकते।


2

ऊपर दी गई टिप्पणियाँ महान बिंदुओं को बढ़ाती हैं।

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

आवश्यकताएँ और प्रलेखन सही नहीं हैं, और अक्सर कार्यान्वयन एक डेवलपर द्वारा आवश्यकताओं की व्याख्या का एक परिणाम है।

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

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


2

एक प्रोग्रामर, जब परीक्षण करता है, तो "क्वांटिटी" नामक एक टेक्स्ट बॉक्स दिखाई देगा और "1" दर्ज करें। एक उच्च अनुभवी प्रोग्रामर इसके बाद "2" मान के साथ एक अनुवर्ती परीक्षण करेगा।

एक उपयोगकर्ता "क्वांटिटी" नामक एक पाठ बॉक्स देखेगा और "~ ~ इकसिंगों ROX !!! ~~" दर्ज करेगा। एक अनुभवी उपयोगकर्ता "-12 1/2" भी आज़माएगा।

उम्मीद है, एक परीक्षक प्रोग्रामर को सचेत करने के लिए कहीं न कहीं होगा कि उपयोगकर्ता इन चीजों को करते समय क्या अनुभव करने वाला है।


2

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

एक और कारण समय है। चरणों में निर्मित होने वाली बड़ी परियोजनाओं के लिए, विकास टीम स्टेज 1 का निर्माण करेगी। तब परीक्षणकर्ता इसका परीक्षण करेंगे, जबकि स्टेज 2 का निर्माण किया जाएगा और स्टेज 1 के दोष तय किए जाएंगे। यह सभी चरणों के लिए जाता है, इसलिए परीक्षण किया जा रहा चरण पिछले एक है जिसे बनाया गया था।


1

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

डेवलपर के लिए टेस्ट वैकल्पिक नहीं हैं। एक डेवलपर को अपने द्वारा लिखे गए कोड का परीक्षण करना होगा। वह और कैसे निश्चित हो सकता है, कि कार्य को सफलतापूर्वक पूरा किया गया है? आपको या तो किसी प्रकार के ऑटोमेट्स टेस्ट (unittests) लिखना होगा या चेकिंग का काम करना होगा "मशीन वही कर रही है जो मैं करना चाहता हूं" manuall (GUI का उपयोग करके, कमांड लाइन पर कमांड को कॉल करके या जो भी हो)।

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


3
ओपी यह नहीं पूछ रहा है कि डेवलपर्स को परीक्षण करना चाहिए या नहीं; ओपी पूछ रहा है कि क्या यह एक अच्छा विचार है कि डेवलपर केवल एक ही परीक्षण कर रहा है।
रेयान

1

यह कोड से अपरिचित किसी व्यक्ति द्वारा परीक्षण किया जाता है कि आप इसे पसंद करते हैं या नहीं। सवाल यह है कि क्या आप चाहते हैं कि कोई आपका ग्राहक हो।


1

बड़ा सवाल है। आपकी स्थिति में, परीक्षण के मामले -sometimes- मौजूद हैं और सॉफ़्टवेयर पर्याप्त जटिल लगता है कि उत्पाद पर गति के लिए नौसिखिया प्राप्त करना व्यावहारिक नहीं है। आप यह भी कहते हैं कि किया गया परीक्षण उत्पादन से पहले अंतिम परीक्षण है

इसके कारण डेवलपर के लिए अंतिम परीक्षण करना ठीक हो सकता है

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

कारण एक डेवलपर को परीक्षण नहीं करना चाहिए

  • और कुछ

सामान्य तौर पर, ऐसा लगता है कि आप वास्तविक समाधान पर हमला करने के सही रास्ते पर हैं - क्या SQA विशेषज्ञ परीक्षण मामले उत्पन्न करते हैं ...

नोट: मैं आम तौर पर डेवलपर्स को परीक्षण करने देने के पक्ष में हूं, लेकिन मुझे यकीन है कि पहली गोली बिंदु मौजूद है ...।


1

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

यह कहने की ज़रूरत नहीं है कि डेवलपर सीधे गलती पर है - उसका / उसका मस्तिष्क पूर्वाग्रह का उपयोग करेगा कि उन्होंने इसे लिखा, इस तथ्य को सुदृढ़ करने के लिए कि वे इसके अधिकार को मानते हैं, और केवल मूल चेक का प्रदर्शन करेंगे, जैसा कि एक डेवलपर ने विरोध किया था किसी और के कोड को देख रहा है, अधिक गहन जांच करेगा।

ऐसे हजारों उदाहरण हैं जहां संज्ञानात्मक पूर्वाग्रह को रोकने के लिए प्रक्रिया को लागू किया गया है, या आमतौर पर "द ह्यूमन फैक्टर" के रूप में जाना जाता है, जैसे कि हवाई यातायात नियंत्रण में कम्प्यूटरीकृत सिस्टम, एक ही हवाई क्षेत्र में एक ही स्थान पर दो अलग-अलग विमानों को रोकने के लिए। समय, चिकित्सा प्रक्रियाओं के लिए एक से अधिक डॉक्टरों को एक निदान देना होगा।

इसके बारे में समय है कि आईटी उद्योग एक अधिक पेशेवर रवैये की ओर बढ़ता है और अपने स्वयं के कोड के परीक्षण को रोकने के लिए प्रक्रियाओं में डालता है।


1
  • Eeveryone का परीक्षण करना चाहिए - Develpers परीक्षण कोड, QA'ers परीक्षण कार्यक्षमता, विपणन परीक्षण संदेश। इस तरह हर कोई परीक्षण के आसपास एक ही दर्शन और भाषा साझा करता है जो आधी लड़ाई है।

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

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

  • जब कभी भी उत्पादन में कुछ टूटता है तो दो काम करते हैं:

    1. "हम्म, क्या हमारे पास इसके लिए एक परीक्षण है " पहली टिप्पणी के रूप में।
    2. किसी भी फिक्स को समस्या के लिए परीक्षण में शामिल करें , पहले से ठीक करने के लिए पुन: उत्पन्न करें।

0

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


0

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


-1

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

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