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