मॉड्यूल 9 · डिफ़ेक्ट मैनेजमेंट

सेवेरिटी और प्रायोरिटी

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

हर defect report दो अलग सवालों का जवाब देती है। Severity बताती है कि असर कितना बुरा है: ISTQB glossary इसे किसी component या system के development या operation पर defect के असर की मात्रा के रूप में परिभाषित करता है। Priority बताती है कि defect कितनी जल्दी ठीक होना चाहिए: team के बाक़ी सारे काम की तुलना में उसे दिया गया business महत्व का स्तर।

किसी online pharmacy app में, जो defect customer के card से पैसे काट ले लेकिन order न बनाए, उसकी severity high है: पैसा गया और कुछ deliver नहीं हुआ। वह कितनी जल्दी ठीक होगा, यह अलग फ़ैसला है, जो इस पर निर्भर है कि कितने customers उस तक पहुँच सकते हैं, कोई workaround है या नहीं, और अगली release कब है।

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

Teams के पास हमेशा समय से ज़्यादा defects होते हैं। Severity और priority से वे जल्दी तय कर पाती हैं कि पहले क्या ठीक हो और क्या ऐसे ही ship हो सकता है। जब दोनों एक field में मिला दी जाती हैं या बढ़ा-चढ़ाकर लिखी जाती हैं, तो manager की नज़र में आया cosmetic issue ठीक हो जाता है, जबकि चुपचाप data बिगाड़ने वाला defect इंतज़ार करता रहता है।

Tester के लिए ईमानदार rating report की विश्वसनीयता का हिस्सा है। अगर आपकी severity सबूत पर आधारित है, तो developers और product owner उस पर काम करते हैं; अगर आपका हर defect Critical है, तो वे उस field को पढ़ना छोड़ देते हैं, और अगला असली Critical बाक़ियों के साथ इंतज़ार करता है।

दो सवाल, दो scales

Severity defect का वर्णन करती है: failure होने पर क्या होता है। यह तभी बदलती है जब नया सबूत मिले, जैसे जब पता चले कि आपका report किया हुआ crash cart भी खाली कर देता है। Priority काम के क्रम के बारे में एक फ़ैसला है, इसलिए यह context के साथ बदलती है: release की तारीख़, कोई campaign, नया workaround, fix की लागत और risk। ISTQB Foundation syllabus इन्हें defect report के अलग-अलग fields के रूप में गिनाता है।

Scales हर team में अलग होते हैं, इसलिए यह lesson bug report guide वाले scales इस्तेमाल करता है। Priority के चार levels हैं, हर एक किसी समय से जुड़ा: Highest (अभी fix; release इसके बिना नहीं जाती), High (इसी release में fix), Medium (अगला sprint) और Low (backlog); कुछ teams इनकी जगह P0 से P3 लिखती हैं, और कुछ trackers पाँचवाँ level भी जोड़ते हैं। Severity के पाँच levels हैं, जिन्हें ऊपर से तब तक जाँचें जब तक कोई fit न हो जाए:

  • Blocker: कोई core flow इस्तेमाल नहीं हो सकता और कोई workaround नहीं। कोई भी customer order नहीं कर पाता।
  • Critical: पैसे का नुकसान या गलत charge, data का खोना या बिगड़ना, security exposure, या ज़्यादातर users के लिए किसी बड़े function का टूटना। Refund दो बार credit हो जाता है।
  • Major: कोई अहम function टूटा है पर workaround मौजूद है, या कुछ ही users प्रभावित हैं। Prescription upload camera से fail होता है पर photo gallery से हो जाता है।
  • Minor: छोटी functional या cosmetic समस्या। Order history सबसे पुराने order से शुरू होती है।
  • Trivial: typo या नगण्य visual ब्यौरा। Help text में एक full stop छूटा है।
Severity defect का वर्णन करती है और सिर्फ़ नए सबूत से बदलती है; priority product owner का फ़ैसला है कि fix कब हो, और यह तारीख़ों, campaigns और workarounds के साथ बदलती है।

Severity

Failure होने पर असर कितना बुरा है?

