सॉफ्टवेयर परीक्षण में परीक्षण अनुमान तकनीकें
थॉमस हैमिल्टन
⚡ स्मार्ट सारांश
सॉफ्टवेयर परीक्षण अनुमान तकनीकें परीक्षण में लगने वाले समय और लागत का अनुमान लगाती हैं। चार चरणों वाली प्रक्रिया - कार्यों को विभाजित करना, जिम्मेदार व्यक्तियों को नियुक्त करना, प्रयास का अनुमान लगाना और हितधारकों के साथ सत्यापन करना - अस्पष्ट समय-सीमाओं को एक तर्कसंगत योजना में बदल देती है जिसे प्रबंधन अनुमोदित कर सकता है।
सॉफ्टवेयर परीक्षण आकलन क्या है?
सॉफ्टवेयर परीक्षण अनुमान यह एक प्रबंधन गतिविधि है जो यह अनुमान लगाती है कि परीक्षण कार्य में कितना समय लगेगा और कितना खर्च आएगा। विश्वसनीय परीक्षण अनुमान तैयार करना सबसे महत्वपूर्ण जिम्मेदारियों में से एक है। परीक्षण प्रबंधन क्योंकि यह समय-सारणी, बजट और संसाधन संबंधी निर्णयों को प्रभावित करता है।
टेस्ट एस्टिमेशन क्यों महत्वपूर्ण है?
ग्राहक परीक्षण अनुबंध को अंतिम रूप देने से पहले हमेशा दो प्रश्न पूछते हैं:
छोटे प्रोजेक्टों के लिए इन सवालों के जवाब देना आसान है। लेकिन बड़े प्रोजेक्टों के लिए—जैसे कि परीक्षण करना—इन सवालों के जवाब देना मुश्किल है। Guru99 बैंक की वेबसाइट — आपको अपने उत्तर का बचाव करने के लिए एक संरचित तकनीक की आवश्यकता है।
क्या अनुमान लगाएं?
- संसाधन: लोग, उपकरण, सुविधाएं, धन और काम को पूरा करने के लिए आवश्यक कोई भी अन्य चीज।
- समय: किसी भी प्रोजेक्ट में सबसे मूल्यवान संसाधन — प्रत्येक रिलीज़ की एक समय सीमा होती है।
- मानवीय कौशल: टीम का ज्ञान और अनुभव। अधिक कुशल परीक्षक कम अनुभवी टीम की तुलना में तेजी से काम पूरा करते हैं।
- लागत: परियोजना का बजट — यानी नियोजित परीक्षण को पूरा करने के लिए कितनी धनराशि की आवश्यकता होगी।
अनुमान कैसे लगाएं?
सॉफ्टवेयर परीक्षण अनुमान की सामान्य तकनीकें निम्नलिखित हैं:
- कार्य विभाजन संरचना (डब्ल्यूबीएस)।
- त्रिबिंदु अनुमान।
- वाइडबैंड डेल्फी।
- फंक्शन पॉइंट या टेस्टिंग पॉइंट विश्लेषण।
- यूज़-केस पॉइंट विधि।
- प्रतिशत वितरण।
- तदर्थ विधि।
नीचे दी गई चार-चरणीय प्रक्रिया एक तर्कसंगत अनुमान तक पहुंचने के लिए कई तकनीकों को जोड़ती है। उदाहरण में निम्नलिखित का उपयोग किया गया है: Guru99 बैंक केस स्टडी।
चरण 1) पूरी परियोजना को उप-कार्यों में विभाजित करें
उपयोग कार्य विश्लेषण संरचना किसी जटिल परियोजना को मॉड्यूल, उप-मॉड्यूल और अंततः सबसे छोटे सार्थक कार्यों में विभाजित करने की तकनीक। अस्पष्ट परियोजनाओं की तुलना में निम्नतम स्तर पर अनुमान कहीं अधिक विश्वसनीय होते हैं।
इस तकनीक का प्रयोग करके तोड़ें Guru99 बैंक परियोजना को पांच छोटे कार्यों में विभाजित किया गया है:
फिर प्रत्येक कार्य को उप-कार्यों में विभाजित किया जाता है जब तक कि प्रत्येक पंक्ति अनुमान लगाने के लिए पर्याप्त रूप से विस्तृत न हो जाए।
| कार्य | उप-कार्य |
|---|---|
| सॉफ्टवेयर आवश्यकता विनिर्देश का विश्लेषण करें | आवश्यकताओं के विवरण की जांच करें। |
| वेबसाइट के बारे में अधिक जानने के लिए डेवलपर्स और अन्य हितधारकों का साक्षात्कार लें। | |
| परीक्षण विनिर्देश बनाएं | परीक्षण परिदृश्यों को डिजाइन करें। |
| टेस्ट केस बनाएं। | |
| Revटेस्ट केस की समीक्षा करें और उनमें संशोधन करें। | |
| परीक्षण मामलों को निष्पादित करें | परीक्षण वातावरण का निर्माण करें। |
| टेस्ट केस चलाएँ। | |
| Revपरीक्षण निष्पादन के परिणाम देखें। | |
| दोषों की रिपोर्ट करें | बनाएं दोष रिपोर्ट. |
| खामियों की रिपोर्ट करें। |
चरण 2) प्रत्येक कार्य को टीम के एक सदस्य को सौंपें।
प्रत्येक उप-कार्य को उसके सबसे उपयुक्त स्वामी को सौंपें।
| कार्य | मालिक |
|---|---|
| सॉफ्टवेयर आवश्यकता विनिर्देश का विश्लेषण करें | सभी टीम सदस्य |
| परीक्षण विनिर्देश बनाएं | परीक्षक / परीक्षण विश्लेषक |
| परीक्षण वातावरण का निर्माण करें | परीक्षण प्रशासक |
| परीक्षण मामलों को निष्पादित करें | परीक्षक, परीक्षण प्रशासक |
| दोषों की रिपोर्ट करें | टेस्टर |
चरण 3) प्रत्येक कार्य के लिए प्रयास का अनुमान
इस चरण में दो पूरक तकनीकें कारगर साबित होती हैं:
- फंक्शन पॉइंट विधि।
- तीन-बिंदु अनुमान।
विधि 1) फंक्शन पॉइंट विधि
टेस्ट मैनेजर प्रत्येक कार्य के लिए आकार, अवधि और लागत का अनुमान लगाता है।
चरण A) कार्य के आकार का अनुमान लगाएं
“परीक्षण विनिर्देश तैयार करें” कार्य लें। इसका आकार परीक्षण किए जा रहे सिस्टम के कार्यात्मक आकार पर निर्भर करता है — जितने अधिक फ़ंक्शन होंगे, सिस्टम उतना ही जटिल होगा। फ़ंक्शन बिंदुओं को आमतौर पर तीन समूहों में वर्गीकृत किया जाता है: जटिल, मध्यम और सरल।
जटिलता के आधार पर, टेस्ट मैनेजर प्रत्येक फ़ंक्शन पॉइंट को एक भार प्रदान करता है:
| समूह | भार |
|---|---|
| जटिल | 5 |
| मध्यम | 3 |
| सरल | 1 |
RSI Guru99 बैंक की वेबसाइट को 12 कार्यात्मक बिंदुओं में विभाजित किया गया है। इनकी जटिलता का सारांश नीचे दिया गया है।
| # | मॉड्यूल | लागू भूमिकाएँ | विवरण | भार |
|---|---|---|---|---|
| 1 | बैलेंस पूछताछ | प्रबंधक, ग्राहक | ग्राहक: केवल अपने खातों का बैलेंस देखें। प्रबंधक: निगरानी में रखे गए प्रत्येक ग्राहक के बैलेंस की जांच करें। |
3 |
| 2 | फंड ट्रांसफर | प्रबंधक, ग्राहक | ग्राहक: अपने खाते से किसी भी गंतव्य स्थान पर धनराशि स्थानांतरित करें। प्रबंधक: किसी भी स्रोत से किसी भी गंतव्य तक धनराशि हस्तांतरित करें। |
5 |
| 3 | मिनी स्टेटमेंट | प्रबंधक, ग्राहक | किसी खाते के पिछले पांच लेन-देन। ग्राहक: केवल अपने खाते देखें। प्रबंधक: किसी भी खाते को देखें। |
3 |
| 4 | अनुकूलित विवरण | प्रबंधक, ग्राहक | तिथि या मूल्य के आधार पर लेनदेन को फ़िल्टर किया गया। ग्राहक: केवल अपने स्वयं के खातों का उपयोग करें। प्रबंधक: कोई भी खाता। |
5 |
| 5 | पासवर्ड बदलें | प्रबंधक, ग्राहक | ग्राहक: अपना पासवर्ड स्वयं बदलें। प्रबंधक: अपना पासवर्ड स्वयं बदलें (ग्राहक का नहीं)। |
1 |
| 6 | नये ग्राहक | प्रबंधक | ग्राहक विवरण (पता, ईमेल, टेलीफोन नंबर) जोड़ें और संपादित करें। | 3 |
| 7 | नया खाता | प्रबंधक | बचत और चालू खाते; एक ग्राहक इनमें से एक से अधिक खाते रख सकता है। प्रबंधक मौजूदा ग्राहकों के लिए नए खाते जोड़ता है। | 5 |
| 8 | खाता संपादित करें | प्रबंधक | मौजूदा खाते के विवरण संपादित करें। | 1 |
| 9 | खाता हटा दो | प्रबंधक | किसी ग्राहक का मौजूदा खाता हटाएं। | 1 |
| 10 | ग्राहक हटाएँ | प्रबंधक | किसी ग्राहक को तभी हटाएं जब कोई सक्रिय खाता न हो। | 1 |
| 11 | डिपॉजिट | प्रबंधक | शाखा में किसी भी खाते में नकद जमा करें। | 3 |
| 12 | धननिकासी | प्रबंधक | शाखा में किसी भी खाते से नकद निकालें। | 3 |
चरण B) कार्य की अवधि का अनुमान लगाएं
एक बार जटिलता निर्धारित हो जाने के बाद, प्रत्येक समूह के परीक्षण के लिए आवश्यक अवधि का अनुमान लगाएं।
- कुल प्रयास: वेबसाइट के हर फंक्शन को टेस्ट करने के लिए पूरा प्रयास किया गया।
- कुल फ़ंक्शन अंक: वेबसाइट के कुल मॉड्यूल।
- प्रति फ़ंक्शन बिंदु अनुमान: प्रति पॉइंट औसत प्रयास; यह टीम की उत्पादकता पर निर्भर करता है।
मान लीजिए कि टीम का प्रति फ़ंक्शन बिंदु अनुमान है 5 घंटे/पॉइंटकुल प्रयास Guru99 बैंक का उदाहरण यह है:
| समूह | भार | फ़ंक्शन बिंदु | कुल |
|---|---|---|---|
| जटिल | 5 | 3 | 15 |
| मध्यम | 3 | 5 | 15 |
| सरल | 1 | 4 | 4 |
| फ़ंक्शन कुल अंक | 34 | ||
| प्रति बिंदु अनुमान | 5 | ||
| कुल अनुमानित प्रयास (व्यक्ति-घंटे) | 170 | ||
“परीक्षण विनिर्देश तैयार करें” को पूरा करने में कुल समय लगभग इतना लगता है। 170 व्यक्ति-घंटेएक बार प्रयास ज्ञात हो जाने पर, आप अवधि और लागत निर्धारित करने के लिए संसाधनों का आवंटन कर सकते हैं।
चरण C) कार्यों की लागत का अनुमान लगाएं
यह चरण ग्राहक के दूसरे प्रश्न का उत्तर देता है — “इसकी लागत कितनी है?”। टीम की औसत दर मान लें। 5 घंटे $ /उपरोक्त कार्य में 170 घंटे लगते हैं, इसलिए लागत यह है। 170 × $5 = $850प्रोजेक्ट बजट निकालने के लिए प्रत्येक WBS कार्य पर समान गणना लागू करें।
अनुमान जितना सटीक होगा, आप परियोजना के बजट को उतना ही बेहतर ढंग से प्रबंधित कर पाएंगे और यह सुनिश्चित कर पाएंगे कि खर्च किया गया हर डॉलर लाभप्रद हो।
विधि 2) तीन-बिंदु अनुमान
थ्री-पॉइंट एस्टिमेशन एक संरचित तकनीक है जिसमें टेस्ट मैनेजर प्रत्येक कार्य के लिए तीन मान प्रदान करता है — आशावादी, सबसे अधिक संभावना, तथा निराशावादी प्रयास — पूर्व अनुभव या सर्वोत्तम अनुमानों पर आधारित।
“परीक्षण विनिर्देश बनाएं” के लिए तीन मान निम्नलिखित हो सकते हैं:
- सर्वोत्तम स्थिति: एक मजबूत और अनुभवी टीम के साथ 120 व्यक्ति-घंटे (~15 दिन)।
- सबसे अधिक संभावना: एक सामान्य टीम और संसाधनों के साथ 170 व्यक्ति-घंटे (~21 दिन)।
- सबसे खराब मामला: कम अनुभवी टीम और अतिरिक्त पुन:कार्य के साथ 200 व्यक्ति-घंटे (~25 दिन) लगे।
PERT-शैली के सूत्र का उपयोग करके भारित औसत की गणना करें:
महत्व E विश्व का सबसे लोकप्रिय एंव भारित औसत — "परीक्षण विनिर्देश तैयार करें" के लिए अनुमानित शीर्षक।
आत्मविश्वास व्यक्त करने के लिए Eमानक विचलन की गणना करें:
के लिए Guru99 बैंक उदाहरण में अनुमान इस प्रकार निकलता है 166.6 ± 13.33 व्यक्ति-घंटे — 153.33 से 179.99 व्यक्ति-घंटे की सीमा।
चरण 4) अनुमान को मान्य करें
वर्क बेस रिपोर्ट (डब्ल्यूबीएस) से सभी कार्यों के अनुमानों को एकत्रित करें और समीक्षा और अनुमोदन के लिए प्रबंधन बोर्ड (सीईओ, परियोजना प्रबंधक, प्रमुख हितधारक) को योजना प्रस्तुत करें।
अनुमान को तार्किक रूप से समझाएं ताकि वे मान्यताओं, चुनी गई तकनीकों और उसमें शामिल आकस्मिकता को समझ सकें।
परीक्षण अनुमान के सर्वोत्तम तरीके
बफ़र समय जोड़ें
योजनाएँ अक्सर वास्तविकता से टकराने पर टिक नहीं पातीं — टीम के सदस्य चले जाते हैं, परीक्षण अपेक्षा से अधिक समय लेते हैं, निर्भरताएँ बिगड़ जाती हैं। प्रत्येक अनुमान में उचित अतिरिक्त समय रखें ताकि समय सारिणी में आने वाली छोटी-मोटी बाधाओं को संभाला जा सके।
संसाधनों की उपलब्धता के लिए योजना बनाएं
नियोजित अवकाश, प्रशिक्षण और ऑन-कॉल रोटेशन को ध्यान में रखें। उपलब्धता को नज़रअंदाज़ करने वाले अनुमान कागज़ पर तो बहुत अच्छे लगते हैं, लेकिन क्रियान्वयन में विफल हो जाते हैं।
पिछले अनुभवों को संदर्भ के रूप में उपयोग करें
इसी तरह की परियोजनाओं से प्राप्त ऐतिहासिक डेटा अमूल्य है। यदि आपने पिछले वर्ष किसी तुलनीय वेबसाइट का परीक्षण किया था, तो उसके वास्तविक परिणामों, सामने आई समस्याओं और उस बफर से सीखें जिसने समस्या को हल किया।
अनुमान पर कायम रहें — लेकिन समय-समय पर इसकी समीक्षा करते रहें।
अनुमान विश्वसनीय नहीं हैं।tracये केवल अनुमान हैं। Revनिर्धारित लक्ष्यों पर उनसे मिलें और केवल तभी बदलाव करें जब आवश्यकताओं में महत्वपूर्ण परिवर्तन हो या नई जानकारी से स्थिति में बदलाव आए। ग्राहक के साथ किसी भी बदलाव पर पारदर्शी रूप से बातचीत करें।
सॉफ़्टवेयर परीक्षण अनुमान टेम्पलेट
सॉफ्टवेयर टेस्ट एस्टिमेशन एक्सेल फाइल (.xlsx) डाउनलोड करें
अन्य अनुमान तकनीकें
डब्ल्यूबीएस, फंक्शन पॉइंट और थ्री-पॉइंट एस्टिमेशन के अलावा, कई अन्य तकनीकें भी व्यापक रूप से उपयोग की जाती हैं:
- वाइडबैंड डेल्फी: विशेषज्ञों के एक पैनल द्वारा पुनरावृत्त सर्वसम्मति अनुमान।
- उपयोग-मामला बिंदु विधि: उपयोग के मामलों की संख्या और जटिलता से प्रयास प्राप्त होता है।
- प्रतिशत वितरण: परियोजना के कुल प्रयासों का एक निश्चित प्रतिशत परीक्षण के लिए आवंटित करता है।
- तदर्थ विधि: ऐतिहासिक डेटा अनुपलब्ध होने पर विशेषज्ञ निर्णय।
नीचे से ऊपर बनाम ऊपर से नीचे अनुमान
अनुमान लगाने का एक व्यावहारिक दृष्टिकोण भी दो पूरक रणनीतियों में विभाजित हो जाता है:
- नीचे से ऊपर की ओर अनुमान: यह कार्य प्रणाली के सबसे निचले स्तर के कार्यों पर आधारित है। कई हितधारक, अनुभवी कर्मचारी और योगदानकर्ता अपने आंकड़ों को मिलाकर एक सटीक योग निकालते हैं। यह तब आदर्श है जब कार्य को अच्छी तरह से समझा गया हो।
- शीर्ष-पंक्ति अनुमान: यह परियोजना को आकार और जटिलता के आधार पर वर्गीकृत करता है और समान आकार की पूर्ण परियोजनाओं से इसकी तुलना करता है। साथ ही प्रति परियोजना औसत प्रयास का भी उपयोग करता है। परीक्षण का मामला और यह अनुमानित मामलों की संख्या के आधार पर बढ़ता है। परियोजना के शुरुआती चरण में उपयोगी होता है जब विवरण कम उपलब्ध होते हैं।
अधिकांश टीमें इन दोनों का मिश्रण करती हैं - मुख्य संख्या के लिए ऊपर से नीचे की ओर और आत्मविश्वास के लिए नीचे से ऊपर की ओर - और जब बजट इसकी अनुमति देता है तो परिणाम को परिष्कृत मॉडलों के साथ जोड़ती हैं।
