डिफ़ेक्ट मेट्रिक्स
Defect metrics वे numbers हैं जो आपके tracker के defect records से निकाले जाते हैं: कितने defects मिले, कहाँ मिले, कितने गंभीर थे, कितने समय तक खुले रहे, fix के बाद कितने वापस आए और कितने users तक पहुँच गए। ISTQB Foundation syllabus testing की monitoring में इस्तेमाल होने वाले metrics में defect metrics गिनाता है, जैसे मिले और fix हुए defects की संख्या, defect density और defect detection percentage।
एक सरल उदाहरण: testers को release से पहले 48 defects मिले, और users ने पहले 30 दिनों में 12 और report किए। Defect detection percentage = 48 ÷ 60 = 80% है: एक महीने बाद तक पता चले हर पाँच defects में से चार testing ने पकड़े, और 20% escape हो गए।
यह क्यों ज़रूरी है
सैकड़ों defects वाला tracker तब तक कुछ नहीं बताता जब तक उसका सार न निकाला जाए। कुछ साफ़ परिभाषित numbers उन सवालों का जवाब देते हैं जिन पर टीम को फ़ैसला करना होता है: क्या release तैयार है, किस component को ज़्यादा testing या redesign चाहिए, क्या fixes ठीक से हो रहे हैं, और क्या testing ज़रूरी defects users से पहले पकड़ रही है?
Tester के लिए ये दो बार मायने रखते हैं। Raw data आप ही बनाते हैं, क्योंकि हर report, severity और status change इन numbers में जाता है, और लापरवाह records ग़लत metrics देते हैं। और अक्सर इन्हें समझाने के लिए आपसे ही कहा जाता है: "Escape rate इसलिए बढ़ा क्योंकि नए SMS provider को सिर्फ़ उसके sandbox में टेस्ट किया गया" टीम के लिए "20%" से कहीं ज़्यादा उपयोगी है।
मुख्य defect metrics और उनके formulas
हर metric एक ratio, समय की अवधि या count है, जो उन fields से निकलता है जो आप पहले से record करते हैं: बनने और बंद होने की तारीख़, severity, component, status history, और defect कहाँ मिला (कोई test level या production)। सिर्फ़ valid defects गिनें: duplicates और "defect नहीं है" कहकर reject हुई reports बाहर रखें।
- Defect density = defects ÷ work product का size, जैसे हज़ार lines of code (KLOC), function points या stories। इससे अलग-अलग size वाले हिस्सों की तुलना होती है: छोटे module में 20 defects बड़े module के 30 से बुरे हो सकते हैं।
- Defect detection percentage (DDP) = testing में मिले defects ÷ (testing में मिले + बाद में मिले) × 100, जहाँ "बाद में" की window पहले से तय होती है, जैसे production के पहले 30 दिन। ISTQB glossary इसे किसी test level के लिए परिभाषित करता है, इसलिए आप इसे सिर्फ़ system testing के लिए भी निकाल सकते हैं।
- Escape rate = बाद में मिले defects ÷ वही कुल; यह DDP का पूरक है। कुछ टीमें इसे defect leakage कहती हैं, और कुछ कुल संख्या की जगह testing में मिले defects से भाग देती हैं, इसलिए तुलना से पहले formula जाँच लें।
- Defect age = report से closure तक का समय, या खुले defect के लिए आज तक का। Median (ages को क्रम से लगाने पर बीच वाला मान) और हर severity का सबसे पुराना defect report करें, सिर्फ़ average नहीं।
- Reopen rate = reopen हुए defects ÷ उसी अवधि में resolve हुए defects। Defect तब reopen होता है जब confirmation testing दिखाए कि fix ने काम नहीं किया, या failure लौट आए।
- Distribution = किसी एक attribute के हिसाब से defects का बँटवारा: severity, component, कहाँ मिला या root cause। यह बताता है कि कहाँ action लेना है; कोई भी कुल संख्या यह नहीं बताती।
Worked example: clinic booking app की एक release
Clinic appointment-booking app की release 3.4 live होने के 30 दिन बाद QA lead retrospective तैयार करता है। Tracker में testing की 55 reports थीं; 4 duplicates थीं और 3 "works as designed" कहकर reject हुईं, यानी 48 valid defects बचे। Users और support ने 12 और report किए। नीचे का block साफ़ किया गया data और results दिखाता है; QA lead इन्हें ऐसे पढ़ता है:
- DDP 80% है, जो ठीक लगता है, लेकिन escape हुए defects में से एक Critical है: दो patients एक ही slot book कर सकते थे (hotfix से ठीक हुआ)। उपयोगी सवाल यह है कि system testing concurrent bookings क्यों नहीं पकड़ पाई, यह नहीं कि 80% अच्छा है या नहीं।
- Booking में सबसे ज़्यादा defects (27) हैं, लेकिन Notifications, जो SMS reminders का नया code है, की density लगभग दोगुनी है: 8.4 बनाम 4.5 प्रति KLOC। अगली release में इस पर ज़्यादा ध्यान चाहिए।
- Reopen rate 12% है, और reopen हुए 6 में से 4 defects Payments में हैं: संकेत है कि वहाँ fixes सिर्फ़ एक path पर confirm होते हैं, इसलिए टीम अपने confirmation tests में refunds भी जोड़ती है।
- 60 में से 17 defects का root cause requirements में है, जो ज़्यादा test cases लिखने की बजाय requirements को पहले review करने का तर्क है।
- 10 defects अभी खुले हैं, उनमें कोई Blocker या Critical नहीं। उनकी mean age 16.6 दिन और median 4.5 दिन है: ज़्यादातर नए हैं, और दो पुराने defects mean को ऊपर खींचते हैं। असली बात एक Major defect है जो SMS provider के इंतज़ार में 60 दिन से खुला है, और एक Trivial जो 75 दिन से खुला है और जिसे fix या साफ़ फ़ैसले से defer करना चाहिए।
Age = defect report होने के बाद से दिन। कोई Blocker या Critical defect खुला नहीं है। Mean, 16.6 दिन, दो पुराने defects की वजह से ऊपर जाता है, पर उनका नाम नहीं बताता।
Release 3.4, clinic booking app: tracker export 30 days after go-live
Found before release 55 reports - 4 duplicates - 3 rejected = 48 defects
Found in production first 30 days = 12 defects
(1 Critical, 3 Major, 8 Minor)
DDP 48 / (48 + 12) = 80%
Escape rate 12 / 60 = 20%
Reopen rate 6 reopened / 50 resolved = 12% (4 of the 6 in Payments)
Component Defects Changed KLOC Density
Booking 27 6.0 4.5 per KLOC
Payments 12 3.0 4.0 per KLOC
Notifications 21 2.5 8.4 per KLOC
Root cause (60) requirements 17 | code 31 | environment 8 | data 4
Open defects (10) Major 3 | Minor 5 | Trivial 2 (no Blocker or Critical)
Age in days Major 1, 4, 60 | Minor 2, 2, 3, 6, 8 | Trivial 5, 75
mean 16.6 | median 4.5Defect metrics को ध्यान से पढ़ना
दो numbers की तुलना से पहले जाँचें कि दोनों एक ही तरीके से गिने गए हैं, और पूछें कि उन्हें और क्या समझा सकता है।
- तय नियम: valid defect की एक ही परिभाषा, severity और classification का एक ही scale (IEEE 1044 software anomalies को classify करने का एक standard scheme है), और एक ही window। 7 दिन बाद मापा गया escape rate 90 दिन बाद मापे गए rate से तुलना योग्य नहीं।
- Percentages के साथ counts: छोटी संख्याएँ बहुत झूलती हैं। 10 में से 2 escapes 20% है; एक और हो तो 11 में से 3, यानी 27%।
- Snapshots नहीं, trends: किसी component या टीम की तुलना उसकी अपनी पिछली releases से करें, किसी दूसरे product से नहीं।
- Context: कम defects का मतलब अच्छा code भी हो सकता है और कम testing भी, और ऊँची density कमज़ोर code भी दिखा सकती है और गहरी testing भी। पहला testing principle यही कहता है: testing defects की मौजूदगी दिखाती है, उनकी ग़ैरमौजूदगी नहीं।
- जोड़ियों में पढ़ें: DDP को escape हुए defects की severity के साथ, defect age को severity के साथ, और density को उस हिस्से की testing की मात्रा के साथ।
Defect metrics का दुरुपयोग कैसे होता है
Defect metrics एक product और एक process का वर्णन करते हैं। ये तब बिगड़ते हैं जब लोगों के targets बन जाते हैं: जब कोई number तारीफ़ या दोष तय करने लगे, तो लोग quality की जगह number को manage करने लगते हैं; इस असर को आमतौर पर Goodhart’s law कहा जाता है।
- Performance score के रूप में bugs per tester: एक problem कई reports में बँट जाती है, कठिन investigation टाली जाती है, और testers developers की मदद की जगह आपस में होड़ करते हैं।
- Defects per developer: हर report बहस बन जाती है, और problems बिना record के chat में चुपचाप fix होती हैं।
- "Defect age 10 दिन से कम" जैसा target: defects "cannot reproduce" कहकर बंद या बिना सहमति defer कर दिए जाते हैं, और age सुधर जाती है जबकि users इंतज़ार करते रहते हैं।
- Escape rate या reopen rate पर target: production defects को change requests का नाम दे दिया जाता है, और reopen हुए defects नए defects के रूप में दर्ज होते हैं।
- टीमों की league tables: अलग products, risks और reporting की आदतें तुलना को बेमतलब बना देती हैं, और टीमें कम report करना सीख जाती हैं।
आम गलतियाँ
- Duplicates और reject हुई reports गिनना, जिससे कुल संख्या tracker के शोर के साथ बढ़ती है।
- Percentage को उसके counts और window के बिना report करना: "escape rate 20%", कितने defects में से, और किस अवधि में?
- सिर्फ़ mean defect age report करना, जिससे सबसे पुराना Major या Critical defect छिपा रह जाता है।
- कम defects को quality का सबूत मान लेना, बिना पूछे कि कितना टेस्ट हुआ।
- उन टीमों या products के बीच defect density की तुलना करना जो size और severity अलग तरह से मापते हैं।
QA का नज़रिया
असली टीम में आपका पहला योगदान साफ़ data है: सही severity और component, defect कहाँ मिला, duplicates को link करके बंद करना, और fix पता चलने पर root cause दर्ज करना। ये fields और गिनती के नियम release की शुरुआत में QA lead के साथ तय करें।
Triage, release review या retrospective में metrics रखते समय counts, trend और एक वाक्य की व्याख्या लाएँ, और एक proposal से ख़त्म करें: "Reopen हुए 6 में से 4 defects Payments में हैं; क्या हम confirmation tests में refunds जोड़ें?" पूछें कि number किस फ़ैसले में मदद करता है, और इससे लोगों की ranking न करें।
अभ्यास
एक sprint के defect metrics निकालें और पढ़ें
एक online shop ने 14 दिन पहले दो हफ़्ते का sprint release किया। नीचे का export पहले से साफ़ है: कोई duplicate या reject हुई report नहीं। "production" का मतलब है कि users ने release के बाद report किया। Age report से closure तक के दिन हैं, या defect अभी खुला हो तो आज तक के।
Metrics निकालें, फिर sprint retrospective के लिए तीन वाक्यों का summary लिखें।
Changed in the sprint (KLOC): Checkout 1.5 | Search 2.0 | Profile 1.0
ID Severity Component Found in Status Age Reopened Root cause
SP-01 Major Search testing Closed 3 no code
SP-02 Minor Search testing Closed 2 yes code
SP-03 Critical Checkout testing Closed 1 no requirements
SP-04 Major Checkout testing Closed 5 yes requirements
SP-05 Minor Profile testing Closed 2 no code
SP-06 Minor Checkout testing Open 4 no requirements
SP-07 Trivial Profile testing Open 26 no code
SP-08 Major Checkout testing Closed 6 yes code
SP-09 Minor Search testing Open 9 no environment
SP-10 Major Checkout production Open 3 no requirements
SP-11 Minor Profile production Closed 2 no code
SP-12 Major Checkout production Open 12 no requirements- DDP और escape rate निकालें।
- Closed defects का reopen rate निकालें।
- खुले defects की mean और median age निकालें, और हर severity का सबसे पुराना खुला defect बताएँ।
- हर component की density निकालें, और root cause के distribution में जो बात अलग दिखे उसे पहचानें।
- हर percentage के साथ counts और एक proposal के साथ summary लिखें।
मॉडल उत्तर दिखाएँ
DDP: testing में 9 और production में 3 defects मिले, तो DDP = 9 ÷ 12 = 75% और escape rate = 3 ÷ 12 = 25%। Escape हुए तीन में से दो Major हैं, दोनों Checkout में।
Reopen rate: 7 defects closed हैं और उनमें से 3 reopen हुए थे (SP-02, SP-04, SP-08): 3 ÷ 7 ≈ 43%। इनमें से दो Checkout में हैं।
खुले defects: SP-10 (3 दिन), SP-06 (4), SP-09 (9), SP-12 (12), SP-07 (26)। Mean = 54 ÷ 5 = 10.8 दिन, median = 9 दिन। हर severity का सबसे पुराना: Major SP-12 (12 दिन, production defect), Minor SP-09 (9 दिन), Trivial SP-07 (26 दिन)।
Density: Checkout 6 ÷ 1.5 = 4.0 प्रति KLOC, Search 3 ÷ 2.0 = 1.5, Profile 3 ÷ 1.0 = 3.0। Root cause: requirements 5, code 6, environment 1, और requirements वाले सभी 5 defects Checkout में हैं।
एक संभावित summary: "Testing ने 12 ज्ञात defects में से 9 पकड़े (DDP 75%); escape हुए दोनों Major defects Checkout में हैं और requirements से जुड़े हैं। Checkout की density सबसे ज़्यादा है (4.0 प्रति KLOC), requirements वाले सभी 5 defects और 3 में से 2 reopens वहीं हैं, इसलिए हम अगले sprint से पहले product owner के साथ उसके acceptance criteria review करने का प्रस्ताव रखते हैं। SP-12, production का Major defect जो 12 दिन से खुला है, को आज ही owner चाहिए।" सिर्फ़ 12 defects में हर defect percentage को लगभग 8 points बदल देता है, इसीलिए counts साथ लिखे गए हैं।
अक्सर पूछे जाने वाले सवाल
अच्छा defect detection percentage कितना होता है?
कोई universal target नहीं है: यह product, window और गिनती के नियमों पर निर्भर करता है। अपनी releases की समय के साथ तुलना करें और देखें कि escape हुए defects कितने गंभीर थे; बिना Critical escapes वाला stable DDP कहीं और से उधार लिए number से ज़्यादा बताता है।
Defect age के लिए average की जगह median क्यों?
Defect ages skewed होती हैं: ज़्यादातर defects कुछ दिनों में बंद हो जाते हैं, कुछ हफ़्तों तक खुले रहते हैं। Mean उन कुछ के पीछे चलता है, median सामान्य defect दिखाता है। Median के साथ हर severity का सबसे पुराना खुला defect report करें।
क्या defect metrics से testers या developers का मूल्यांकन करना चाहिए?
नहीं। Per-person counts को आसानी से game किया जा सकता है, और ये उस collaboration और prevention work को हतोत्साहित करते हैं जो defects घटाते हैं। Defect metrics को team या component level पर बेहतर सवाल पूछने के लिए इस्तेमाल करें, और किसी व्यक्ति के काम पर बातचीत में चर्चा करें।
Defect metrics का data कहाँ से आता है?
Defect tracker से: बनने और बंद होने की तारीख़ें, status history, severity, component, कहाँ मिला और root cause। Support tickets या incidents से आए production defects उसी tracker में दर्ज या उससे linked होने चाहिए, ताकि वे उन्हीं नियमों से गिने जा सकें।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
- Certified Tester Advanced Level Test Management (CTAL-TM) v3.0टेस्टिंग प्रबंधन पर ISTQB का advanced पाठ्यक्रम: टेस्ट योजना और अनुमान, risk-based testing, निगरानी, मेट्रिक्स और रिपोर्टिंग।
- IEEE 1044-2009 — IEEE Standard Classification for Software Anomaliesसॉफ़्टवेयर anomalies — defects, failures और उनके प्रभाव — को वर्गीकृत करने के मानक शब्द और एट्रिब्यूट (IEEE इसे inactive-reserved सूचीबद्ध करता है)।
Mutqan tools से अभ्यास करें
प्रतिशत, प्रतिशत परिवर्तन, वृद्धि/कमी और X, Y का कितना प्रतिशत है — सब गिनें।
दो तारीख़ों के बीच सटीक अंतर वर्ष, महीने, दिन, घंटे और कुल इकाइयों में निकालें।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।