किसका वर्णन:
Defect और उसके नतीजे
आधार:
Users, data, पैसे और security पर असर, और कोई workaround
कौन तय करता है:
Tester propose करता है; developer सबूत के साथ सुधार सकता है
इस lesson का scale:
Blocker · Critical · Major · Minor · Trivial
कब बदलती है:
असर के बारे में नया सबूत मिले

Priority

बाक़ी काम की तुलना में team इसे कितनी जल्दी ठीक करे?

किसका वर्णन:
काम के क्रम का फ़ैसला
आधार:
Impact और frequency, साथ में तारीख़ें, visibility और fix की लागत
कौन तय करता है:
Product owner, आम तौर पर triage में
इस lesson का scale:
Highest · High · Medium · Low, या P0 से P3
कब बदलती है:
Context बदले: कोई तारीख़, campaign या workaround

Impact और frequency: दोनों ratings के पीछे का सबूत

Impact वह है जो failure करता है: user के साथ (काम रुका, गलत नतीजा, मेहनत बेकार), data, पैसे, security, क़ानूनी ज़िम्मेदारियों और भरोसे के साथ, और यह भी कि workaround है या नहीं। Severity मुख्य रूप से impact से तय होती है।

Frequency बताती है कि failure कितनी बार होता है: हर बार, या 10 में से 3 बार। उसके साथ reach आती है, यानी failure कितनी दूर तक फैला है: सभी devices पर या एक OS version पर, checkout में या किसी सालाना report में, सभी customers के लिए या एक account type के लिए। Frequency और reach का सबसे ज़्यादा असर priority पर होता है, क्योंकि हर order पर वही impact महीने में एक order की तुलना में ज़्यादा urgent है। कुछ severity scales reach को भी गिनते हैं, जैसे ऊपर का Major level, इसलिए team का नियम तय करें और उसे हर बार एक ही तरह लागू करें।

  • User, data और पैसे के साथ ठीक-ठीक क्या होता है?
  • क्या कोई workaround है जो आम user खोज ले, और उसकी उसे क्या क़ीमत चुकानी पड़ती है?
  • यह कितनी बार reproduce होता है, किन conditions में, और कौन इस तक पहुँच सकता है?
  • सबसे बुरा नतीजा क्या है जिसका आपके पास सबूत है, न कि जिसकी आप कल्पना कर सकते हैं?

चार combinations, उदाहरणों के साथ

क्योंकि दोनों scales अलग सवालों का जवाब देते हैं, हर combination असल में होता है। यहाँ high severity का मतलब Blocker या Critical है और low severity का मतलब Minor या Trivial; high priority का मतलब Highest या High है और low priority का मतलब Medium या Low। Major दोनों severity groups के बीच आता है, इसलिए उससे mixed combination नहीं बनता। Mixed combinations पर सबसे ज़्यादा ध्यान चाहिए: low priority वाली high severity को लिखित कारण चाहिए, और high priority वाली low severity आम तौर पर visibility का मामला होती है।

उसी pharmacy app से उदाहरण, गुरुवार को planned release से कुछ दिन पहले:

  • High severity, high priority: saved card से payment करने पर card से पैसे कटते हैं पर order नहीं बनता। Critical, Highest: release से पहले fix।
  • High severity, low priority: नया loyalty points feature चालू करने पर मौजूदा balances शून्य हो जाते हैं, लेकिन एक feature flag (ऐसी setting जो बिना नई release के feature को चालू या बंद करती है) उसे अगली तिमाही तक बंद रखता है। अभी Critical, Low, और flag चालू होने से पहले review की एक तारीख़ के साथ।
  • Low severity, high priority: home screen पर national day sale का banner पिछले साल की तारीख़ दिखाता है। कुछ टूटा नहीं, पर campaign शनिवार को शुरू है। Minor, High।
  • Low severity, low priority: settings screen पर back arrow बाक़ी screens से 2 pixel नीचे है। Trivial, Low: backlog।
