मॉड्यूल 25 · प्रोफ़ेशनल QA और टेस्ट मैनेजमेंट

QA मेट्रिक्स और KPIs

Mutqan Soft QA टीम द्वारा · · 19 मिनट · उन्नत

Metric तय तरीके से किया गया measurement है: क्या गिना जाता है, कैसे, और किस data से। Key performance indicator (KPI) उन गिने-चुने metrics में से एक है जिन्हें किसी business goal की ओर progress दिखाने के लिए चुना जाता है, और उसके साथ एक owner, एक target, action trigger करने वाले thresholds और एक तय review होता है। "पिछली रात के regression run का pass rate" team का metric है; "हर release में customers को मिले Critical defects" पूरे QA function का KPI हो सकता है।

यह lesson दिखाता है कि business goal से छोटा KPI set कैसे बनाएँ, उसे leadership के सामने कैसे रखें, teams की निष्पक्ष तुलना कैसे करें, और गढ़े हुए return-on-investment आँकड़ों की जगह cost-of-quality model से testing की value कैसे समझाएँ।

यह क्यों ज़रूरी है

तय KPIs के बिना quality की बातचीत राय पर या सबसे आसानी से मिलने वाले number पर लौट आती है, अक्सर test cases की गिनती पर। तब leadership testing को अंदाज़े से fund करती है और quality का हाल customer complaints से जानती है।

Lead role की ओर बढ़ रहे tester के लिए KPIs और cost of quality budget meetings और release decisions की भाषा हैं। "पिछली तिमाही escaped defects से तीन hotfixes हुए और लगभग 90 घंटे support में गए; हमारा प्रस्ताव यह है" कहना "हमें और testers चाहिए" से ज़्यादा वज़न रखता है, बशर्ते हर number असली data तक trace हो।

Metrics, KPIs, leading और lagging indicators

ISTQB Foundation syllabus testing में इस्तेमाल होने वाले metrics को project progress, test progress, product quality, defect, risk, coverage और cost metrics में बाँटता है। रोज़ के काम को दिशा देने के लिए एक team इनमें से दर्जनों track कर सकती है।

KPI शब्द general management practice से आया है और ढीले-ढाले तरीके से इस्तेमाल होता है। एक उपयोगी working definition: कोई metric तब KPI बनता है जब वह किसी business goal को track करे, उसका नामित owner, target और तय actions वाले thresholds हों, और फ़ैसला लेने वाले लोग उसे तय cadence पर review करें। हर KPI एक metric है; ज़्यादातर metrics को कभी KPI नहीं बनना चाहिए।

Metric एक चीज़ को तय तरीके से मापता है; KPI business goal से जुड़े गिने-चुने metrics में से एक है, जिसका owner, target, thresholds और तय review होता है।

मेट्रिक

तय तरीके से किया गया measurement: क्या गिना जाता है, कैसे, और किस data से

किस सवाल का जवाब:
इस measure की value अभी क्या है?
उदाहरण:
पिछली रात के regression run का pass rate
Target और thresholds:
अक्सर नहीं; context में और trend के रूप में पढ़ा जाता है
Owner और पाठक:
वह team जो इसे जुटाती और इस्तेमाल करती है
Review cadence:
जितनी बार उपयोगी हो, अक्सर रोज़
कितने:
जितने team को चाहिए, अक्सर दर्जनों

KPI

Business goal track करने के लिए चुना गया metric, owner, target और thresholds के साथ

किस सवाल का जवाब:
क्या हम business goal की ओर सही रास्ते पर हैं?
उदाहरण:
हर release में customers को मिले Critical defects
Target और thresholds:
हमेशा: एक target, और तय action वाले thresholds
Owner और पाठक:
नामित owner; फ़ैसला लेने वाले लोग review करते हैं
Review cadence:
तय: हर sprint, महीने या release पर; set खुद हर तिमाही
कितने:
हर business goal पर तीन से पाँच

