मेन्यू

तकनीकी ऋण क्या है और क्यूए परीक्षकों को इसके बारे में चिंतित क्यों होना चाहिए?

  • मुख्य
  • चंचल परीक्षण
  • तकनीकी ऋण क्या है और क्यूए परीक्षकों को इसके बारे में चिंतित क्यों होना चाहिए?

what is technical debt

समस्याओं को खत्म करने के लिए हमारे साधन का प्रयास करें

तकनीकी ऋण एक रूपक विचार है जो तर्क देता है कि जैसे कोई वित्त में ऋण की समस्याओं में भाग सकता है, सॉफ्टवेयर संगठन पिछले परियोजनाओं और संस्करण रिलीज़ / स्प्रिंट के दौरान अधूरे काम के निर्माण में कुछ इसी तरह का सामना करते हैं।

तकनीकी ऋण क्या है?

यह उन समस्याओं / दोषों को ठीक करने के लिए आवश्यक प्रयास का प्रतिनिधित्व करता है जो किसी एप्लिकेशन के जारी होने पर कोड में बने रहते हैं। सरल शब्दों में - यह अंतर (बग के संदर्भ में) है कि क्या अपेक्षित है और क्या दिया गया है।

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

इस लेख में, आप सीखेंगे - तकनीकी ऋण क्या है, क्यूए टीम को इसके बारे में चिंतित क्यों होना चाहिए और सबसे महत्वपूर्ण बात यह है कि इसे कैसे प्रबंधित किया जाए।

तकनीक ऋण क्या है

छवि स्रोत

वार्ड कनिंघम विकी सॉफ्टवेयर के संस्थापक, इस विचार की कल्पना की 1990 के दशक में वापस, वित्तीय उद्योग पर खराब ऋण के प्रभाव के साथ समानताएं आरेखित करना, वस्तुतः ऋणों पर चूक के बाद अत्यधिक ब्याज धन का भुगतान करने के लिए गैर-अनुभव का अनुभव होना।

यूनिक्स साक्षात्कार प्रश्न और उत्तर का आदेश देता है

प्रति स्प्रिंट में बढ़ते टेक ऋण की चुनौती को Fig.1 में देखा जा सकता है।

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

बढ़ते तकनीकी ऋण

चित्र एक: स्प्रिंट भर में तकनीकी ऋण में स्केलेबल वृद्धि की कल्पना

आप क्या सीखेंगे:

क्यूए टीमें तकनीकी ऋण के कारण सबसे अधिक पीड़ित हैं

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

उदाहरण के लिए, यह देखा गया है कि कोड दोहराव प्रयासों के बीच कुछ भी हो सकता है २५ सेवा मेरे 35% अतिरिक्त काम।

बिन फाइल क्या है?

हालाँकि, कहीं नहीं हैं क्यूए परीक्षण की तुलना में तकनीकी ऋण के कारण चुनौतियां अधिक स्पष्ट हैं जहां परीक्षण टीमों को अप्रत्याशित समय सीमाएं पूरी करनी होती हैं और सब कुछ गियर से बाहर फेंक दिया जा सकता है।

आपके परीक्षकों को अनपेक्षित रूप से अंतिम क्षण में कितनी बार quandaries का सामना करना पड़ा, वितरण प्रबंधक ने आकर उनसे कहा, “टीम! हमें एक सप्ताह के समय में अपने उत्पाद को रोल आउट करना होगा, क्षमा करें कि यह समय में संचार करने में सक्षम नहीं है। कृपया सभी परीक्षण कार्यों को तत्काल पूरा करें ताकि हम डेमो के साथ तैयार हो सकें। ”

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

एक वास्तविक विश्व उदाहरण

कई वेबसाइटों और मोबाइल ऐप्स पर महत्वपूर्ण उपस्थिति वाले एक यूएस-आधारित ऑनलाइन रिटेलर ने खुद को एक वास्तविक दुनिया में पाया 'तकनीकी ऋण' चुनौती जब परीक्षण जाल की जटिलता ने प्रत्येक नए के साथ समझौता करना शुरू किया पूरे वेग से दौड़ना ।

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

40% से कम ऑटोमेशन कवरेज के साथ, तकनीकी ऋण चुनौती निम्नलिखित तरीकों से दिखाई देगी:

  • रिलीज परीक्षण में अत्यधिक समय की खपत - प्रत्येक परीक्षण स्प्रिंट के साथ ब्राउज़रों, उपकरणों और लिपियों की संख्या बढ़ने के साथ, रिलीज चक्र को समय-समय पर बाजार के नुकसान में देरी हो रही होगी।
  • काम पर रखने की बढ़ती लागत - परियोजना को समर्थन देने के लिए आवश्यक परीक्षकों की संख्या लगभग दोगुनी हो गई जो $ 500k अतिरिक्त लागत में अनुवादित हुई
  • परियोजना में जटिलता - परियोजना की बढ़ती जटिलता के साथ, परीक्षण मामलों और बगों पर नज़र रखना एक चुनौती बन गया था
  • झूठी सकारात्मकता का पीछा करने में बहुत समय बर्बाद किया - फिर से, बढ़ती परियोजना जटिलताओं का पतन।
  • 60% तक परीक्षण के विकास के प्रयास में वृद्धि - यह क्षेत्र के अनुसार होता है

क्यूए प्रथाओं में टेक ऋण प्रबंधन

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

इस के रूप में जाना जाता है त्वरित और गंदा दृष्टिकोण के लेखक मार्टिन फाउलर द्वारा एक ब्लॉग में कवर किया गया है तकनीकी ऋण चतुर्थांश ।

चंचल सिद्धांत तय करते हैं कि हम तकनीकी ऋण समस्या को उखाड़ने और मिलने में असमर्थता के रूप में देखते हैं QA बेंचमार्क ।

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

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

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

परीक्षण प्रभावशीलता

5 साल के अनुभव के लिए एसक्यूएल सर्वर साक्षात्कार सवाल और जवाब

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

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

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

विशिष्ट उदाहरण वाणिज्यिक-ऑफ-द-शेल्फ या मुफ्त उपकरण होंगे जैसे सेलेनियम, मंकीटॉक, रोबोटों , Borland SilkCentral, HP गुणवत्ता केंद्र और आईबीएम तर्कसंगत गुलाब ।

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

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

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

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

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

निष्कर्ष

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

लेखक के बारे में: यह eInfochips टीम द्वारा अतिथि पोस्ट है। वे एक अद्वितीय दृष्टिकोण के साथ आए हैं जिसे कहा जाता है टेक डेट जीरो क्यूए / ऑटोमेशन गतिविधियों में तकनीकी ऋण को धीरे-धीरे समाप्त करने के लिए सबसे संरचित और कुशल तरीकों में से एक है। तकनीक ऋण के बारे में अधिक जानने के लिए, इस वीडियो को देखें टेक विभाग को कम करने के लिए एक दृष्टिकोण पर।

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

अनुशंसित पाठ

^