अपडेट किया गया अगस्त 28, 2019
सॉफ्टवेयर विकसित होने के बाद से सॉफ्टवेयर विकास के हिस्से के रूप में परीक्षण को व्यापक रूप से अपनाया गया है। हालांकि, बिजनेस इंटेलिजेंस (बीआई) आईबीएम कॉग्नोस जैसे बीआई सॉफ्टवेयर में विकास के एक एकीकृत हिस्से के रूप में परीक्षण को अपनाने में धीमा रहा है। आइए जानें कि बीआई परीक्षण प्रथाओं और परिणामों को अपनाने में धीमा क्यों रहा है नहीं परीक्षण.
संगठन बीआई का परीक्षण क्यों नहीं करते...
- समय की पाबंधी. बीआई परियोजनाएं तेजी से वितरित करने के लिए लगातार दबाव में हैं। कुछ संगठनों को यह एहसास नहीं हो सकता है कि समय कम करने का सबसे आसान चरण परीक्षण है।
- बजट बाधाएं. सोच यह है कि परीक्षण बहुत महंगा है और एक परीक्षण टीम को समर्पित नहीं कर सकता है।
- तेज़ बेहतर है. यह जरूरी नहीं कि एक "फुर्तीली" दृष्टिकोण है और यह आपको गलत जगह पर जल्दी पहुंचा सकता है।
- "बस इसे पहली बार सही करें" मानसिकता. यह भोला दृष्टिकोण इस बात पर जोर देता है कि गुणवत्ता नियंत्रण की उपस्थिति से परीक्षण की आवश्यकता कम होनी चाहिए।
- स्वामित्व की कमी. यह पिछली गोली की तरह ही है। सोच यह है कि "हमारे उपयोगकर्ता इसका परीक्षण करेंगे।" इस दृष्टिकोण से नाखुश उपयोगकर्ता और बहुत सारे समर्थन टिकट हो सकते हैं।
- साधनों की कमी. गलत धारणा है कि उनके पास परीक्षण के लिए सही तकनीक नहीं है।
- परीक्षण की समझ की कमी. उदाहरण के लिए,
- परीक्षण को डेटा की सटीकता और वैधता, डेटा स्थिरता, डेटा की समयबद्धता, वितरण के प्रदर्शन और वितरण तंत्र के उपयोग में आसानी का मूल्यांकन करना चाहिए।
- बीआई परियोजना के दौरान परीक्षण में प्रतिगमन परीक्षण, इकाई परीक्षण, धुआं परीक्षण, एकीकरण परीक्षण, उपयोगकर्ता स्वीकृति परीक्षण, तदर्थ परीक्षण, तनाव/मापनीयता परीक्षण, सिस्टम प्रदर्शन परीक्षण शामिल हो सकते हैं।
बीआई का परीक्षण न करने की लागत क्या है?
- अक्षम डिजाइन. यदि परीक्षण की उपेक्षा की जाती है तो खराब वास्तुकला की खोज नहीं की जा सकती है। डिजाइन मुद्दे प्रयोज्य, प्रदर्शन, पुन: उपयोग, साथ ही रखरखाव और रखरखाव में योगदान कर सकते हैं।
- डेटा अखंडता मुद्दे. डेटा भ्रष्टाचार या डेटा वंश चुनौतियों से संख्याओं में विश्वास की कमी हो सकती है।
- डेटा सत्यापन मुद्दे. खराब डेटा पर किए गए निर्णय व्यवसाय के लिए विनाशकारी हो सकते हैं। गलत जानकारी पर आधारित मेट्रिक्स द्वारा प्रबंधित करने की कोशिश करने से बुरा कुछ नहीं है।
- उपयोगकर्ता अपनाने में कमी. यदि संख्याएं सही नहीं हैं, या यदि एप्लिकेशन उपयोगकर्ता के अनुकूल नहीं है, तो आपका उपयोगकर्ता समुदाय आपके चमकदार नए एंटरप्राइज़ बीआई सॉफ़्टवेयर का उपयोग नहीं करेगा।
- मानकीकरण के अभाव में बढ़ी लागत.
- बीआई विकास जीवन चक्र के बाद के चरणों में दोषों की मरम्मत के लिए बढ़ी हुई लागत. आवश्यकता चरण से परे खोजे गए किसी भी मुद्दे की कीमत पहले की तुलना में तेजी से अधिक होगी।
अब जबकि हमने यह निर्धारित कर लिया है कि संगठन परीक्षण क्यों नहीं कर रहे हैं और जब आप बीआई का परीक्षण नहीं करते हैं तो होने वाले नुकसान, आइए सॉफ्टवेयर विकास में परीक्षण पर कुछ अध्ययनों को देखें।
स्टडी शो टेस्टिंग आपके बीआई प्लेटफॉर्म से पैसे की बचत होती है!
139 उत्तरी अमेरिकी कंपनियों का एक अध्ययन 250 से 10,000 कर्मचारियों के आकार में, $5.2M से $22M की वार्षिक डिबगिंग लागत की सूचना दी। यह लागत सीमा उन संगठनों को दर्शाती है जो नहीं कर जगह में स्वचालित इकाई परीक्षण है। आईबीएम और माइक्रोसॉफ्ट के अलग-अलग शोध में पाया गया कि साथ में स्वचालित इकाई परीक्षण, दोषों की संख्या को ६२% से ९१% के बीच कम किया जा सकता है. इसका मतलब है कि डिबगिंग पर खर्च किए गए डॉलर को $5M - $22M रेंज से $0.5M से $8.4M रेंज तक कम किया जा सकता है। यह एक बड़ी बचत है!
त्रुटियों को ठीक करने की लागत तेजी से बढ़ती है।
सफल सॉफ्टवेयर विकास रणनीति पर एक पेपर यह दर्शाता है कि अधिकांश त्रुटियां विकास चक्र में जल्दी की जाती हैं और यह कि आप जितनी देर तक पता लगाने और ठीक करने की प्रतीक्षा करेंगे, उतनी ही अधिक लागत आपको ठीक करने में होगी। इसलिए, यह स्पष्ट निष्कर्ष निकालने के लिए एक रॉकेट वैज्ञानिक की आवश्यकता नहीं है कि जितनी जल्दी त्रुटियों का पता लगाया जाए और उन्हें ठीक किया जाए, उतना ही बेहतर है। रॉकेट साइंस की बात करें तो ऐसा ही होता है कि नासा ने बस उसी पर एक पेपर प्रकाशित किया - "परियोजना जीवन चक्र के माध्यम से त्रुटि लागत वृद्धि।"
यह सहज है कि विकास जीवन-चक्र की प्रगति के साथ त्रुटियों को ठीक करने की लागत बढ़ जाती है। नासा का अध्ययन यह निर्धारित करने के लिए किया गया था कि खोजी गई त्रुटियों को ठीक करने की सापेक्ष लागत कितनी जल्दी बढ़ती है। इस अध्ययन ने सापेक्ष लागतों को निर्धारित करने के लिए तीन दृष्टिकोणों का उपयोग किया: नीचे से ऊपर की लागत विधि, कुल लागत टूटने की विधि, और ऊपर से नीचे की काल्पनिक परियोजना विधि। इस पेपर में वर्णित दृष्टिकोण और परिणाम एक बड़े, जटिल अंतरिक्ष यान, एक सैन्य विमान, या एक छोटे संचार उपग्रह के विकास में उपयोग किए जाने वाले प्रोजेक्ट विशेषताओं वाले हार्डवेयर/सॉफ्टवेयर सिस्टम के विकास को मानते हैं। परिणाम उस डिग्री को दिखाते हैं जिस तक लागत बढ़ती है, क्योंकि त्रुटियों की खोज की जाती है और परियोजना जीवन चक्र में बाद और बाद के चरणों में तय की जाती है। यह अध्ययन अन्य शोधों का प्रतिनिधि है जो किया गया है।
उपरोक्त चार्ट से, TRW, IBM, GTE, Bell Labs, TDC और अन्य के शोध विभिन्न विकास चरणों के दौरान त्रुटियों को ठीक करने की लागत को दर्शाता है:
- आवश्यकता चरण के दौरान खोजी गई त्रुटि को ठीक करने की लागत को इस प्रकार परिभाषित किया गया है: 1 इकाई
- डिज़ाइन चरण के दौरान पाई जाने वाली त्रुटि को ठीक करने की लागत है डबल कि
- कोड और डिबग चरण में, त्रुटि को ठीक करने की लागत है 3 इकाइयों
- इकाई परीक्षण और एकीकृत चरण में, त्रुटि को ठीक करने की लागत बन जाती है 5
- सिस्टम परीक्षण चरण चरण में, त्रुटि को ठीक करने की लागत 20 . तक बढ़ जाती है
- और एक बार सिस्टम ऑपरेशन के चरण में है, त्रुटि को ठीक करने की सापेक्ष लागत बढ़कर 98 हो गई है, यदि आवश्यकता चरण में पाई जाती है तो त्रुटि को ठीक करने की लागत का लगभग 100 गुना!
लब्बोलुआब यह है कि यदि दोषों को जल्दी नहीं पकड़ा जाता है तो उन्हें ठीक करना अधिक महंगा होता है।
निष्कर्ष
महत्वपूर्ण शोध किया गया है जो सॉफ्टवेयर विकास में प्रारंभिक और निरंतर परीक्षण के मूल्य को प्रदर्शित करता है। हम, बीआई समुदाय में, सॉफ्टवेयर विकास में अपने दोस्तों से सीख सकते हैं। हालांकि अधिकांश औपचारिक शोध सॉफ्टवेयर विकास से संबंधित किए गए हैं, फिर भी बीआई विकास के बारे में इसी तरह के निष्कर्ष निकाले जा सकते हैं। परीक्षण का मूल्य निर्विवाद है, लेकिन कई संगठन अपने बीआई पर्यावरण के औपचारिक परीक्षण का लाभ उठाने और अपनी बीआई विकास प्रक्रियाओं में परीक्षण को एकीकृत करने के लिए धीमे रहे हैं। की लागत नहीं परीक्षण वास्तविक हैं। से जुड़े जोखिम नहीं परीक्षण वास्तविक हैं।
कार्रवाई में कुछ स्वचालित Cognos परीक्षण देखना चाहते हैं? हमारी प्लेलिस्ट पर वीडियो देखें यहाँ पर क्लिक!