हर KPI एक metric है; ज़्यादातर metrics कभी KPI नहीं बनते।

  • Lagging indicator — किसी outcome को उसके हो जाने के बाद मापता है: customers को मिले defects, production incidents, change fail rate (उन deployments का हिस्सा जिनके बाद rollback या hotfix जैसा तुरंत दख़ल चाहिए)। यह भरोसेमंद है, पर जिस release के बारे में है उसे बदलने के लिए बहुत देर से आता है।
  • Leading indicator — पहले बदलता है और उम्मीद होती है कि outcome को predict करेगा: release से पहले passing tests वाले high risks, development से पहले review हुए acceptance criteria वाली stories, regression suite का flaky rate। इस पर समय रहते action लिया जा सकता है, पर outcome से इसका रिश्ता एक assumption है।
  • दोनों की जोड़ी बनाएँ: हर lagging KPI के लिए एक या दो leading indicators जिन्हें team इसी sprint में बदल सके, और हर leading indicator को कई releases तक उसके KPI से मिलाकर देखें। अगर risk coverage बढ़े पर escapes न घटें, तो leading indicator गलत चीज़ माप रहा है।

KPI set बनाना: business goal से indicators तक

Test metrics guide के दो विचार KPIs के लिए और भी ज़रूरी हैं। Dashboard से नहीं, decision से शुरू करें: जिस number पर कोई action नहीं लेगा, वह set में नहीं होना चाहिए। और Goodhart’s law: जब कोई measure ऐसा target बन जाए जिस पर लोगों को परखा जाता है, तो वे quality की जगह number सुधारते हैं, इसलिए test cases की गिनती या प्रति tester bugs खराब KPIs हैं। हर KPI को लिखित definition और gaming पकड़ने वाला counter-metric दें।

KPI tree इस chain को साफ़ दिखाता है: एक business goal, उसे support करने वाला quality objective, एक या दो lagging KPIs, वे leading indicators जिन्हें team बदल सकती है, और उन्हें feed करने वाला data। उदाहरण एक food-delivery app का है; उसकी baselines उसकी अपनी पिछली तीन releases से हैं।

  • Targets और thresholds — target वह है जहाँ आप पहुँचना चाहते हैं; हर threshold band का तय action होता है (amber: weekly review में चर्चा; red: release owner स्पष्ट फ़ैसला लेता है)। इन्हें अपनी baseline से तय करें, दूसरी companies के benchmarks से नहीं।
  • Review cadence — leading indicators हर sprint में team के साथ, lagging KPIs हर महीने या हर release पर leadership के साथ, और set खुद हर तिमाही: जो indicators अब फ़ैसले नहीं चलाते उन्हें हटाएँ।
  • Definitions — लिखें कि क्या गिना जाता है और क्या बाहर है, data source, counting window (जैसे release के 30 दिन बाद तक) और owner, ताकि अगली तिमाही का number भी वही अर्थ रखे।
BUSINESS GOAL      More repeat orders
QUALITY OBJECTIVE  Customers rarely meet a checkout defect in production

LAGGING KPIs (per release, reviewed with leadership)
  K1  Customer-found Critical/Major checkout defects, 30-day window
      baseline 5 · target <= 2 · amber 3 · red >= 4
  K2  Change fail rate of the checkout service (DORA definition)
      baseline 14% · target <= 10% · amber > 10% and <= 15% · red > 15%

LEADING INDICATORS (per sprint, reviewed by the team)
  L1  High checkout risks covered by passing tests at release     -> K1
      target 100% · red < 95% (release owner decides explicitly)
  L2  Checkout stories with acceptance criteria reviewed by QA
      before development                                          -> K1
      target >= 90% · red < 75%
  L3  Flaky rate of the checkout regression suite                 -> K2
      target < 2% · red > 5%

DATA  CI test results · defect tracker · deployment log ·
      support tickets tagged "checkout"

आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर आज़माएँ: प्रतिशत कैलकुलेटर

Leadership dashboards और teams की निष्पक्ष तुलना

