क्या प्रोग्रामर खराब परीक्षक हैं?


36

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

सॉफ्टवेयर पर जोएल - शीर्ष पांच (गलत) कारण आपके पास परीक्षक नहीं हैं (जोर मेरा)

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

और इस सवाल में , सबसे लोकप्रिय उत्तरों में से एक कहता है (फिर से, मेरा जोर):

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

तो सवाल यह है कि प्रोग्रामर परीक्षण में खराब हैं? इस निष्कर्ष का समर्थन करने के लिए क्या सबूत या तर्क हैं? क्या प्रोग्रामर केवल अपने स्वयं के कोड का परीक्षण करने में खराब हैं? क्या यह सुझाव देने के लिए कोई सबूत है कि प्रोग्रामर वास्तव में परीक्षण में अच्छे हैं ?

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


17
@jshowter प्रोग्रामर सबसे खराब होते हैं जब दूसरों के कोड का परीक्षण करते समय अपने स्वयं के कोड का परीक्षण करते हैं। परीक्षक (अच्छे परीक्षक) स्वयं अपने तरीके से प्रोग्रामर होते हैं (क्योंकि उन्हें प्रोग्रामिंग लॉजिक और इसकी कार्यक्षमता को समझने की आवश्यकता होती है) इस अपवाद के साथ कि वे बहुत अधिक कोड नहीं लिखते हैं। मेरा मानना ​​है कि यह मनोविज्ञान के साथ करने के लिए अधिक है क्योंकि मैं अपने काम में संदेह खोजने में हमेशा संकोच कर रहा हूं लेकिन बुरा हो सकता है।
Ubermensch

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

1
@jshowter यदि आप कठिन तथ्यों / अनुसंधान डेटा के बाद हैं, तो मुझे एक नहीं मिल सकता है। अधिकांश साहित्य एजाइल डेवलपमेंट से संबंधित हैं और ऐसा कोई भी नहीं मिला जो आपके विशेष मामले से मेल खाता हो। आप Google विद्वान या वायरस पर प्रयास कर सकते हैं।
Ubermensch

3
हम बुरे परीक्षक नहीं हैं! यह मेरे पीसी पर काम करता है! ;-)
जोरिस टिम्मरमन्स

2
@MadKeithV हा! यह मेरा JIRA (इश्यू ट्रैकर) अवतार है;)
yannis

जवाबों:


39

यह सवाल सिस्टम टेस्टिंग के बारे में विशेष रूप से पूछ रहा है , इसलिए मैं इस पूरे उत्तर का उल्लेख कर रहा हूं।

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

प्रोग्रामर परीक्षण में खराब क्यों हैं:

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

प्रोग्रामर परीक्षण में अच्छे क्यों हैं:

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

प्रोग्रामर खराब परीक्षक क्यों हैं:

  • प्रोग्रामर परीक्षकों की तुलना में अधिक महंगे हैं (अधिकांश मामलों में)।
  • मानसिकता मौलिक रूप से अलग है: "बिल्ड (वर्किंग) उत्पाद" बनाम "यह बात किसी भी (अज्ञात) कीड़े के साथ दरवाजे से बाहर नहीं जा रही है।"
  • परीक्षक आमतौर पर अधिक कुशल होंगे - यानी एक ही समय में अधिक परीक्षण करें।
  • प्रोग्रामर प्रोग्रामिंग में माहिर हैं। क्यूए पेशेवर परीक्षण में विशेषज्ञ हैं।

4
ध्यान दें कि प्रोग्रामर की तार्किक सोच एक अच्छा परीक्षक होने के लिए एक बाधा हो सकती है। आपने कितनी बार एक प्रोग्रामर को "लेकिन यह असंभव है" के साथ प्रतिक्रिया करते देखा है! जब एक बग के साथ सामना किया? केवल यह पता लगाने के लिए कि वे अपने तर्क में कुछ गंभीर चूक गए हैं जिसने बग को "असंभव" बना दिया है।
जोरिस टिम्मरमन्स

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

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

1
+1 के लिए "मानसिकता मौलिक रूप से अलग है"। संबंधित (लेकिन अलग) कौशल सेट के साथ ये सभी अलग-अलग भूमिकाएं हैं।
joshin4colours

