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

लीडरशिप के लिए क्वालिटी रिपोर्टिंग

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

Leadership को product quality report करना business चलाने वालों को बताता है कि releases और teams में product बेहतर हो रहा है या बिगड़ रहा है, customers को कहाँ नुक़सान हो रहा है, company कौन-सा risk उठा रही है और कौन-सा फ़ैसला चाहिए। यह release से पहले testing में मिली जानकारी को production की घटनाओं से जोड़ता है: customers को मिले defects, incidents और failed deployments।

उदाहरण: QA lead का quarterly review दिखाता है कि नए contract tests के बाद checkout के escapes 18% से 9% पर आ गए, जबकि courier app के escapes untested Android versions पर दोगुने हो गए, और test devices माँगता है।

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

Leaders budgets, priorities और release dates तय करते हैं। अगर quality उन तक सिर्फ़ test case counts या नाराज़ customers के tickets के रूप में पहुँचे, तो वे अंदाज़े से फ़ैसले लेते हैं: numbers अच्छे दिखें तो testing घटा देते हैं, या किसी incident के बाद यह जाने बिना "और testing" माँगते हैं कि gap कहाँ है।

Lead role की ओर बढ़ते tester के लिए यही report वह जगह है जहाँ testing का असर बनता है: नतीजों से जुड़े evidence, साफ़ बताया गया risk और एक ठोस ask QA को cost line से फ़ैसलों का source बना देते हैं।

तीन reports, तीन audiences

कई templates जो "test summary report" माँगते हैं, वह test reporting वाले lesson की test completion report ही है; 2018 का ISTQB Foundation syllabus पुराना नाम इस्तेमाल करता था। यह testing के एक stage को exit criteria के मुक़ाबले बंद करती है, उसके लिए जो वह release स्वीकार करता है।

Leadership लंबी अवधि पर दूसरे सवाल पूछती है: क्या quality बेहतर हो रही है, customers को कहाँ नुक़सान हो रहा है, हम कौन-सा risk उठा रहे हैं, आपको क्या चाहिए? इसलिए तीन reports इस्तेमाल करें:

  • Test completion report: हर test stage पर, release स्वीकार करने वाले के लिए; क्या test हुआ और क्या अब भी खुला है।
  • Residual-risk statement: हर release पर, go/no-go decision owner के लिए; users को क्या नुक़सान हो सकता है, और उसे कौन स्वीकार करता है।
  • Quality review: leadership के लिए हर महीने dashboard और हर quarter meeting; releases और teams में quality, कारण, आगे ले जाया गया risk और ज़रूरी फ़ैसले।

Test results को production signals से जोड़ना

Test results बताते हैं कि आपने क्या जाँचा; production बताता है कि users ने क्या झेला। 99% pass rate untested paths के बारे में कुछ नहीं कहता, और शांत quarter का मतलब सिर्फ़ यह भी हो सकता है कि नया feature कम लोगों ने इस्तेमाल किया। हर team के लिए चार signals साथ-साथ रखें:

  • Release से पहले के सबूत: आपके KPI set के leading indicators, जैसे release पर pass हुए high-risk tests।
  • Escape rate: तय window में production में मिले defects, उन releases के लिए मिले सभी defects के हिस्से के रूप में (defect metrics वाले lesson के DDP का पूरक)। Counts और window दें: "9% (44 में से 4, 30 दिन)"।
  • Incidents: production की वे अनियोजित घटनाएँ जो users या business को नुक़सान पहुँचाती हैं, incident log से, severity level (अक्सर सबसे गंभीर के लिए Sev1; हर company अपने levels खुद तय करती है) और users पर असर के हिसाब से। हर एक पर label लगाएँ: capacity, configuration और third-party failures escaped defects नहीं हैं।
  • Change fail rate: DORA के अनुसार उन deployments का हिस्सा जिन्हें तुरंत intervention चाहिए, जैसे rollback या hotfix। यह deployment की वे failures पकड़ता है जो code के tests कभी नहीं देखते।

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

Worked example: एक quarterly quality review

पिछले lesson के food-delivery app की तीन teams हैं: checkout, ordering और courier app। हर quarter QA lead 45 मिनट की meeting से दो दिन पहले leadership को यह एक पेज का review भेजता है, जो teams के पहले से रखे data से बनता है और जिसे हर team lead पहले जाँचता है, ताकि किसी को झटका न लगे।