Leadership dashboard एक मिनट से कम में तीन सवालों के जवाब देता है: क्या हम सही रास्ते पर हैं, हालात सुधर रहे हैं या बिगड़ रहे हैं, और क्या कोई फ़ैसला चाहिए? Teams की तुलना वह जगह है जहाँ KPIs सबसे ज़्यादा नुकसान करते हैं: अलग products, risk levels और counting rules ऐसे कारणों से अलग numbers देते हैं जिनका team की testing की गुणवत्ता से कोई लेना-देना नहीं।

  • हर goal के लिए तीन से पाँच KPIs दिखाएँ, हर एक के साथ छह periods का trend, target, band शब्दों में (on track, at risk, off track), सिर्फ़ रंग से नहीं, data की तारीख़ और source, और एक वाक्य की interpretation।
  • आख़िर में ask लिखें: कौन-सा फ़ैसला या support चाहिए और कब तक।
  • निष्पक्ष तुलना करें: वही लिखित definitions और counting window, raw counts की जगह rates (प्रति release या प्रति 100 changes escaped defects), और हर team की तुलना पहले उसकी अपनी baseline से।
  • Cross-team views से अपनाने लायक practices ढूँढें, teams या लोगों की ranking कभी न करें; जब ranking bonus तय करने लगती है, numbers ईमानदार नहीं रहते।

आज़माएँ: Markdown को PDF में बदलें

Cost of quality: चार categories

General quality management से लिया गया cost-of-quality model organisation के quality की वजह से हुए खर्च को चार categories में बाँटता है: पहली दो quality सही पाने के लिए खर्च होती हैं, आख़िरी दो defects की कीमत हैं। कुछ testing texts appraisal को "detection" कहते हैं। Reviews work products में defects ढूँढते हैं, इसलिए ज़्यादातर teams उन्हें appraisal गिनती हैं, जबकि कुछ भी बनने से पहले acceptance criteria पर सहमति काम करने का तरीका बदलती है और prevention गिनी जाती है। रेखा जहाँ भी खींचें, हर तिमाही उसे एक ही तरह खींचें।

  • Prevention — secure coding की training, development से पहले acceptance criteria पर सहमति, coding standards, retrospective में मिले root cause को ठीक करना।
  • Appraisal — tests design करना और चलाना, reviews, static analysis, test environments और test data, test automation का रखरखाव।
  • Internal failure — release से पहले मिले defects: उनकी जाँच, fix और retest, और fix का इंतज़ार करता build।
  • External failure — customers को मिले defects: hotfixes, support calls, refunds, incident handling, contractual penalties, और वे खोए customers जो किसी ledger में नहीं दिखते।

Value ईमानदारी से दिखाना: budgets और go/no-go

Quantitative value आपके अपने records से आती है: release से पहले मिले और fix हुए defects, workarounds के साथ documented known defects, और escape हुए defects की मापी गई cost। Qualitative value असली है पर गिनी नहीं जा सकती: release करने का भरोसा, reputation, regulations और contracts का compliance। दोनों report करें और साफ़ लिखें कि कौन-सी कौन है।

गढ़े हुए ROI आँकड़े गुमराह करते हैं। "Testing ने 900% return दिया" जैसा दावा आम तौर पर मिले defects की संख्या को उस cost से गुणा करता है जो माना जाता है कि हर defect production में पैदा करता। कोई नहीं जानता कि उनमें से कौन users तक पहुँचता या कितना महँगा पड़ता, और चुनौती पाया एक number पूरी report की साख गिरा देता है। मापी गई costs, लिखे हुए assumptions और ranges इस्तेमाल करें।

  • Budget request — मापे गए external failure से शुरू करें ("पिछली तिमाही checkout के तीन hotfixes और उनसे आई support calls में लगभग 120 घंटे गए"), कोई specific prevention या appraisal investment प्रस्तावित करें, बताएँ कि कौन-से KPIs बदलने चाहिए, और review की तारीख़ तय करें। असर को जाँचने लायक उम्मीद के रूप में रखें, वादा किए गए return के रूप में नहीं।
  • Go/no-go — अभी और appraisal की cost (अतिरिक्त test days, देर से आने वाला revenue) को open defects और untested risks की संभावित external failure cost के सामने तौलें। Release owner को residual risk सादे शब्दों में और estimate range के रूप में दें; फ़ैसला उनका है।

