क्या एक प्रोग्रामर को आत्मनिर्भर होना चाहिए?

Question

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

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

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

ध्यान दें

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

अब तक के उत्कृष्ट जवाब, उन्हें साझा करने के लिए कुछ रखने या व्यक्तिगत अनुभव रखने के लिए आते रहें!

Comments

आह, पुराने पुराने "उपयोगकर्ता परीक्षक के रूप में" परिदृश्य। मैं इसे अच्छी तरह से जानता था।

— मैट एलेन

मुझे खेद है कि मुझे आपको यह बताना होगा लेकिन आपका प्रबंधन बेवकूफों से भरा है :(

— डॉ। हैनिबल लेक्टर

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

— कार्सन 63000

@ Carson6300, वर्तमान में हमारे पास 7 प्रोग्रामर हैं जो सभी ओवरवर्क किए गए हैं और ग्राफिक डिजाइनरों की समान मात्रा है। हमारे पास परियोजना प्रबंधक भी हैं , कम से कम शब्द के कुछ अर्थों में। जैसा कि मैंने कहा, ' .. कुछ प्रबंधन कर्तव्यों के कारण ..'; अधिकांश प्रबंधन अभी भी एक परियोजना प्रबंधक द्वारा किया जाता है। मुझे लगता है कि हम समर्पित परीक्षकों को न्यायोचित ठहराने के लिए पर्याप्त हैं।

— तातु उलमन ने

हो सकता है, आपको अपने प्रबंधन को निम्नलिखित लेख दिखाने की आवश्यकता हो: सॉफ्टवेयर कीड़े द्वारा संचालक की शर्त

— वैभव गर्ग

Answer 1

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

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

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

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

Comments

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

— जोनाथन

Answer 2

हाँ। यदि आपको करना है, तो आपको अपने कोड का परीक्षण करने में सक्षम होना चाहिए। (मैं यूनिट परीक्षणों की बात नहीं कर रहा हूं, लेकिन स्वीकृति परीक्षण और ऐसे।)

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

आपके पास कई अन्य प्रश्न हैं। मैं केवल एक उत्तर दूंगा:

क्या एक प्रोग्रामर को विनिर्देश को परिष्कृत करना चाहिए?

हाँ! आपको विनिर्देश को लागू करना होगा, इसलिए आपको यह सुनिश्चित करना होगा कि विनिर्देश वास्तव में लागू हो। इसके अलावा, एक प्रोग्रामर के रूप में - स्पष्ट सोच, सटीक और ऐसे में प्रशिक्षित - आप लोगों को यह पता लगाने में मदद कर सकते हैं कि वास्तव में क्या करने की आवश्यकता है, और अस्पष्ट या तार्किक रूप से त्रुटिपूर्ण आवश्यकताओं को पूरा किया।

Answer 3

वे जो कह रहे हैं और हकीकत है वह शायद दो अलग-अलग चीजें हैं। सबसे अधिक संभावना है कि तर्क यह है:
"मुझे एक परीक्षक का वेतन क्यों देना पड़ता है जब मैं सिर्फ प्रोग्रामर को दोहरी ड्यूटी कर सकता हूं?"

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

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

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

Comments

यदि आप वेतनभोगी हैं और आपके पास काम करने के बारे में कोई बाध्यता नहीं है, तो आपको नौकरी छोड़ने के लिए अधिक भुगतान नहीं करना पड़ेगा।

— ग्लेनट्रॉन

अच्छाई का धन्यवाद कि अनिवार्य अवैतनिक ओवरटाइम हर जगह कानून नहीं है।

— स्टीवन एवर्स

Answer 4

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

काफी उचित।

क्या इस तरह के कार्यों की जिम्मेदारी मेरी होनी चाहिए?

यह तय करने के लिए अंततः आपके प्रबंधन पर निर्भर है।

मैं एक प्रोग्रामर के रूप में खुद को सख्ती से देखता हूं और कुछ नहीं।

शायद तब आप गलत काम में हैं। बहुत सारे लोगों को अतिरिक्त जिम्मेदारी दी जा रही है।

और अगर ये मेरी जिम्मेदारी हैं, तो किस हद तक?

अगर प्रबंधन ऐसा कहता है, तो हाँ।

जब एक परियोजना इतनी बड़ी है कि उसे परीक्षकों की आवश्यकता है?

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

समर्पित परीक्षक होने में निश्चित फायदे हैं, लेकिन अतिरिक्त स्टाफ को नियोजित करने की लागत के साथ-साथ डाउनसाइड भी हैं।

एक प्रोग्रामर को विनिर्देश को परिष्कृत करना चाहिए,

यदि आवश्यक हो, तो हाँ। वास्तव में, यदि विनिर्देश को परिष्कृत करने की आवश्यकता है और इस पर कोई और काम नहीं कर रहा है, तो ऐसा करने में विफलता परियोजना के विफल होने की संभावना है।

परियोजना के प्रबंधन के बारे में चिंता

यदि आवश्यक हो, तो हाँ।

या यहां तक ​​कि ग्राहक सहायता प्रदान करते हैं?

यदि आवश्यक हो, तो हाँ।

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

Comments

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

— jmoreno

Answer 5

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

1. वे अत्यधिक कुशल हैं, और प्रोग्रामर के पास अलग-अलग कौशल हैं।
   1. उनके पास बहुत अनुभव और ज्ञान है कि क्यूए परीक्षण कैसे करें, और यह कैसे सत्यापित करें कि जो कोड बनाया गया है वह वास्तव में उपयोगकर्ता की अपेक्षा और उपयोगकर्ताओं के वास्तविक व्यवहार दोनों से मेल खाता है।
   2. उन्होंने कई बगों का अनुभव किया है, और उन स्थितियों के बारे में सोचकर बहुत अच्छा है जो सॉफ्टवेयर को तोड़ सकते हैं।
   3. वे निंदक और व्यवस्थित होते हैं। मैंने देखा है कि प्रोग्रामर अक्सर अधिक आशावादी होते हैं।
2. वे प्रयोज्य पर मूल्यवान प्रारंभिक प्रतिक्रिया प्रदान करते हैं। उदाहरण के लिए, हाल ही में REST API बनाते समय, जिन क्षेत्रों को QA परीक्षक आसानी से समझ नहीं पाए, वे उन क्षेत्रों का एक अच्छा संकेत थे जिनसे उपयोगकर्ता भी नाखुश होगा।
3. वे वास्तविक वातावरण पर परीक्षण करते हैं, वास्तव में वास्तविक हार्डवेयर, ओएस, आदि के कई कॉन्फ़िगरेशन।
4. वे जानते हैं कि बड़े पैमाने पर यथार्थवादी, परीक्षण बेड का निर्माण और प्रदर्शन, भार और तनाव परीक्षण कैसे करना है
5. वे खराब रिलीज को बाहर निकलने से रोकने पर केंद्रित हैं। प्रोग्रामर कोड जारी करने पर ध्यान केंद्रित करते हैं। इसकी तरह, एक प्रोग्रामर डिफ़ॉल्ट रूप से कोड जारी करेगा, लेकिन एक क्यूए परीक्षक को इसे जारी करने के लिए एक कारण की आवश्यकता होगी (यह काम करने के लिए दिखाया गया है!)

Answer 6

"अगर हमारे पास परीक्षक थे, तो आप अपने स्वयं के कोड का परीक्षण नहीं करेंगे"

" अगर आपकी कार में सीट-बेल्ट होता तो आप हर समय दुर्घटनाग्रस्त होते! "

क्या इस तरह के कार्यों की जिम्मेदारी मेरी होनी चाहिए? [...] और अगर ये मेरी जिम्मेदारी हैं, तो किस हद तक?

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

जब एक परियोजना इतनी बड़ी है कि उसे परीक्षकों की आवश्यकता है?

यह (काफी) एक सही सवाल पूछने के लिए नहीं है। आप यह पूछना बेहतर है कि "कंपनी के उत्पाद / छवि की गुणवत्ता इतनी महत्वपूर्ण है कि इसके लिए परीक्षकों की आवश्यकता है?"

एक प्रोग्रामर को विनिर्देश को परिष्कृत करना चाहिए, [...]

हाँ बिलकुल। ज्यादातर बार, डेवलपर / कार्यान्वयनकर्ता को क्या चाहिए और क्लाइंट क्या प्रदान करता है, इसके बीच एक बड़ी विसंगति है।

कई बार यह आपके ऊपर होता है कि आप ग्रे / अनिर्दिष्ट क्षेत्रों का पता लगाएं और सही सवाल पूछें, तकनीकी रूप से असंभव या विरोधाभासी आवश्यकताओं को नोटिस करने और इंगित करने के लिए और इतने पर (विशेषकर यदि आप केवल डेवलपर हैं)।

[...] परियोजना के प्रबंधन के बारे में चिंता करें या ग्राहक सहायता भी प्रदान करें?

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

Answer 7

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

1. उत्पाद विनिर्देश + उपयोग के मामले
   भले ही हर कोई जानता हो (या लगता है कि वे करते हैं) उत्पाद की कार्यक्षमता क्या है, यह नीचे लिखा जाना चाहिए। आप स्पष्ट विनिर्देश के बिना किसी एप्लिकेशन का परीक्षण नहीं कर सकते। एक विनिर्देश परिभाषित करता है कि सही व्यवहार क्या है और बग क्या है।
2. इकाई परीक्षण, एकीकरण परीक्षण
   टेस्ट इंटरनल के परीक्षण जो यूआई, असाधारण एप्लिकेशन स्टेट्स के माध्यम से टेस्ट करना मुश्किल है। यह हर बड़ी व्यवस्था के लिए जरूरी है। दोनों प्रकार के परीक्षणों में एक और दिलचस्प संपत्ति भी है - वे आपको कोड के हर हिस्से के माध्यम से फिर से जाने के लिए मजबूर करते हैं और आपको बग / वास्तुकला की समस्याओं का एहसास होगा जो आपने पहले कभी नहीं किया था।
3. कोड गुणवत्ता और कोडिंग मानक
   QA को किए जाने वाले कार्यों में से एक कोड जटिलता को मापना है। कम जटिलता कोड त्रुटियों की संभावना को कम करता है (बग्स को रोकना)।
4. कोड समीक्षा
   जब कोई परियोजना किसी दिए गए आकार तक पहुंचती है, या इसका उपयोग बहुत सारे उपयोगकर्ताओं द्वारा किया जाता है, तो कोड की समीक्षा एक होनी चाहिए। एक अन्य प्रोग्रामर को हमेशा कोड की समस्याएं / कीड़े मिलते हैं जो आपको याद हो गए थे। प्रोग्रामर कभी-कभी अपने कोड में स्पष्ट कीड़े के लिए अंधे होते हैं।
5. प्रलेखन
   आपके कोड और इसकी वास्तुकला का दस्तावेजीकरण करता है, यह आपको संभावित दोषों (मेरे अपने अनुभव) का एहसास करने में मदद करेगा।
6. परीक्षक
   परीक्षक एक बंदर नहीं है जो सिर्फ यूआई के माध्यम से क्लिक करता है। एक परीक्षक विनिर्देश लेता है और मामलों का उपयोग करता है और परीक्षण मामले बनाता है। फिर वह एक-एक करके उनका परीक्षण करता है। अगर किसी बग को एंड यूजर्स द्वारा रिपोर्ट किया जाता है, तो उसके लिए एक टेस्ट केस जोड़ा जाना चाहिए।

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

एक प्रोग्रामर क्या प्राप्त कर सकता है 2, 3 और 5।

आपको 4 के लिए एक और प्रोग्रामर की आवश्यकता है। एक बड़ी आईटी परियोजना के साथ कोई भी कंपनी और केवल एक डेवलपर जो सिस्टम को बहुत खतरनाक आधार पर जानता है।

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