Leadership के लिए quarterly quality review, हिस्सा-दर-हिस्सा: पाठक और sources, फ़ैसले वाली headline, release से पहले के सबूत, production में नतीजे, targets, कारण, residual risk और asks।

Meeting से पहले भेजा गया एक पेज का review

भाग 1:QUARTERLY QUALITY REVIEW · Food-delivery app · Q3 · data as of 2 Oct
Readers: CTO, head of product, engineering managers, support lead
Sources: test management tool, defect tracker, incident and deployment logs

भाग 2:HEADLINE  Checkout improved and met its targets. Courier app quality fell:
          2 of the 3 Critical escapes this quarter came from it.
          Decision needed by 15 Oct: test devices for the courier app.

                               Checkout          Ordering          Courier app
भाग 3:BEFORE RELEASE (Q3)
  High-risk tests passed       100%              96%               71%
भाग 4:IN PRODUCTION (Q2 -> Q3)
  Escape rate, 30 days         18% -> 9% (4/44)  12% -> 11% (3/27) 10% -> 21% (7/33)
  Critical escapes             2 -> 0            0 -> 1            0 -> 2
  Change fail rate             14% -> 8% (4/50)  10% -> 10% (3/30) 8% -> 25% (3/12)
  Sev1 incidents               1 -> 0            0 -> 0            0 -> 1
  Sev2 incidents               3 -> 1            1 -> 2            1 -> 3
भाग 5:TARGETS  escape rate <= 10% · no Critical escapes · change fail rate <= 10%

भाग 6:WHY  Courier: 10 of 35 high-risk tests could not run (no older Android
     devices), and 5 of its 7 escapes occur only on those versions. The Sev1
     (live tracking down for 3 hours) followed an Android permission change.
     Ordering: the Critical escape was a stale menu price after an admin edit.
     Checkout: contract tests added in Q2 stopped 6 breaking payment-API
     changes before release.

भाग 7:RESIDUAL RISK CARRIED INTO Q4
  R1  Courier app on older Android versions: untested until devices arrive
  R2  New payment provider in November: no load test possible before go-live
  R3  14 Minor defects deferred, each with a workaround (list attached)

भाग 8:ASKS  1. Approve renting 6 older Android test devices (quote attached),
         by 15 Oct
      2. Head of product: accept R2 at the November go/no-go, or move the date
  1. 1Identification, पाठक और sourcesProduct, quarter और data की तारीख़; कौन पढ़ेगा; हर number कहाँ से आता है।
  2. 2Headline और फ़ैसलाएक वाक्य में trend और ज़रूरी फ़ैसला, deadline के साथ।
  3. 3Release से पहले के सबूतLeading indicator: हर team के high-risk tests का वह हिस्सा जो release पर pass हुआ।courier: 25/35 = 71%
  4. 4Production में नतीजेEscape rate, Critical escapes, change fail rate और incidents: counts के साथ rates, पिछली quarter के मुक़ाबले।courier escapes: 7/33 = 21%
  5. 5Targetsहर team को तय targets और उसके अपने पिछले data के मुक़ाबले पढ़ा जाता है, दूसरी teams के मुक़ाबले ranking कभी नहीं।
  6. 6कारणNumbers क्यों बदले, escape analysis और blameless incident reviews से, users पर असर की भाषा में।
  7. 7आगे ले जाया गया residual riskअगली quarter में ले जाए जा रहे जाने-पहचाने risks; हर एक अपने go/no-go पर पाँच हिस्सों वाला statement बनता है।
  8. 8Asksठोस फ़ैसले या support, हर एक का owner और deadline: meeting इसी के लिए है।

Parts 3 और 4 courier app की एक ही कहानी बताते हैं: release से पहले उसके 71% high-risk tests pass हुए, और उसके 21% defects escape हुए।

  • Headline सबसे पहले: trend और ज़रूरी फ़ैसला, deadline के साथ। हर rate अपने counts, पिछली quarter और target के साथ दिखता है; हर team को उसके अपने पिछले data के मुक़ाबले पढ़ा जाता है, ranking कभी नहीं। Escape rate में सिर्फ़ वे releases गिनी जाती हैं जिनकी 30 दिन की window data की तारीख़ तक बंद हो चुकी थी; बाद की releases अगले review में आती हैं।
  • सबूत नतीजों के ऊपर हैं ताकि पाठक दोनों की तुलना करें। Courier app के लिए दोनों मेल खाते हैं: सिर्फ़ 71% high-risk tests pass हुए और 21% defects escape हुए, यानी leading indicator ने release से पहले चेतावनी दी थी; अगली बार ship करने से पहले उस चेतावनी पर action लें। Tests green हों पर escapes बढ़ें, तो आम तौर पर tests वह cover नहीं करते जो users करते हैं; escapes स्थिर हों पर change fail rate बढ़े, तो यह deployment या infrastructure की ओर इशारा करता है।
  • "Why" lines escape analysis (हर escaped defect testing से कैसे निकल गया) और blameless incident reviews, यानी postmortems, से आती हैं, जो failure के पीछे की परिस्थितियाँ ढूँढते हैं, दोष देने के लिए कोई व्यक्ति नहीं। ये users पर असर की भाषा में लिखी जाती हैं, ताकि meeting का समय asks पर जाए।
पाठ संस्करण
QUARTERLY QUALITY REVIEW · Food-delivery app · Q3 · data as of 2 Oct
Readers: CTO, head of product, engineering managers, support lead
Sources: test management tool, defect tracker, incident and deployment logs

HEADLINE  Checkout improved and met its targets. Courier app quality fell:
          2 of the 3 Critical escapes this quarter came from it.
          Decision needed by 15 Oct: test devices for the courier app.

                               Checkout          Ordering          Courier app
BEFORE RELEASE (Q3)
  High-risk tests passed       100%              96%               71%
IN PRODUCTION (Q2 -> Q3)
  Escape rate, 30 days         18% -> 9% (4/44)  12% -> 11% (3/27) 10% -> 21% (7/33)
  Critical escapes             2 -> 0            0 -> 1            0 -> 2
  Change fail rate             14% -> 8% (4/50)  10% -> 10% (3/30) 8% -> 25% (3/12)
  Sev1 incidents               1 -> 0            0 -> 0            0 -> 1
  Sev2 incidents               3 -> 1            1 -> 2            1 -> 3
TARGETS  escape rate <= 10% · no Critical escapes · change fail rate <= 10%

WHY  Courier: 10 of 35 high-risk tests could not run (no older Android
     devices), and 5 of its 7 escapes occur only on those versions. The Sev1
     (live tracking down for 3 hours) followed an Android permission change.
     Ordering: the Critical escape was a stale menu price after an admin edit.
     Checkout: contract tests added in Q2 stopped 6 breaking payment-API
     changes before release.

RESIDUAL RISK CARRIED INTO Q4
  R1  Courier app on older Android versions: untested until devices arrive
  R2  New payment provider in November: no load test possible before go-live
  R3  14 Minor defects deferred, each with a workaround (list attached)

ASKS  1. Approve renting 6 older Android test devices (quote attached),
         by 15 Oct
      2. Head of product: accept R2 at the November go/no-go, or move the date

आज़माएँ: Markdown फ़ॉर्मेटर आज़माएँ: Markdown को PDF में बदलें

Go/no-go audience के लिए residual risk बताना

हर release से पहले सवाल सिमट जाता है: ship करें तो users को अब भी क्या नुक़सान हो सकता है, और उसे कौन स्वीकार करता है? बचे हिस्से को risk-based testing guide की तरह बाँटें (reduced, partial, open, not tested, out of scope), फिर हर अहम item को उन पाठकों के लिए दोबारा लिखें जो न risk IDs जानते हैं न test counts। यह review का R2 है, पाँच हिस्सों में, November के go/no-go के लिए; meeting खुद release readiness वाले lesson का विषय है।

  • असर, users की भाषा में: अगर नया payment provider शुक्रवार शाम के peak पर धीमा पड़ा, तो customers checkout पर इंतज़ार करेंगे और कुछ अपने orders छोड़ देंगे।
  • Evidence: payment tests provider के rate-limited test environment पर pass हुए, इसलिए peak load कभी test नहीं हुआ।
  • Likelihood, तर्क के साथ, कभी गढ़ा हुआ percentage नहीं: अज्ञात, किसी भी तरफ़ का evidence नहीं, और यही risk है।
  • Containment: पहले हफ़्ते 10% payments नए provider पर, किसी payment में 5 seconds से ज़्यादा लगें तो alert, और rehearse की गई पुराने provider पर वापसी 15 मिनट से कम में।
  • Acceptance, आपकी recommendation के साथ, साफ़ लिखा हुआ कि वह आपकी है: फ़ैसला head of product का; QA 10% से शुरुआत की recommendation देता है।

आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर

आम गलतियाँ

  • Completion reports या test case counts को quality report बनाकर leadership को forward करना।
  • सिर्फ़ test results या सिर्फ़ production incidents report करना; हर एक आधी कहानी बताता है।
  • बिना counts, window और definition के percentages, या quarters के बीच बदलती definitions।
  • Raw counts पर teams की ranking, जबकि ज़्यादा deploy करने वाली team के पास fail होने के मौक़े भी ज़्यादा होते हैं।
  • Residual risk testing jargon में या confidence percentage के रूप में, बिना यह नाम दिए कि उसे कौन स्वीकार करेगा।
  • बिना ask के review ख़त्म करना, जिससे leadership सहमत होती है और कुछ नहीं बदलता।

QA का नज़रिया

Review आम तौर पर QA lead की ज़िम्मेदारी है, पर वह definitions, windows और data sources engineering और operations के साथ एक बार तय करता है और data pulls automate करता है। पहले हर team lead के साथ उसका column देखें: CTO के सामने किसी team को चौंकाना numbers पर भरोसा तोड़ देता है।

हर फ़ैसला और स्वीकार किया गया risk record करें, हर review पिछली quarter के asks से शुरू करें, और एक साल में go/no-go फ़ैसलों की तुलना production में बाद की घटनाओं से करें, ताकि पता चले कि आपके residual-risk statements पर भरोसा किया जा सकता है या नहीं।

अभ्यास

Hotel booking app के लिए एक quarter का quality review लिखें

आपका काम

आप दो teams वाले hotel booking web app के QA lead हैं। नीचे दूसरी quarter के numbers और incident review notes हैं; multi-currency refunds 20 August को live होंगे। अगले हफ़्ते की leadership meeting के लिए review का मुख्य हिस्सा तैयार करें।

सामग्री
Hotel booking web app · Q2 (Apr-Jun) · two teams · data as of 31 Jul

                                       Search & booking    Payments & refunds
Deployments                            40                  25
Deployments rolled back or hotfixed    2                   5
Defects found in testing               54                  30
Defects found by customers, 30 days    6                   10
  of which Critical                    0                   2
Incidents Sev1 / Sev2                  0 / 1               1 / 2
Regression tests passed at release     98%                 99%
High-risk tests passed at release      100%                100%

Q1 for comparison: escape rate 12% and 11%; change fail rate 6% and 8%

Incident review notes, payments & refunds:
  - Sev1: refunds failed for 2 hours after the bank gateway's certificate expired
  - 7 of 10 customer-found defects are partial refunds in currencies other than
    SAR; all test data uses SAR bookings

Coming in Q3: multi-currency refunds go live on 20 Aug
चरण
  1. हर team का escape rate और change fail rate counts के साथ निकालें, Q1 के मुक़ाबले (percentage calculator मदद करता है)।
  2. Headline लिखें: हर team का trend और ज़रूरी फ़ैसला।
  3. समझाएँ कि payments team के test results और production signals मेल क्यों नहीं खाते, और हर कारण पर action कौन लेता है।
  4. 20 August के go-live के लिए पाँच हिस्सों वाला residual-risk statement लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Search & booking: escape rate 6/60 = 10% (Q1: 12%), change fail rate 2/40 = 5% (Q1: 6%): स्थिर। Payments & refunds: 10/40 = 25% (Q1: 11%) और 5/25 = 20% (Q1: 8%), 2 Critical escapes और एक Sev1 के साथ: साफ़ तौर पर बदतर।

Headline: "Search & booking स्थिर रहा। Payments & refunds बिगड़ा, ज़्यादातर non-SAR currencies में partial refunds की वजह से। 20 August से पहले फ़ैसला चाहिए: multi-currency refund tests के लिए समय, या बाद की go-live date।"

Payments के tests green थे, फिर भी escapes दोगुने से ज़्यादा हो गए: tests वह cover नहीं करते जो users करते हैं, क्योंकि test data में सिर्फ़ SAR bookings हैं (10 में से 7 escapes); इसे team और QA ठीक करें। Sev1, यानी expired certificate, एक operational failure है: expiry alerts operations या SRE lead की ज़िम्मेदारी हैं। Change fail rate escapes के साथ बढ़ा: pipeline को दोष देने से पहले deployment log में देखें कि क्या 5 rollbacks और hotfixes उन्हीं escapes के fixes थे।

असर: दूसरी currencies में गलत refund amounts। Evidence: 10 में से 7 escapes ऐसे ही refunds थे; कोई refund test non-SAR booking इस्तेमाल नहीं करता। Likelihood: ऊँची, इसी history को देखते हुए। Containment: पहले multi-currency tests, launch पर सिर्फ़ एक अतिरिक्त currency, और दो हफ़्ते तक रोज़ refund reconciliation। Acceptance: payments का product owner; QA की recommendation: नए tests pass होने तक go-live नहीं।

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

क्या test summary report और leadership के लिए quality report एक ही हैं?

नहीं। "Test summary report" test completion report का पुराना नाम है: यह testing के एक stage को exit criteria के मुक़ाबले उन लोगों के लिए बंद करती है जो वह release स्वीकार करते हैं। Leadership के लिए quality report एक अवधि में कई releases और teams को cover करती है और escapes, incidents और change fail rate जैसे production signals जोड़ती है। Completion reports उसके inputs में से हैं।

QA को leadership को कितनी बार quality report करनी चाहिए?

एक आम rhythm: तय KPIs का monthly dashboard, फ़ैसलों पर ख़त्म होने वाली quarterly review meeting, हर go/no-go पर residual-risk statement, और कुछ गंभीर होने पर, जैसे Critical escape, तुरंत message। Quarterly review को planning या budget cycle के साथ मिलाएँ ताकि उसके asks को funding मिल सके।

क्या जो incidents software defects नहीं हैं, वे भी QA report में आएँ?

हाँ, साफ़ label के साथ। Users configuration error या provider outage को भी खराब quality के रूप में ही झेलते हैं, और failed deployment का कारण चाहे जो हो, वह change fail rate में गिना जाता है। Escaped defects को operational कारणों से अलग करने पर हर action सही owner तक पहुँचता है।

अगर leadership एक ही quality score माँगे तो?

समझाएँ कि combined score छिपा देता है कि कौन-सा signal बदला, और लोगों को product की जगह score सुधारने के लिए उकसाता है। एक वाक्य की headline के साथ trends वाले तीन से पाँच KPIs दें। अगर एक index ज़रूरी ही हो, तो उसका formula publish करें और उसके components साथ में दिखाएँ।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024टेस्टिंग प्रबंधन पर ISTQB का advanced पाठ्यक्रम: टेस्ट योजना और अनुमान, risk-based testing, निगरानी, मेट्रिक्स और रिपोर्टिंग।
  • DORA's software delivery performance metricsDORA (Google Cloud)DORA के डिलीवरी मेट्रिक्स — change lead time, deployment frequency, failed deployment recovery time, change fail rate आदि — throughput और instability में समूहित।
  • Postmortem Culture: Learning from Failure — Site Reliability Engineering (John Lunney and Sue Lueder)Google / O'Reilly Media · 2016Blameless postmortems: किन घटनाओं पर postmortem ज़रूरी है, उसमें क्या दर्ज होता है — प्रभाव, root causes और follow-up कार्य — और उसमें दोष देने को क्यों बाहर रखा जाता है।
टूल्स

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

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

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

यूटिलिटीज़

Markdown फ़ॉर्मेटर

Markdown की फ़ॉर्मेटिंग (हेडिंग, सूचियाँ, टेबल, emphasis) सामान्य करें और रेंडर किया नतीजा देखें।

फ़ॉर्मेटिंग

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

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

PDF रूपांतरण

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

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

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

और गहराई से

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

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

इस topic से पहले