टेस्ट एस्टिमेशन तकनीकें
Test estimation यह अनुमान लगाना है कि किसी दिए गए scope की टेस्टिंग में कितनी मेहनत और समय लगेगा। अच्छा estimate कोई एक संख्या नहीं है जो बाद में सही निकले; यह लिखी गई मान्यताओं के साथ एक range है, ऐसी तकनीक से बनी जिसे दूसरे जाँच सकें, और तथ्य बदलते ही जिसे दोबारा देखा जाए।
यह गाइड बताती है कि test estimate क्यों ग़लत होते हैं, टेस्टिंग की मेहनत किन कारकों से तय होती है, मुख्य तकनीकें — ratio-based estimation, extrapolation, Wideband Delphi, planning poker, three-point estimation और work breakdown structure — और एक पूरा संख्यात्मक उदाहरण, जिसमें नतीजे को range के रूप में बताने और दोबारा estimate करने का समय भी शामिल है।
Test estimate क्यों फ़ेल होते हैं
ज़्यादातर estimate की विफलताएँ गणित की ग़लतियाँ नहीं होतीं। वे ग़लत चीज़ का अनुमान लगाने से या अंदाज़े को वादा मान लेने से आती हैं। टेस्टिंग ख़ास तौर पर जोखिम में है क्योंकि इसकी मेहनत का एक हिस्सा ऐसी चीज़ पर निर्भर है जो पहले से कोई नहीं जानता: प्रोडक्ट में कितने डिफ़ेक्ट हैं और उन्हें ठीक करने व re-test करने में कितना समय लगेगा।
- सिर्फ़ execution का अनुमान — test analysis और design, environment और डेटा setup, automation maintenance, डिफ़ेक्ट re-testing, regression runs और reporting भूल जाते हैं।
- एक संख्या दी जाती है और फिर उसे वादा समझा जाता है, जबकि वह सिर्फ़ सबसे संभावित स्थिति थी।
- Estimate deadline पर टिका होता है: जवाब scope से आगे की ओर नहीं, तारीख़ से पीछे की ओर निकाला जाता है।
- Rework को नज़रअंदाज़ किया जाता है — plan मानता है कि पहला build टेस्ट लायक है और हर डिफ़ेक्ट एक बार re-test होगा।
- दूसरी टीमों पर निर्भरताएँ (build, environment, थर्ड-पार्टी sandbox) लिखी नहीं जातीं, इसलिए उनकी देरी टेस्टिंग का overrun लगती है।
- Scope बदलता है पर estimate नहीं।
- Estimate लगाने वाला वह व्यक्ति नहीं है जो काम करेगा, और तुलना के लिए कोई historical डेटा नहीं है।
टेस्टिंग की मेहनत तय करने वाले कारक
ISTQB Foundation syllabus (अपने 2018 संस्करण में) ने test effort पर असर डालने वाले कारकों को चार समूहों में बाँटा था। यह समूहन आज भी उपयोगी checklist है: कोई संख्या स्वीकार करने से पहले पूछें कि हर कारक इस scope पर कैसे लागू होता है।
- Product — आकार और जटिलता, test basis की गुणवत्ता (साफ़ या अस्पष्ट requirements), जिन quality विशेषताओं को टेस्ट करना है (security, performance, accessibility), audit के लिए ज़रूरी documentation, प्लेटफ़ॉर्म, डिवाइस और भाषाओं की संख्या (अरबी और अंग्रेज़ी, right-to-left लेआउट), और बाहरी सिस्टम से integration।
- Process — lifecycle मॉडल, test process की परिपक्वता, tool और automation सपोर्ट, environment की उपलब्धता और स्थिरता, और समय का दबाव।
- People — टेस्टर और डेवलपर के कौशल और domain अनुभव, टीम की स्थिरता, और टीम कितनी अच्छी तरह साथ काम करती है।
- Test results — मिले डिफ़ेक्ट की संख्या और severity, और उनसे होने वाला rework; डिफ़ेक्ट भरा build re-testing और regression की मेहनत कई गुना कर देता है।
आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर आज़माएँ: AI रिस्क-बेस्ड टेस्ट जनरेटर
Metrics-based तकनीकें: ratio और extrapolation
ISTQB CTFL v4.0 syllabus estimation की चार तकनीकें बताता है: ratio पर आधारित estimation, extrapolation, Wideband Delphi और three-point estimation। पहली दो metrics-based हैं और आपके अपने संगठन का historical या मौजूदा डेटा चाहती हैं — किसी दूसरी कंपनी के आँकड़े या इंडस्ट्री औसत कमज़ोर विकल्प हैं।
Ratio-based estimation पिछले प्रोजेक्ट में देखे गए अनुपात को नए प्रोजेक्ट पर लागू करता है। उदाहरण के लिए, अगर पिछली चार रिलीज़ में टेस्टिंग की मेहनत development की मेहनत का 0.38, 0.42, 0.45 और 0.35 थी (औसत 0.40), और development नई रिलीज़ का अनुमान 70 person-days लगाता है, तो ratio लगभग 28 person-days टेस्टिंग सुझाता है। Ratio सिर्फ़ मिलते-जुलते काम पर मान्य है: नए पेमेंट integration वाली रिलीज़ UI टेक्स्ट बदलावों वाली रिलीज़ जैसी नहीं है।
Extrapolation मौजूदा प्रोजेक्ट के माप से उसके बाक़ी हिस्से का अनुमान लगाता है। उदाहरण के लिए, पहले execution cycle के चार दिन बाद टीम ने 130 नियोजित टेस्ट में से 48 execute किए, यानी लगभग 12 प्रति दिन, और 9 डिफ़ेक्ट पाए। इस दर से बाक़ी 82 टेस्ट को लगभग 7 दिन और चाहिए — उन 9 डिफ़ेक्ट (और आने वाले डिफ़ेक्ट) के re-testing से पहले। प्रोजेक्ट आगे बढ़ने के साथ extrapolation ज़्यादा भरोसेमंद होता जाता है, इसलिए यह re-estimation की स्वाभाविक तकनीक है।
Expert-based तकनीकें: Wideband Delphi और planning poker
जब historical डेटा कम हो, तो एक व्यक्ति के अंदाज़े से व्यवस्थित expert judgement बेहतर काम करता है। Wideband Delphi एक iterative तकनीक है जिसमें विशेषज्ञ अलग-अलग अनुमान लगाते हैं, तुलना करते हैं, अंतर के कारणों पर चर्चा करते हैं, और फिर अनुमान लगाते हैं जब तक अनुमान पास न आ जाएँ या बचा अंतर समझ में न आ जाए।
Planning poker agile टीमों में बहुत इस्तेमाल होता है और आम तौर पर Wideband Delphi का एक रूप बताया जाता है। हर सदस्य के पास मानों वाले कार्ड होते हैं (अक्सर modified Fibonacci सीरीज़ जैसे 1, 2, 3, 5, 8, 13), सब एक साथ user story का अनुमान दिखाते हैं, और सबसे ऊँचा और सबसे नीचा अनुमान देने वाले अपना तर्क बताते हैं, फिर टीम दोबारा वोट करती है। अनुमान आम तौर पर पूरी story के relative story points होते हैं, इसलिए टेस्टिंग की मेहनत story के आकार का हिस्सा होती है, अलग संख्या नहीं — इसीलिए टेस्टर का कमरे में होना ज़रूरी है: जो story बनाने में आसान है, वह टेस्ट करने में महँगी हो सकती है।
- 1. Coordinator सभी estimators के सामने scope और मान्यताएँ रखता है।
- 2. हर विशेषज्ञ अकेले अनुमान लगाता है और अपनी मान्यताएँ लिखता है।
- 3. अनुमान एक साथ दिखाए जाते हैं, अगर समूह चाहे तो नाम के बिना।
- 4. सबसे अलग अनुमान वाले बताते हैं कि वे क्या जानते या मानते हैं जो दूसरे नहीं; सबसे ज़्यादा मूल्य इसी चर्चा में है।
- 5. सब दोबारा अनुमान लगाते हैं। अंतर स्वीकार्य होने तक दोहराएँ, और अंतिम range व मान्यताएँ दर्ज करें।
Three-point estimation
Three-point estimation हर task के लिए तीन मान माँगता है: optimistic अनुमान a, most likely अनुमान m और pessimistic अनुमान b। Weighted mean E = (a + 4m + b) / 6 most likely मान को दोनों छोरों से चार गुना वज़न देता है; यह PERT का weighting है। Standard deviation का अनुमान SD = (b − a) / 6 से लगाया जाता है। CTFL v4.0 syllabus नतीजे को E ± SD के रूप में दिखाता है।
दो गुण इस तकनीक को उपयोगी बनाते हैं। पहला, टेस्टिंग में pessimistic पूँछ आम तौर पर optimistic से लंबी होती है — build हफ़्तों देर से आ सकता है पर शायद ही हफ़्तों पहले — इसलिए E आम तौर पर m से ज़्यादा होता है, और यह अंतर जोखिम के बारे में जानकारी है। दूसरा, b − a का फ़ासला दिखाता है कि task कितना अनिश्चित है; चौड़े फ़ासले वाला task बाँटने या जल्दी जाँचने लायक है। SD को अनुमान मानें, गारंटी वाली probability नहीं: यह distribution के आकार की उन मान्यताओं पर टिका है जिनका असली प्रोजेक्ट हमेशा पालन नहीं करते।
- नीचे के ब्लॉक का उदाहरण: promotion rules के टेस्ट design और execute करना, a = 6 दिन, m = 9 दिन, b = 18 दिन। तब E = (6 + 36 + 18) / 6 = 10 दिन और SD = (18 − 6) / 6 = 2 दिन। रिपोर्ट ऐसे करें: लगभग 10 दिन; E ± SD पर 8–12 दिन; E ± 2 SD पर 6–14 दिन।
- कई स्वतंत्र tasks जोड़ते समय: कुल E सभी E का जोड़ है, लेकिन कुल SD सभी SD के वर्गों के जोड़ का वर्गमूल है, SD का सीधा जोड़ नहीं।
Three-point estimate (PERT weighting)
a = optimistic m = most likely b = pessimistic
E = (a + 4m + b) / 6
SD = (b - a) / 6
Example: design and execute tests for the promotion rules
a = 6 days m = 9 days b = 18 days
E = (6 + 4*9 + 18) / 6 = 60 / 6 = 10 days
SD = (18 - 6) / 6 = 2 days
Report: about 10 days; E +/- SD = 8-12 days; E +/- 2 SD = 6-14 days
Adding several independent tasks
E_total = sum of E
SD_total = square root of the sum of SD^2 (not the sum of SD)E = 10 आता है, जो m = 9 से ज़्यादा है; एक संख्या नहीं, range बताएँ: 8–12 या 6–14 दिन।तीन अनुमान
- 6–9Optimistic तरफ़: 3 दिन
- 9–18Pessimistic पूँछ: 9 दिन
- 1a = 6 optimistic
- 2m = 9 most likely
- 3b = 18 pessimistic
क्या रिपोर्ट करें
- 8–12
E ± SD - 6–14
E ± 2 SD
- 1E = 10 weighted mean
(a + 4m + b) / 6:mसे ज़्यादा, क्योंकि पूँछ लंबी है
दिनों में, उदाहरण task “promotion rules के टेस्ट design और execute करना” के लिए। SD = (b − a) / 6 एक अनुमान है, गारंटी वाली probability नहीं।
Work breakdown structure: हिस्सों का अनुमान लगाएँ
Work breakdown structure (WBS) टेस्टिंग को इतने छोटे tasks में बाँटता है कि उनका भरोसे से अनुमान लग सके — आम तौर पर हर एक कुछ दिनों से ज़्यादा नहीं — और हर एक का अनुमान लगाता है। यह अलग estimation तकनीक कम और वह ढाँचा ज़्यादा है जिस पर बाक़ी सभी तकनीकें काम करती हैं: three-point अनुमान या Delphi राउंड एक बड़े task की तुलना में दस छोटे tasks पर कहीं ज़्यादा सटीक होते हैं, और WBS भूला हुआ काम दिखा देता है।
- Test planning और risk analysis; requirements और acceptance criteria का review।
- हर फ़ीचर के लिए test analysis और design, test data design सहित।
- Environment, integration sandbox और test data setup।
- Automation: नए टेस्ट और मौजूदा टेस्ट का maintenance।
- Execution cycles, exploratory sessions सहित।
- डिफ़ेक्ट reporting, triage सपोर्ट, re-testing और fix के बाद regression runs।
- Non-functional testing: performance, security जाँच, accessibility, localization।
- Reporting, test completion report और hand-over।
उदाहरण: three-point और WBS से एक रिलीज़ का अनुमान
उदाहरण के लिए, Bustan Market की रिलीज़ 4.0 ("one-page checkout") लें — वही काल्पनिक सऊदी marketplace जो test plan गाइड में इस्तेमाल हुआ है। QA lead टेस्टिंग को छह tasks में बाँटता है, जो टेस्टर काम करेंगे उनसे हर task के तीन मान पूछता है, और हर task के लिए E और SD निकालता है। सभी संख्याएँ उदाहरण के लिए हैं।
- नीचे की तालिका के छह tasks: CHK-01 से CHK-05 तक का test analysis और design; environment, payment sandbox और synthetic data की तैयारी; पहला execution cycle, exploratory sessions सहित; automated regression का अपडेट और run; defect re-testing और दोबारा regression; load test, security headers की जाँच और accessibility pass।
- नतीजा: most likely मानों का जोड़ 26 person-days, E का जोड़ 28.83, कुल SD 2.5, इसलिए E ± 2 SD पर range 23.8 से 33.8 person-days। Ratio से cross-check (70 dev days × 0.40) 28 person-days देता है, जो नतीजे से मेल खाता है।
- Capacity: 3 टेस्टर × 0.75 focus factor = हर working day में 2.25 person-days; अवधि 28.83 ÷ 2.25 ≈ 12.8 working days (range 10.6 से 15.0)।
- अनुमान के साथ लिखी मान्यताएँ: build 4.0.0-rc पहले दिन मिले और smoke पास करे; payment sandbox कम से कम 90% working hours उपलब्ध रहे; design शुरू होने से पहले promotion rules freeze हों; High-risk फ़ीचर के लिए ज़्यादा से ज़्यादा एक fix-and-retest cycle।
Task (person-days) a m b E SD
T1 Test analysis and design (CHK-01..05) 3 5 9 5.33 1.00
T2 Environment, payment sandbox, synthetic data 2 3 8 3.67 1.00
T3 Execution cycle 1, incl. exploratory sessions 6 8 14 8.67 1.33
T4 Automated regression: updates and runs 2 3 5 3.17 0.50
T5 Defect re-testing and re-regression 2 4 10 4.67 1.33
T6 Load test, security headers, accessibility pass 2 3 6 3.33 0.67
---- -----
Sum of most likely (m) 26 E = 28.83
SD_total = sqrt(1.00 + 1.00 + 1.78 + 0.25 + 1.78 + 0.44) = sqrt(6.25) = 2.5
Effort range (E +/- 2 SD): 23.8 - 33.8 person-days
Cross-check (ratio 0.40 x 70 dev days): 28 person-days -> consistent
Capacity: 3 testers x 0.75 focus factor = 2.25 person-days per working day
Duration: 28.83 / 2.25 = 12.8 working days (range 10.6 - 15.0)
Assumptions: build 4.0.0-rc delivered on day 1 and passes smoke; payment sandbox
available >= 90% of working hours; promotion rules frozen before design starts;
no more than one fix-and-retest cycle for High-risk features.Range, buffer, मान्यताएँ और re-estimation
उदाहरण में तीन बातें देखें। Most likely मानों का जोड़ (26 दिन) three-point कुल (28.83) से कम है, क्योंकि हर task की pessimistic पूँछ लंबी है — "26 दिन" बताना optimistic जवाब को realistic बताकर पेश करना होता। संयुक्त SD (2.5) tasks के SD के जोड़ (5.83) से छोटा है, क्योंकि स्वतंत्र overruns आंशिक रूप से एक-दूसरे को काट देते हैं; अगर tasks स्वतंत्र नहीं हैं — एक ख़राब build सबको देर कर दे — तो असली फैलाव ज़्यादा चौड़ा है। और ratio-based cross-check नतीजे के क़रीब आता है, जो भरोसा बढ़ाता है पर कुछ साबित नहीं करता।
Estimate को उसकी मान्यताओं के साथ range के रूप में बताएँ: "24 से 34 person-days, तीन टेस्टर के साथ लगभग 11 से 15 working days, ऊपर लिखी शर्तें मानकर"। कोई भी buffer ऐसी जगह रखें जहाँ वह दिखे और उसका owner हो — go/no-go फ़ैसले और दूसरे fix cycle के लिए नामित contingency — न कि हर task को चुपचाप बढ़ाएँ, जो जोखिम छिपाता है और वैसे भी ख़र्च हो जाता है। जब कोई मान्यता टूटे, जब scope बदले, और तय बिंदुओं पर जैसे पहले execution cycle के अंत में, दोबारा estimate करें, जहाँ असली प्रगति और डिफ़ेक्ट दर से extrapolation मूल अंदाज़े की जगह लेता है।
- पूरी टेस्टिंग का अनुमान लगाएँ, सिर्फ़ execution का नहीं।
- जो लोग काम करेंगे वही अनुमान लगाएँ; राय को Delphi या planning poker से मिलाएँ।
- Range दें और उसके साथ मान्यताएँ लिखें; मान्यताओं के बिना estimate दोबारा जाँचा नहीं जा सकता।
- Contingency को साफ़ और task estimates से अलग रखें।
- हर रिलीज़ में estimate के मुक़ाबले actuals दर्ज करें; यही इतिहास अगली बार ratio-based estimate संभव बनाता है।
अक्सर पूछे जाने वाले सवाल
Three-point estimation का formula क्या है?
E = (a + 4m + b) / 6, जहाँ a optimistic, m most likely और b pessimistic अनुमान है। Standard deviation का अनुमान SD = (b − a) / 6 है, और नतीजा आम तौर पर E ± SD या E ± 2 SD जैसी चौड़ी range के रूप में बताया जाता है।
ISTQB कौन-सी test estimation तकनीकें बताता है?
CTFL v4.0 syllabus ratio पर आधारित estimation, extrapolation, Wideband Delphi और three-point estimation बताता है। Advanced Test Management syllabus estimation को test planning के हिस्से के रूप में और गहराई से कवर करता है।
प्रोजेक्ट की मेहनत का कितना हिस्सा टेस्टिंग में जाना चाहिए?
कोई सार्वभौमिक प्रतिशत नहीं है। मिलते-जुलते काम के लिए अपना historical ratio इस्तेमाल करें, और नए scope के product, process, people और अपेक्षित डिफ़ेक्ट स्तर के हिसाब से उसे बदलें। बिना संदर्भ के बताए गए इंडस्ट्री औसत ठोस आधार नहीं हैं।
Agile टीमें टेस्टिंग का अनुमान कैसे लगाती हैं?
आम तौर पर story के अनुमान के हिस्से के रूप में, relative story points में, पूरी टीम (टेस्टर सहित) के साथ planning poker से। Sprint planning में testing tasks का अनुमान घंटों में भी लगाया जा सकता है। फिर टीम की velocity पिछले स्प्रिंट से extrapolation का काम करती है।
क्या test estimate में buffer जोड़ना चाहिए?
हाँ, पर उसे दिखने दें: कारण के साथ नामित contingency, जैसे दूसरा fix-and-retest cycle या sandbox की अस्थिरता। हर task में चुपचाप जोड़ा गया padding जोखिम छिपाता है और आम तौर पर काम में ही ख़र्च हो जाता है।
Test estimate कब बदलना चाहिए?
जब भी scope बदले, जब लिखी गई कोई मान्यता ग़लत निकले, और तय checkpoints पर जैसे पहले execution cycle के अंत में, जब असली प्रगति और डिफ़ेक्ट दर extrapolation संभव बनाती हैं।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- Certified Tester Advanced Level Test Management (CTAL-TM) v3.0टेस्टिंग प्रबंधन पर ISTQB का advanced पाठ्यक्रम: टेस्ट योजना और अनुमान, risk-based testing, निगरानी, मेट्रिक्स और रिपोर्टिंग।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
- ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesटेस्ट प्रक्रिया मॉडल: संगठनात्मक, टेस्ट प्रबंधन और dynamic टेस्ट प्रक्रियाएँ, उनकी गतिविधियों और परिणामों के साथ।
- Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)एजाइल टेस्टिंग क्वाड्रेंट और टेस्टर डिलीवरी टीम के भीतर कैसे काम करते हैं — "सही परत पर टेस्टिंग" का आधार।
अभ्यास
वीडियो कंसल्टेशन रिलीज़ की टेस्टिंग का estimate लगाएँ
आप एक private clinic network के patient app (काल्पनिक) के QA lead हैं: Android और iOS apps और एक web booking portal, Arabic और English में। Release 5.0 में video consultation जुड़ता है: video slot बुक करना, consultation fee का भुगतान, app या portal से call join करना, और prescription को PDF के रूप में पाना। Development अपने काम का अनुमान 60 person-days लगाता है, और ज़्यादातर टेस्टिंग release candidate (RC) आने पर शुरू होती है। कल आपके दो टेस्टर में से एक, उमर, ने product manager के सवाल के जवाब में एक जल्दी वाला estimate भेजा; उसके बाद आपने उमर और लीना के साथ work breakdown structure (WBS) पर Wideband Delphi का एक राउंड चलाया। नीचे के material में दोनों हैं, साथ में टीम का इतिहास और product manager का सवाल।
पहला draft review करें, three-point estimate निकालें, ratio से cross-check करें, product manager को जवाब दें, और estimate वैसे लिखें जैसे आप भेजेंगे। फिर material के आख़िर में दिए checkpoint डेटा से extrapolation के ज़रिए दोबारा estimate करें। सभी संख्याएँ उदाहरण के लिए हैं। काग़ज़-कलम या कोई भी calculator इस्तेमाल करें, दो decimal तक रखें, और इसके लिए 25–30 मिनट रखें।
एक private clinic network का patient app (काल्पनिक): Android, iOS और web booking portal,
Arabic और English UI। Release 5.0 "Video consultations": video slot बुक करना,
consultation fee का भुगतान, call join करना, prescription को PDF के रूप में पाना।
5.0 के लिए development estimate: 60 person-days।
Testers: लीना और उमर, release candidate (RC) आने के बाद पूरे समय 5.0 पर।
टीम के records से focus factor: 0.8।
1) उमर का पहला draft, कल product manager को भेजा गया
"लगभग 150 test cases। हम में से हर एक दिन में 15 चलाता है, तो हम दोनों को 5 दिन
चाहिए। सुरक्षा के लिए मैंने इसे दोगुना किया: RC के बाद 10 working days। काफ़ी होगा।"
2) Work breakdown structure पर Wideband Delphi (person-days)
Round 1 में सबसे बड़ा अंतर T3 पर था (लीना m = 1, उमर m = 4)। उमर: "मेरे पिछले
प्रोजेक्ट में video vendor ने sandbox accounts approve करने में कई दिन लगाए।"
Round 2 के मान:
Task a m b कब
T1 Test planning, risk analysis, review of criteria 1 2 4 RC से पहले
T2 Test analysis and design: book, pay, call, PDF 3 4 6 RC से पहले
T3 Video and payment sandboxes, test patients/doctors 1 2 7 RC से पहले
T4 Execution cycle 1 (150 tests, incl. exploratory) 6 8 12 RC के बाद
T5 Defect re-testing and regression after fixes 2 4 8 RC के बाद
T6 Calls on weak networks, accessibility, Arabic RTL 2 3 5 RC के बाद
T7 Automated regression update, report, hand-over 1 2 4 RC के बाद
टीम की मान्यताएँ: RC आते ही smoke test पास करे; दोनों sandboxes कम से कम 90%
working hours उपलब्ध रहें; T5 मानता है कि cycle 1 में लगभग 15 डिफ़ेक्ट होंगे
और एक fix-and-retest cycle होगा।
3) Test effort / development effort, इस टीम के दर्ज actuals
Release 4.6 0.42 app में नया payment method
Release 4.7 0.15 टेक्स्ट और icon updates
Release 4.8 0.40 lab results module
Release 4.9 0.38 appointment reminders (SMS, push)
4) Product manager (नासिर), पिछले हफ़्ते की planning meeting में:
"क्या QA, RC आने के बाद 10 working days में पूरा कर सकता है?"
5) बाद में: execution cycle 1 के तीसरे दिन के अंत में checkpoint
RC तय दिन पर आया और smoke test पास किया।
150 में से 60 planned tests execute हुए। 12 डिफ़ेक्ट मिले, जिनमें से 7 payment
और call join करने में। Video sandbox आधे दिन बंद रहा।- उमर का पहला draft review करें: उसमें क्या ग़लत है, लिखें, और हर समस्या के लिए वह कारण बताएँ जो गाइड देती है।
- T1 से T7 तक हर task के लिए E = (a + 4m + b) / 6 और SD = (b − a) / 6 निकालें। फिर m का जोड़, कुल E, कुल SD (SD के वर्गों के जोड़ का वर्गमूल), और E ± SD व E ± 2 SD की ranges निकालें। सबसे अनिश्चित task कौन-सा है, और RC से पहले आप उसके बारे में क्या करेंगे?
- Ratio से cross-check करें: पिछली रिलीज़ में से मिलती-जुलती रिलीज़ चुनें, ratio-based estimate निकालें और उसकी तुलना three-point नतीजे से करें।
- Product manager को जवाब दें: RC के बाद की मेहनत (T4 से T7), हर working day में टीम की capacity, और range के साथ अवधि निकालें। क्या आप 10 working days का वादा कर सकते हैं? अगर नहीं, तो कौन-से विकल्प देंगे?
- Estimate वैसे लिखें जैसे आप भेजेंगे: range, मान्यताएँ, एक नामित contingency, और वे बिंदु जहाँ आप दोबारा estimate करेंगे।
- Checkpoint पर execution cycle 1 का अंत extrapolate करें, बताएँ कि कौन-सी मान्यताएँ टूटीं, RC के बाद के काम का forecast अपडेट करें, और तय करें कि आगे क्या करेंगे।
मॉडल उत्तर दिखाएँ
1. उमर का पहला draft एक आम फ़ेल estimate है, और इसकी हर समस्या का नाम गाइड में है। (1) सिर्फ़ execution का अनुमान: test planning और acceptance criteria का review, test analysis और design, video और payment sandboxes व test data, fix के बाद re-testing और regression, non-functional testing (कमज़ोर network पर calls, accessibility, Arabic right-to-left लेआउट), automation और reporting, सब ग़ायब हैं — यानी work breakdown के T1 से T3 और T5 से T7। (2) Product के कारक नज़रअंदाज़ हैं: तीन प्लेटफ़ॉर्म (Android, iOS, web), दो भाषाएँ और एक नया external video integration; यह भी साफ़ नहीं कि 150 test cases तीनों प्लेटफ़ॉर्म कवर करते हैं या नहीं। (3) हर टेस्टर के लिए 15 test cases प्रति दिन की दर का टीम के records में कोई स्रोत नहीं है, और कुछ नहीं दिखाता कि इसमें वह 0.8 का focus factor शामिल है जो वही records देते हैं: दो टेस्टर हर working day में लगभग 1.6 person-days का टेस्ट काम देते हैं, 2 नहीं। (4) दोगुना करना बिना कारण और बिना owner का padding है, नामित contingency नहीं। यह ठीक उन 10 दिनों पर आकर रुकता है जिनके बारे में product manager ने पिछले हफ़्ते की planning meeting में पूछा था, जिससे लगता है कि जवाब scope से आगे की ओर नहीं, तारीख़ से पीछे की ओर निकाला गया। (5) Rework को नज़रअंदाज़ किया गया: draft मानता है कि RC टेस्ट लायक है और किसी डिफ़ेक्ट को re-test नहीं करना पड़ेगा, और sandboxes पर निर्भरता लिखी नहीं गई। (6) यह एक व्यक्ति की एक संख्या है, बिना range या मान्यताओं के, और "काफ़ी होगा" को वादा समझा जाएगा।
2. Three-point estimate। T1: E = (1 + 8 + 4) / 6 = 2.17, SD = (4 − 1) / 6 = 0.50। T2: E = 25 / 6 = 4.17, SD = 0.50। T3: E = 16 / 6 = 2.67, SD = 1.00। T4: E = 50 / 6 = 8.33, SD = 1.00। T5: E = 26 / 6 = 4.33, SD = 1.00। T6: E = 19 / 6 = 3.17, SD = 0.50। T7: E = 13 / 6 = 2.17, SD = 0.50। m का जोड़ = 25 person-days; कुल E = 162 / 6 = 27.00 (rounded कॉलम का जोड़ 27.01 आता है)। कुल SD = sqrt(0.25 + 0.25 + 1 + 1 + 1 + 0.25 + 0.25) = sqrt(4.00) = 2.00, जबकि SD का सीधा जोड़ 5.00 है। Range: E ± SD पर 25 से 29 person-days; E ± 2 SD पर 23 से 31 person-days। 25 बताना — यानी most likely मानों का जोड़ — optimistic जवाब को realistic बताकर पेश करना होता।
T3, T4 और T5 का SD सबसे बड़ा (1.00) और बराबर है, पर अपने आकार के हिसाब से T3 सबसे अनिश्चित है: most likely मान 2 के लिए यह 1 से 7 person-days तक फैला है, vendor के sandbox approvals के साथ उमर के अनुभव की वजह से। Delphi का पहला राउंड इसी के लिए था: सबसे अलग अनुमान वाले ने बताया कि वह क्या जानता है, टीम ने दोबारा अनुमान लगाया, और जोखिम बहस में खोने की जगह अब b में दिखता है। इंतज़ार न करें: video और payment sandbox accounts और test doctors के accounts अभी, development के दौरान ही, माँगें, और "T3 ख़त्म होने से पहले sandbox accounts approve हों" को मान्यता के रूप में दर्ज करें। सबसे बड़े tasks T4 और T5 का फ़ासला भी उतना ही (6 person-days) है, और दोनों RC की गुणवत्ता पर निर्भर हैं, इसलिए वे स्वतंत्र नहीं: RC ख़राब हुआ तो दोनों साथ में overrun होंगे और असली फैलाव 2.00 से ज़्यादा चौड़ा होगा।
3. Ratio से cross-check। Release 4.7 (टेक्स्ट और icon updates) नए external integration वाली रिलीज़ जैसी नहीं है, इसलिए उसे छोड़ दें। बाक़ी तीन — नया payment method, नया module, SMS और push से reminders — मिलती-जुलती हैं: (0.42 + 0.40 + 0.38) / 3 = 0.40, और 0.40 × 60 = 24 person-days। 4.7 को शामिल करने पर औसत 0.3375 और लगभग 20 person-days आता, जो कम आँकना होता। 24 की तुलना कुल E 27 से करें, RC के बाद के काम से नहीं, क्योंकि ratios पूरी टेस्टिंग को कवर करते हैं। 24 range 23 से 31 के अंदर है और E से थोड़ा नीचे, जो नए video vendor, तीन प्लेटफ़ॉर्म और कमज़ोर network की टेस्टिंग वाली रिलीज़ के लिए समझ में आता है। Cross-check भरोसा बढ़ाता है, पर कुछ साबित नहीं करता।
4. Product manager का सवाल। T1 से T3 (E = 54 / 6 = 9.00 person-days) development चलते समय ही होते हैं, इसलिए RC के बाद सिर्फ़ T4 से T7 गिने जाते हैं: E = 108 / 6 = 18.00 person-days, SD = sqrt(1 + 1 + 0.25 + 0.25) = sqrt(2.5) = 1.58, तो E ± 2 SD = 14.84 से 21.16 person-days। Capacity: 2 टेस्टर × 0.8 = हर working day में 1.6 person-days। अवधि: 18.00 / 1.6 = 11.25 working days, range 14.84 / 1.6 = 9.3 से 21.16 / 1.6 = 13.2 working days। 10 working days में 16 person-days की capacity है, जो E से कम है: यह तभी संभव है जब काम most likely से बेहतर चले, इसलिए इसका वादा न करें। इसकी जगह विकल्प दें और फ़ैसला product manager को करने दें: तारीख़ रखें और तय करें कि कम-risk वाले कौन-से टेस्ट घटाए जाएँगे, बचा हुआ जोखिम दर्ज करके; RC के बाद capacity बढ़ाएँ (काग़ज़ पर तीसरा टेस्टर हर दिन 2.4 person-days देता है और 18 / 2.4 = 7.5 working days, पर नए व्यक्ति को product सीखने में समय लगता है, इसलिए उसके साथ दोबारा estimate करें); कुछ काम RC से पहले करें, जैसे T7 का automated regression update और शुरुआती builds पर accessibility जाँच; या लगभग 11 working days और नीचे दी गई contingency स्वीकार करें।
5. Estimate, जैसे आप भेजेंगे: "Release 5.0 (video consultations) की टेस्टिंग: लगभग 27 person-days, range 23 से 31, सात tasks के three-point estimate से, जो उन दो टेस्टर ने लगाया जो काम करेंगे; तीन मिलती-जुलती रिलीज़ का ratio 24 देता है। लगभग 9 person-days RC से पहले होते हैं। RC के बाद: लगभग 18 person-days, यानी दो टेस्टर के साथ लगभग 11 working days (range 9 से 13), इसलिए 10 working days का वादा नहीं किया जा सकता; विकल्प साथ में हैं। मान्यताएँ: RC तय दिन पर आए और smoke test पास करे; video और payment sandboxes कम से कम 90% working hours उपलब्ध रहें, और accounts T3 ख़त्म होने से पहले approve हों; cycle 1 में लगभग 15 डिफ़ेक्ट और एक fix-and-retest cycle; scope वही जो T1 में review हुए acceptance criteria में है; RC के बाद लीना और उमर पूरे समय 5.0 पर, focus factor 0.8। Contingency, go/no-go फ़ैसले के लिए product manager के पास: payment और call join करने के लिए दूसरा fix-and-retest cycle, लगभग 4 person-days (2.5 working days)। हम execution cycle 1 के तीसरे दिन के अंत में, cycle 1 के अंत में, और जब भी scope बदले या कोई मान्यता टूटे, दोबारा estimate करेंगे।" Contingency का आकार T5 के most likely मान से लिया गया है, और वह task estimates से बाहर रखी गई है, tasks में चुपचाप बाँटी नहीं गई।
6. Checkpoint। Extrapolation: 3 working days में 60 टेस्ट, यानी 20 प्रति दिन; बाक़ी 90 को 4.5 दिन और चाहिए, इसलिए cycle 1 लगभग 5.2 (8.33 / 1.6) की जगह 7.5 working days लेगा। 7.5 × 1.6 = 12 person-days: T4 अपने pessimistic मान पर चल रहा है। डिफ़ेक्ट: 60 टेस्ट में 12; इस दर से cycle के अंत तक लगभग 30, यानी माने गए 15 के दोगुने — यह सिर्फ़ मोटा संकेत है, क्योंकि cycle के दौरान डिफ़ेक्ट की दर बदलती है। दो मान्यताएँ टूटीं: डिफ़ेक्ट की संख्या, और sandbox की उपलब्धता (3 में से 2.5 दिन, लगभग 83%, 90% से कम); RC वाली मान्यता टिकी रही। RC के बाद का अपडेटेड forecast: T4 12 + T5 लगभग 8 (डिफ़ेक्ट की संख्या के हिसाब से बढ़ाया गया, जो उसका pessimistic मान है, जब तक लीना और उमर उसका दोबारा estimate न करें) + T6 3.17 + T7 2.17 = 25.33 person-days (rounded मान जोड़ें तो 25.34), यानी RC के बाद 11.25 की जगह 25.33 / 1.6 = 15.8 working days — मूल range 9 से 13 के बाहर, और आज से लगभग 12.8 working days बाक़ी। T4 और T5 साथ-साथ खिसके, जैसा एक ही build पर निर्भर tasks से उम्मीद होती है।
अब क्या करें: नया forecast और दोनों टूटी मान्यताएँ product manager को आज ही बताएँ, cycle के अंत में नहीं; बाक़ी T4 और T5 के लिए लीना और उमर से नए three-point मान लें; बचे हुए high-risk टेस्ट (payment, call join करना) पहले चलाएँ, ताकि scope पर कोई भी फ़ैसला कम-risk वाले टेस्ट हटाए; डिफ़ेक्ट का जमाव — 12 में से 7 payment और call join करने में — development lead के साथ साझा करें, क्योंकि यही re-testing की मेहनत तय करता है; sandbox के बंद होने का मुद्दा vendor के साथ संबंध के owner तक पहुँचाएँ; और product manager को बताएँ कि contingency वाला दूसरा fix-and-retest cycle अब शायद ज़रूरी होगा। रिलीज़ के अंत में estimate के मुक़ाबले असली मेहनत दर्ज करें, ताकि 5.0 अगले ratio के लिए एक data point बने।
अगर आपकी संख्याएँ अलग हैं, तो जाँचें: E में 4 × m है; कुल SD, SD के वर्गों के जोड़ का वर्गमूल है, उनका जोड़ नहीं; capacity में focus factor लगा है; ratio में सिर्फ़ मिलती-जुलती रिलीज़ हैं और उसकी तुलना कुल E से हुई है; और अवधि = person-days ÷ हर working day के person-days। दूसरे decimal में rounding के अंतर ठीक हैं।
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।
QA रोडमैप का हिस्सा
इस topic से पहले
अगले topics
इस गाइड में बताए गए टूल्स
थ्री-पॉइंट फ़ॉर्मूले से टेस्टिंग effort का अनुमान लगाएँ: टास्क के optimistic, most likely और pessimistic मान लिखें और PERT एस्टिमेट, range और टीम के दिन पाएँ।
फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।
Mutqan AI से किसी फ़ीचर या रिलीज़ के जोखिम पहचानें और प्राथमिकता-क्रम में risk-based टेस्ट प्लान बनाएँ।
क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।
बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।