आम गलतियाँ

  • हर उपलब्ध metric को KPI बना देना, जिससे dashboard पर बिना owner या target के तीस numbers हों।
  • सिर्फ़ lagging KPIs चुनना, जिससे team को problems का पता customers के बाद चलता है।
  • अपनी baseline से तय करने की बजाय दूसरी companies से targets कॉपी करना।
  • Defects found जैसी raw counts पर teams या testers की ranking करना, जो gaming को इनाम देता है और ईमानदार reporting को सज़ा।
  • गढ़ा हुआ ROI percentage या generic cost multiplier तथ्य की तरह पेश करना।
  • हर तिमाही cost-of-quality categories अलग तरीके से गिनना, जिससे trend product नहीं, bookkeeping दिखाता है।

QA का नज़रिया

QA lead KPI set product owner और engineering manager के साथ बनाता है, क्योंकि goal और फ़ैसले उनके हैं। छोटे से शुरू करें: एक goal, दो lagging KPIs, दो या तीन leading indicators और definitions का एक page, और पहली report से पहले thresholds और उनके actions तय कर लें।

हर तिमाही उस data से cost-of-quality log रखें जो पहले से आपके पास है (time tracking, defect tracker, incident log, support tickets)। जब कोई पूछे कि testing की value क्या है, तो इसे KPI trends के साथ दिखाएँ और साफ़ बताएँ कि numbers क्या नहीं दिखाते।

अभ्यास

एक तिमाही की quality costs classify करें और KPI set का draft बनाएँ

आपका काम

एक mobile banking team अगले साल failed transfers की customer complaints कम करना चाहती है। नीचे time tracking और defect tracker से उसकी पिछली तिमाही का data है, और एक slide जो एक vendor ने budget meeting के लिए सुझाई है। Costs classify करें, goal के लिए एक minimal KPI set का draft बनाएँ, और तय करें कि slide का क्या करना है।

सामग्री
Mobile banking app · transfers · last quarter · hours from time tracking

  A  Secure-coding training for developers                         24
  B  Root-cause workshop on the previous quarter's incidents;
     new review checklist adopted                                  12
  C  Review of transfer requirements and acceptance criteria       30
  D  Designing and running transfer regression tests              210
  E  Maintaining the test environment and test data                70
  F  Fixing and retesting 42 defects found in system testing      160
  G  Hotfix 7.4.1: transfer shown twice in the history             48
  H  Call-centre time on failed-transfer complaints                95

Production: 6 transfer defects reported by customers (2 Critical, 4 Major)

Vendor slide: "Testing ROI = 900%. Every defect found in testing
               saves 10x its fix cost in production."
चरण
  1. Lines A–H को prevention, appraisal, internal failure या external failure में रखें; घंटे जोड़ें और हर category का हिस्सा निकालें (percentage calculator मदद करता है)।
  2. Goal के लिए एक lagging KPI लिखें: definition, baseline, target और thresholds के साथ।
  3. दो leading indicators जोड़ें जिन्हें team एक sprint में बदल सके, और एक review cadence।
  4. दो वाक्यों में बताएँ कि vendor के ROI figure का क्या करें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Prevention: A 24 + B 12 = 36 घंटे (5.5%)। Appraisal: C 30 + D 210 + E 70 = 310 घंटे (47.8%)। Internal failure: F 160 घंटे (24.7%)। External failure: G 48 + H 95 = 143 घंटे (22.0%)। कुल: 649 घंटे। Requirements review (C) work product में defects ढूँढता है, इसलिए appraisal है; root-cause workshop (B) काम करने का तरीका बदलता है, इसलिए prevention है। Complaints और खोए customers गिनने से पहले ही external failure prevention का लगभग चार गुना है।

Lagging KPI: हर तिमाही customers द्वारा report किए गए Critical या Major transfer defects, duplicates छोड़कर। Baseline 6 (2 Critical); target अधिकतम 3 और कोई Critical नहीं; 4 या 5 पर at risk; 6 या ज़्यादा या कोई भी Critical होने पर off track, जो product owner के साथ review trigger करता है।