3
@MadKeithV तार्किक सोच परीक्षण में महत्वपूर्ण है और इसलिए अनावश्यक परीक्षणों को समाप्त कर रहा है। क्या आप ब्लैक-बॉक्स बनाम व्हाइट-बॉक्स परीक्षण के बारे में सोच रहे हैं? में ब्लैक बॉक्स परीक्षण आप कार्यान्वयन के ज्ञान के बिना आवश्यकताओं से परीक्षण वसीयत। दोषपूर्ण मान्यताओं की जांच करने के लिए, गलत तर्क आदि, IMHO डेवलपर्स इस पर अच्छे हैं , बशर्ते कि वे कार्यान्वयन को नहीं जानते हों। विशेष रूप से अगर उन्होंने कोड लिखा है, और गलतियाँ की हैं, तो वे अनिवार्य रूप से परीक्षणों में एक ही गलती करने के लिए प्रवण हैं। सिस्टम परीक्षण ब्लैक बॉक्स परीक्षण होना चाहिए।
MarkJ

19

मुझे लगता है कि प्रोग्रामर अपने स्वयं के कोड का परीक्षण करने में खराब हैं ।

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


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

11

प्रोग्रामर निश्चित रूप से सिस्टम के कुछ हिस्सों का परीक्षण करने के लिए सही लोग हैं - उन जगहों पर वे एकमात्र ऐसे व्यक्ति हैं जो इसे प्रभावी ढंग से करने में सक्षम हो सकते हैं।

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

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

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


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

1

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

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

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

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


1

मेरे अनुभव से, हाँ, प्रोग्रामर खराब परीक्षक हैं। बहुत बार मैंने दूसरों को देखा है और खुद "हू, लेकिन मैंने जांच की कि इससे पहले कि मैं जाँच करूँ!" जब आपके सामने बग को पुन: पेश करने वाले परीक्षक द्वारा सामना किया जाता है।

क्यूं कर? खैर, मुझे यकीन नहीं है कि ऐसा क्यों है, लेकिन शायद यह इसलिए है क्योंकि हम सामान को काम करते हुए देखना चाहते हैं। या हम केवल इस या उस सुविधा के परीक्षण के साथ काम करना चाहते हैं।

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

सवाल के रूप में, परीक्षण का मतलब कुछ भी स्वचालित नहीं है, लेकिन वास्तव में कार्यक्रम का उपयोग करके परीक्षण करना है।


1

परीक्षण के कई स्तर हैं। डेवलपर्स द्वारा "निम्न स्तर" परीक्षण किया जा सकता है और किया जाना चाहिए। मुझे लगता है कि यूनिट टेस्टिग में।

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

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


0

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

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

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


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

0

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

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

मैन्युअल परीक्षण करने के लिए प्रोग्रामर का उपयोग करना सिर्फ मूर्खतापूर्ण है। मैनुअल परीक्षण अपने आप में पर्याप्त रूप से मूर्खतापूर्ण है; प्रोग्रामर बना यह बेहद मूर्खतापूर्ण है। यह महंगा है और सक्षम प्रोग्रामर को दूर करता है।


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

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

@ डैनी: टीडीडी के साथ, आपको एक असफल परीक्षा के जवाब में केवल शाखाएँ या विधियाँ लिखनी चाहिए, और आप केवल असफल परीक्षा पास बनाने के लिए आवश्यक कोड लिखते हैं।
केविन क्लाइन

मैं टीडीडी की कार्यप्रणाली जानता हूं, मैं सिर्फ निष्कर्ष से सहमत नहीं हूं।
डैनी व्रॉड

0

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

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

इसलिए परीक्षण करने वाले अन्य देव एक ही धारणा के कई कारण बनाते हैं क्योंकि वे भी कुछ निश्चित धारणाएँ बनाते हैं जैसे "अच्छी तरह से अगर वे X वाइस वाई का मतलब रखते हैं तो उनका और अधिक विस्तार होगा क्योंकि उत्तर देने से पहले बहुत सारे विवरण हैं। यह। लेकिन आवश्यकताओं के लेखक इस तरह से नहीं सोचते हैं। इसलिए कोई ऐसा व्यक्ति जो आवश्यकताओं को अधिक पसंद करता है लेखकों को डेवलपर मान्यताओं का परीक्षण करने की आवश्यकता होती है और जो कोई डेवलपर नहीं है वह सबसे अच्छा व्यक्ति है यहां तक ​​कि यह देखने के लिए कि कोई मुद्दा है।

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