Pharmacy app में हर combination होता है: बिना order बने card से पैसे कटना गुरुवार से पहले fix होता है, जबकि बंद flag के पीछे loyalty points का reset लिखित review तारीख़ के साथ इंतज़ार करता है।
Severity: असरPriority: कितनी जल्दी fix
High priorityHighest · HighLow priorityMedium · Low
High severityBlocker · CriticalCard से पैसे कटे, order नहीं बनाCritical · Highest: release से पहले fixLoyalty points reset, feature flag अभी बंदCritical · Low: चालू करने से पहले review
Low severityMinor · TrivialSale banner पर पिछले साल की तारीख़Minor · High: शनिवार के campaign से पहले fixBack arrow 2 px खिसका हुआTrivial · Low: backlog
  • दोनों high: पहले fix
  • Mixed combination: report में कारण दर्ज करें, जैसे बंद feature या ऐसी screen जिसे सब देखते हैं

यहाँ high severity का मतलब Blocker या Critical और low का मतलब Minor या Trivial है; Major दोनों rows के बीच आता है।

कौन क्या तय करता है

Severity impact के बारे में आकलन है, इसलिए आम तौर पर जिस tester ने defect खोजा, वही सबूत के आधार पर उसे propose करता है। Priority business फ़ैसला है, इसलिए product owner, या जिसके पास backlog है, उसे तय करता है, आम तौर पर development lead के साथ defect triage में: एक नियमित review जिसमें team तय करती है कि हर नए defect का क्या होगा। अगर team आपसे priority सुझाने को कहे, तो उसे सुझाव के रूप में ही लिखें।

  • Tester: severity propose करता है और वे facts दर्ज करता है जिन पर priority निर्भर है: frequency, reach, workaround और प्रभावित release।
  • Developer या development lead: cause और scope की पुष्टि करता है, fix की मेहनत और risk का अनुमान देता है, और नए technical facts के साथ severity सुधार सकता है।
  • Product owner: priority तय करता और बदलता है, defer या fix न करने का फ़ैसला करता है, और कारण दर्ज करता है।
  • Support और operations: बताते हैं कि production में failure कितनी बार और किन customers के लिए दिखता है।
  • Severity सिर्फ़ नए सबूत से बदलती है; priority तब बदलती है जब context बदलता है।

आज़माएँ: AI बग गंभीरता सुझाव आज़माएँ: AI बग प्राथमिकता सुझाव

Worked example: एक defect की rating

Pharmacy app की regression testing के दौरान आप "Cancel order" पर जल्दी से दो बार tap करके एक paid order cancel करते हैं। Refund wallet में दो बार credit हो जाता है। जब दूसरा tap 2 seconds के अंदर आता है, तो Android और iOS दोनों पर यह 5 में से 5 बार होता है।

  • Impact: company दो बार पैसा देती है और stored balance गलत है; finance को हर case खोजकर हाथ से वापस करना पड़ेगा।
  • Frequency: तय condition में हर बार, और slow network पर double tap आम है। Paid order cancel करने वाला कोई भी customer इसे trigger कर सकता है।
  • Severity: Critical, क्योंकि पैसा जा रहा है और stored data गलत है। Blocker नहीं: cancel करना अब भी काम करता है।
  • Priority: इसे तय करना आपका काम नहीं, पर आप product owner को ऊपर के facts और गुरुवार की release date देते हैं। Triage में वे Highest तय करते हैं, और आप fix के लिए confirmation test plan करते हैं।
Title:      Wallet: "Cancel order" पर दो बार tap करने से refund दो बार credit
Impact:     पैसा - wallet को refund का दोगुना मिलता है; finance हाथ से वापस करता है
Frequency:  5 में से 5 बार, जब दूसरा tap 2 s के अंदर हो (Android और iOS)
Reach:      paid order cancel करने वाला हर customer
Severity:   Critical  (QA का प्रस्ताव: पैसे का नुकसान, stored data गलत)
Priority:   Highest   (triage में product owner ने तय की: release गुरुवार को)

आम गलतियाँ

  • दोनों के लिए एक ही field इस्तेमाल करना, जिससे "Critical" का मतलब कुछ लोगों के लिए urgent और दूसरों के लिए नुकसानदेह हो जाता है।
  • जल्दी fix पाने के लिए severity बढ़ाना। इसकी जगह facts के साथ priority के लिए तर्क दें; बढ़ा-चढ़ाकर दी गई ratings पर भरोसा ख़त्म हो जाता है।
  • देखे गए impact की जगह सबसे बुरी कल्पना के आधार पर rating देना।
  • हर cosmetic defect को low priority मानना: किसी price, क़ानूनी सूचना या campaign page पर वह urgent हो सकता है।
  • कारण दर्ज किए बिना priority बदलना, जिससे बाद में कोई फ़ैसले और चूक में फ़र्क नहीं कर पाता।
  • Frequency और reach छोड़ देना, जिससे product owner को अंदाज़ा लगाना पड़ता है कि कितने customers प्रभावित हैं।

QA का नज़रिया

असली team में आप defect file करते समय team के लिखित scale से severity propose करते हैं, और triage में developers के technical facts जोड़ने पर उसे फिर से देखते हैं। चार सवाल ज़्यादातर ratings तय कर देते हैं: मैंने क्या देखा, यह कितनी बार होता है, कौन इस तक पहुँच सकता है, और क्या कोई workaround है?

जब आप किसी priority से असहमत हों, तो label पर बहस करने की बजाय context के बारे में पूछें: "रोज़ कितने customers paid orders cancel करते हैं?" या "क्या production में flag सच में बंद है?" नए facts फ़ैसले बदलते हैं; ऊँची ratings नहीं। Scale के साथ अपने product के कुछ rated उदाहरण रखें, ताकि नए team members भी उसी तरह rating दें।

अभ्यास

Clinic booking app के चार defects की rating करें

आपका काम

आप एक clinic booking app टेस्ट कर रहे हैं। Release रविवार को planned है, और उसी दिन नए online payment का प्रचार करने वाला campaign शुरू होता है। Material के हर defect के लिए severity propose करें, एक वाक्य के कारण के साथ priority सुझाएँ, और वे facts लिखें जो आपको अभी चाहिए।

फिर mixed combinations चिह्नित करें और हर एक के लिए वह कारण लिखें जो आप दर्ज करेंगे। बाद में आप अपने जवाबों की तुलना AI severity और priority suggestion tools से कर सकते हैं, दूसरी राय के रूप में, अंतिम जवाब के रूप में नहीं।

सामग्री
D1  Online payment: iOS पर "Pay" button कुछ नहीं करता। Android और website
    काम करते हैं। Patients अब भी booking करके clinic पर pay कर सकते हैं।
D2  Booking confirmation e-mail में हर booking के लिए doctor के नाम की जगह
    "{doctor_name}" दिखता है।
D3  Results URL के आख़िर का number बदलकर कोई patient दूसरे patient के
    lab results खोल सकता है।
D4  दो duplicate patient records को merge करने पर (admin function, महीने में
    कुछ बार इस्तेमाल) दूसरे record की visit history move होने की बजाय delete होती है।
चरण
  1. हर defect का impact एक वाक्य में लिखें।
  2. Frequency और reach के बारे में जो पता है और जो नहीं पता, वह लिखें।
  3. Blocker से नीचे की ओर scale जाँचते हुए severity propose करें।
  4. Priority सुझाएँ और बताएँ कि उसकी पुष्टि कौन करेगा।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

D1: Major। हर iOS user के लिए online payment fail होता है, पर patients अब भी booking करके clinic पर pay कर सकते हैं, और न पैसा जाता है न data, इसलिए यह Critical नहीं है। Priority Highest, क्योंकि campaign release के दिन online payment का प्रचार करता है; पुष्टि product owner करता है। यह mixed combination नहीं है, क्योंकि Major दोनों groups के बीच आता है। अभी चाहिए: iOS वाले patients का हिस्सा (अगर ज़्यादातर वही हैं, तो team इसे Critical रेट कर सकती है)।

D2: Minor, क्योंकि booking खुद सही है। Priority High: campaign के दिन हर patient टूटा हुआ e-mail देखेगा। यह mixed combination है; दर्ज करने लायक कारण है campaign के दौरान सभी patients को दिखना। अभी चाहिए: क्या दूसरे e-mails, जैसे reminders और cancellations, में भी ऐसे placeholders दिखते हैं।

D3: Critical, क्योंकि personal health data दूसरे users के सामने खुल रहा है। Priority Highest, और security owner को तुरंत बताएँ। अभी चाहिए: क्या defect पहले से production में है; अगर है, तो असली patients का data शायद पहले ही दूसरों के सामने खुल चुका हो, और security owner तय करता है कि इसे security incident की तरह संभालना है या नहीं। इसे सिर्फ़ test accounts से साबित करें और पहले सबूत पर रुक जाएँ।

D4: Critical, क्योंकि patient data खो रहा है, भले ही कुछ ही admins यह function इस्तेमाल करते हों। अगर product owner fix तक merge रोक दे और खोई हुई histories backups से restore हो सकें, तो priority Medium हो सकती है; यह mixed combination है, इसलिए रोक का फ़ैसला और review की तारीख़ दर्ज करें। अगर merge चालू रखना ज़रूरी हो, तो priority High है। अभी चाहिए: क्या defect पहले से production में है, और अगर है, तो क्या backups में delete हुई histories हैं।

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

क्या किसी defect की severity low और priority high हो सकती है?

हाँ। Campaign banner पर गलत तारीख़ या launch announcement में product के नाम की गलत spelling कुछ नहीं तोड़ती, पर हर visitor उसे देखता है। Priority visibility और तारीख़ों जैसे business context पर निर्भर है, सिर्फ़ impact पर नहीं।

जब tester और developer severity पर असहमत हों, तो कौन तय करता है?

सबूत triage में लाएँ। Developer को ऐसे facts पता हो सकते हैं जो आपको नहीं, जैसे पीछे-पीछे data का बिगड़ना, और आपको users पर ऐसे असर पता हो सकते हैं जो उन्होंने नहीं देखे। असहमति बनी रहे तो test lead या triage group एक बार फ़ैसला करता है और कारण दर्ज करता है। Severity schedules पर मोलभाव की जगह नहीं है; उसके लिए priority है।

क्या frequency से severity बदलनी चाहिए?

ज़्यादातर नहीं: severity impact पर चलती है, और frequency priority को दिशा देती है। फिर भी कुछ scales, इस lesson वाला भी, reach को tiebreaker की तरह इस्तेमाल करते हैं, जैसे कुछ ही users प्रभावित हों तो Critical की जगह Major। नियम पर सहमति बनाएँ, उसे उदाहरणों के साथ scale में लिखें, और हर हाल में report में frequency और reach दर्ज करें।

P0, P1, P2 और P3 का क्या मतलब है?

यह numbered priority scale है जिसे कई teams और tools इस्तेमाल करते हैं, P0 (तुरंत fix) से P3 (backlog) तक। ये priority बताते हैं, severity नहीं। अगर आपका tracker इनकी जगह शब्द इस्तेमाल करता है, तो लिखित mapping रखें, जैसे P0 को Highest और P3 को Low। कुछ trackers अलग numbering इस्तेमाल करते हैं, जैसे P1 से P5, इसलिए अपने tracker की definitions पढ़ें।

संदर्भ

  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • IEEE 1044-2009 — IEEE Standard Classification for Software AnomaliesIEEE Standards Association · 2009सॉफ़्टवेयर anomalies — defects, failures और उनके प्रभाव — को वर्गीकृत करने के मानक शब्द और एट्रिब्यूट (IEEE इसे inactive-reserved सूचीबद्ध करता है)।
टूल्स

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

AI बग गंभीरता सुझाव

Mutqan AI से कारण सहित सुझाई गई गंभीरता (Blocker / Critical / Major / Minor / Trivial) पाएँ।

बग विश्लेषण AI

AI बग प्राथमिकता सुझाव

Mutqan AI से व्यावसायिक प्रभाव, प्रभावित यूज़र, समयसीमा और गंभीरता को देखते हुए सुझाई गई प्राथमिकता (P0–P3) पाएँ।

बग विश्लेषण AI

AI बग विवरण जनरेटर

मोटे-मोटे नोट्स को पूरी बग रिपोर्ट में बदलें: reproduce करने के स्टेप, अपेक्षित बनाम वास्तविक, environment, गंभीरता और attachments चेकलिस्ट।

बग विश्लेषण AI

और गहराई से

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

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