Leading indicators: हर release से पहले passing tests वाले High-risk transfer scenarios (target 100%, 95% से नीचे off track) और वे transfer stories जिनके acceptance criteria development से पहले QA ने review किए (target 90%, 75% से नीचे off track)। इन्हें हर sprint review करें, KPI को हर महीने product owner के साथ और हर तिमाही leadership के साथ, और set खुद हर तिमाही।

Vendor slide: 900% शायद assumed 10× multiplier को ही दूसरे रूप में कहता है (1 की cost पर 10 की बचत यानी 9 का net gain, जो 900% है), और यह भी मानता है कि मिला हर defect customers तक पहुँचता; यहाँ दोनों में से कुछ भी मापा नहीं गया, और चुनौती पाया एक number बाकी सबकी साख गिरा देता है। इसकी जगह external failure के मापे गए 143 घंटे, customers को मिले 6 defects, प्रस्तावित investment, जिन KPIs को बदलना चाहिए वे, और review की तारीख़ दिखाएँ।

अक्सर पूछे जाने वाले सवाल

Metric और KPI में क्या फ़र्क है?

Metric तय तरीके से किया गया कोई भी measurement है, जैसे pass rate या defect age। KPI गिने-चुने metrics में से एक है जिसे business goal की ओर progress दिखाने के लिए चुना जाता है, और उसका owner, target, action trigger करने वाले thresholds और तय review होता है। हर KPI एक metric है; ज़्यादातर metrics KPI नहीं हैं।

एक QA function के कितने KPIs होने चाहिए?

इतने कम कि leadership सब पढ़ ले: आम तौर पर हर business goal के लिए एक या दो lagging KPIs और दो या तीन leading indicators, यानी हर goal पर कुल तीन से पाँच। अगर किसी KPI ने दो तिमाही में कोई फ़ैसला नहीं बदला, तो उसे हटा दें।

क्या मैं testing का ROI calculate कर सकता हूँ?

सिर्फ़ आंशिक रूप से। आप costs (appraisal, internal और external failure) माप सकते हैं और किसी investment के बाद external failure का बदलना track कर सकते हैं। आप यह नहीं माप सकते कि testing ने जो defects पकड़े वे escape होते तो कितने महँगे पड़ते, इसलिए कोई भी single ROI percentage assumptions पर टिका होता है। उसकी जगह मापी गई costs, लिखे हुए assumptions और ranges दिखाएँ।

क्या DORA metrics QA KPIs हैं?

ये test team को नहीं, पूरे delivery system को मापते हैं, लेकिन change fail rate QA KPI set में quality के lagging KPI के रूप में अच्छा काम करता है, बशर्ते उसकी definition DORA की definition के अनुसार हो और target आपकी अपनी baseline से आए। Testing इन सब पर असर डालती है।

संदर्भ

  • Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024टेस्टिंग प्रबंधन पर ISTQB का advanced पाठ्यक्रम: टेस्ट योजना और अनुमान, risk-based testing, निगरानी, मेट्रिक्स और रिपोर्टिंग।
  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • DORA's software delivery performance metricsDORA (Google Cloud)DORA के डिलीवरी मेट्रिक्स — change lead time, deployment frequency, failed deployment recovery time, change fail rate आदि — throughput और instability में समूहित।
टूल्स

Mutqan tools से अभ्यास करें

प्रतिशत कैलकुलेटर

प्रतिशत, प्रतिशत परिवर्तन, वृद्धि/कमी और X, Y का कितना प्रतिशत है — सब गिनें।

यूटिलिटीज़

रिस्क-बेस्ड टेस्ट जनरेटर

फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।

टेस्ट डिज़ाइन

Markdown को PDF में बदलें

Markdown (.md) फ़ाइलों को ब्राउज़र में PDF में बदलें: शीर्षक, सूचियाँ, तालिकाएँ, कोड ब्लॉक, उद्धरण, लिंक और चित्र एम्बेडेड फ़ॉन्ट से टाइपसेट।

PDF रूपांतरण

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा