डिफ़ेक्ट ट्रायेज कैसे करें

उद्देश्य और प्रतिभागी

डिफ़ेक्ट लाइफ़साइकल में ट्रायेज New और Open के बीच बैठता है। इसका उद्देश्य कुछ ठीक करना नहीं, बल्कि चार फ़ैसले जल्दी लेकर दर्ज करना है: क्या रिपोर्ट valid है, यह कितनी severe है, कितनी urgent है, और आगे कौन क्या करेगा। हर फ़ैसले का एक मालिक है, और मालिकों का घालमेल धीमे या राजनीतिक ट्रायेज का सबसे आम कारण है।

• Test lead या QA प्रतिनिधि — defect और उसके सबूत पेश करता है, reproducibility की पुष्टि करता है, तय स्केल से severity प्रस्तावित करता है।
• Product owner — priority और बिज़नेस फ़ैसलों का मालिक: defer, won't fix, इस रिलीज़ के लिए जोखिम स्वीकारना।
• Development lead या on-call इंजीनियर — असाइनमेंट का मालिक, कारण और मेहनत पर पहली तकनीकी राय देता है।
• ज़रूरत पड़ने पर — production defect के लिए support या operations, सिक्योरिटी से जुड़े defect के लिए security owner, "क्या यह by design है?" के सवालों के लिए designer।
• व्यावहारिक नियम — QA severity प्रस्तावित करता है, product owner priority तय करता है, development lead असाइन करता है; असहमति एक बार escalate होती है, और फ़ैसला व कारण रिकॉर्ड में जाते हैं।

Cadence और मीटिंग फ़ॉर्मेट

Cadence defect आने की दर और रिलीज़ के चरण पर निर्भर करता है। System testing और release hardening के दौरान रोज़ का छोटा सेशन सामान्य है; स्थिर स्प्रिंट में हफ़्ते में दो-तीन सेशन आमतौर पर काफ़ी हैं। Blocker और Critical defect, और production को प्रभावित करने वाली कोई भी चीज़, मीटिंग का इंतज़ार नहीं करती: ड्यूटी पर मौजूद व्यक्ति उन्हें तुरंत और asynchronously ट्रायेज करता है, और मीटिंग सिर्फ़ फ़ैसले की पुष्टि करती है।

काफ़ी काम मीटिंग से पहले हो सकता है। QA lead नई रिपोर्टों को पूर्णता और duplicate के लिए पहले से जाँचता है और अधूरी रिपोर्टें Needs info में लौटा देता है, ताकि सेशन का समय पढ़ने के बजाय फ़ैसलों में लगे।

नीचे के उदाहरण में सेशन का क्रम (release hardening के दौरान रोज़ 20 मिनट): पहले 2 मिनट queue की जाँच — New में कितने defect हैं, सबसे पुराना untriaged defect कौन-सा है, और पिछले सेशन के बाद कोई Blocker या Critical आया या नहीं; मिनट 2 से 15 तक नए defect, सबसे ऊँची प्रस्तावित severity पहले, हर एक पर 1-2 मिनट, जिन्हें रिपोर्टर या QA lead स्लाइड से नहीं बल्कि defect रिकॉर्ड से दिखाता है; मिनट 15 से 18 तक पुराने या विवादित आइटम — 3 दिन से ज़्यादा Needs info में पड़े defect, review के लिए देय Deferred, और reopen पर असहमति; मिनट 18 से 20 तक फ़ैसले पढ़कर सुनाए जाते हैं और हर owner पुष्टि करता है। नियम: जिस पर 2 मिनट से ज़्यादा लगें, वह एक owner और लिखित सवाल के साथ सेशन से बाहर जाता है।

• फ़ैसले सेशन के दौरान ही ट्रैकर में दर्ज करें, मीटिंग नोट्स या चैट में नहीं।
• ग्रुप छोटा रखें: जो फ़ैसला ले सकते हैं, हर दिलचस्पी रखने वाला नहीं।
• प्रक्रिया मापें: untriaged count, सबसे पुराने untriaged defect की age, New से फ़ैसले तक का समय।

Defect triage - 20 minutes, daily during release hardening

00-02  Queue check: number of New, oldest untriaged, any Blocker/Critical since last session
02-15  New defects, highest proposed severity first, 1-2 minutes each
       Presenter: reporter or QA lead. On screen: the defect record, not a slide.
15-18  Aged or disputed items: Needs info > 3 days, Deferred due for review, reopen disputes
18-20  Read back decisions; each owner confirms

Rule: anything that needs more than 2 minutes leaves with an owner and a written question.

ट्रायेज चेकलिस्ट

हर नए defect को उन्हीं सवालों से उसी क्रम में गुज़ारें। पहले दो सवाल गेट हैं: अगर defect रिप्रोड्यूस नहीं होता या उसका सबूत नहीं है, या रिपोर्ट अधूरी है, तो वह एक ख़ास सवाल के साथ Needs info में जाता है और New में पड़ा नहीं रहता।

नीचे की सूची के आइटम क्रम से: Reproducible? (रिपोर्टर के अलावा किसी और ने स्टेप चलाए, या intermittent failure के लिए काफ़ी सबूत है: logs, request id, timestamps, रिकॉर्डिंग); Complete? (build, environment, अकाउंट/रोल, डेटा, expected बनाम actual); Duplicate? (error टेक्स्ट, endpoint या स्क्रीन, और component से खोजा गया; मिला तो लिंक किया); Valid? (expected result किसी requirement, design या साफ़ convention से जुड़ा है); Severity (तय स्केल पर यूज़र या सिस्टम पर असर); Priority (बिज़नेस तात्कालिकता: रिलीज़ की तारीख़, प्रभावित यूज़र, visibility); Owner (नामित व्यक्ति, या नामित lead वाली टीम queue — "dev team" नहीं); Target release (version या sprint; या कारण के साथ Deferred; या कारण के साथ Won't fix); Workaround (है या नहीं? support और release notes के लिए लिखा गया); Info needed (ठीक कौन-सी चीज़ चाहिए और कौन देगा); Links (story या requirement, test case, जुड़े defect, और production का मामला हो तो incident)।

[ ] Reproducible?   Steps run by someone other than the reporter, or evidence strong enough for an
                    intermittent failure (logs, request id, timestamps, recording)
[ ] Complete?       Build, environment, account/role, data, expected vs actual
[ ] Duplicate?      Searched by error text, endpoint or screen, component; linked if found
[ ] Valid?          Expected result traced to a requirement, design or clear convention
[ ] Severity        Impact on user/system on the agreed scale (Blocker ... Trivial)
[ ] Priority        Business urgency (Highest ... Low): release date, users affected, visibility
[ ] Owner           A named person, or a team queue with a named lead - not "dev team"
[ ] Target release  Version or sprint; or Deferred with reason; or Won't fix with reason
[ ] Workaround      Exists? Written down for support and the release notes
[ ] Info needed     The exact missing item and who must provide it
[ ] Links           Story/requirement, test case, related defects, incident (if production)

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

Severity × priority: डिसीज़न मैट्रिक्स

बग रिपोर्ट गाइड दोनों स्केल परिभाषित करती है: severity — Blocker, Critical, Major, Minor, Trivial; priority — Highest, High, Medium, Low। Severity असर है और priority तात्कालिकता, इसलिए कोई भी संयोजन संभव है। नीचे का मैट्रिक्स उदाहरणों के साथ आम फ़ैसले देता है; यह चर्चा की शुरुआत है, फ़ॉर्मूला नहीं — product owner priority बदल सकता है, लेकिन कारण दर्ज होता है।

मैट्रिक्स के उदाहरण और आम फ़ैसले: Blocker × Highest: production में हर यूज़र के लिए लॉगिन 500 लौटाता है — अभी hotfix, और incident खोला जाए। Critical × Highest: checkout ग़लत VAT राशि लेता है और रिलीज़ 7 दिन में है — रिलीज़ से पहले fix; तब तक sign-off रुका रहता है। Critical × Low: तिमाही एडमिन export कुछ rows छोड़ देता है और अगला रन 10 हफ़्ते बाद है — शेड्यूल करें और review की तारीख़ तय करें। Major × High: orders सूची date filter को अनदेखा करती है, workaround sort करना है — इसी रिलीज़ में fix। Major × Medium: 5 MB से बड़ा bulk import बिना मैसेज के फ़ेल होता है, पर ऐसा कम होता है — अगला sprint। Minor × High: sign-up फ़ॉर्म के national ID फ़ील्ड पर अरबी error टेक्स्ट में अंग्रेज़ी placeholder दिखता है — launch campaign से पहले fix। Minor × Low: अरबी लेआउट में 320 px चौड़ाई पर tooltip कटता है — backlog। Trivial × High: लॉगिन पेज पर कंपनी का नाम ग़लत लिखा है — जल्दी fix, क्योंकि यह सबको दिखता है। Trivial × Low: footer की copyright लाइन में एक अतिरिक्त स्पेस — backlog, बाक़ी टेक्स्ट सुधारों के साथ।

• Low priority वाले Blocker या Critical defect को लिखित कारण चाहिए: फ़ीचर बंद है, तारीख़ दूर है, या कोई यूज़र वहाँ तक नहीं पहुँच सकता।
• High या Highest priority वाला Trivial या Minor defect आमतौर पर visibility का मामला है: कानूनी टेक्स्ट, ब्रांड, डेमो, या ऐसी स्क्रीन जिसे कोई regulator या बड़ा ग्राहक देखेगा।
• Exit criterion पास करने के लिए priority नहीं घटाई जाती; नए सबूत के बिना severity नहीं बदली जाती।
• AI Bug Priority Suggestion टूल अपना सुझाव P0–P3 स्केल पर देता है, P0 (तुरंत fix) से P3 (backlog) तक। अपने ट्रैकर से एक लिखित mapping रखें — जैसे P0 → Highest, P1 → High, P2 → Medium, P3 → Low।

Severity x Priority   Example defect                                          Typical decision
--------------------  ------------------------------------------------------  ------------------------------
Blocker  x Highest    Login returns 500 for every user in production          Hotfix now, incident open
Critical x Highest    Checkout charges the wrong VAT amount, release in 7 d   Fix before release; blocks sign-off
Critical x Low        Quarterly admin export drops rows; next run: 10 weeks   Schedule; set a review date
Major    x High       Orders list ignores date filter; workaround: sort       Fix in this release
Major    x Medium     Bulk import over 5 MB fails with no message; rare       Next sprint
Minor    x High       Arabic error text shows an English placeholder on the   Fix before a launch campaign
                      national ID field of the sign-up form
Minor    x Low        Tooltip clipped at 320 px width in the Arabic layout    Backlog
Trivial  x High       Company name misspelled on the login page               Quick fix; high visibility
Trivial  x Low        Extra space in the footer copyright line                Backlog; batch with copy fixes

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

असाइनमेंट और जाँच

Ownership के आधार पर असाइन करें, इस आधार पर नहीं कि कमरे में कौन है: component या service का मालिक, या ऐसी team queue जिसका नामित lead एक दिन के अंदर काम बाँटे। "टीम" को असाइन किए defect का कोई मालिक नहीं होता। जब कारण कई layers में हो सकता है — ऐप, API, डेटा — तो उसे उस layer को असाइन करें जहाँ failure दिखा, और उसके मालिक को सबूत के साथ आगे सौंपने दें, बजाय इसके कि वह ट्रायेज में तब तक पड़ा रहे जब तक कोई सही अंदाज़ा न लगा ले।

जाँच ट्रायेज के बाद मालिक का काम है, और उसकी समय-सीमा होनी चाहिए। अगर तय समय में defect रिप्रोड्यूस नहीं होता, तो वह आज़माई गई चीज़ों की सूची के साथ Needs info में लौटता है, या सबूत रखते हुए cannot reproduce के रूप में resolve होता है।

• पहले रिपोर्टर के डेटा से रिपोर्टर के environment में रिप्रोड्यूस करें, फिर लोकल।
• आख़िरी सही build खोजें और बदलावों का दायरा घटाएँ; git के साथ बीच के commits पर bisect करें।
• चलने वाले और फ़ेल होने वाले केस की तुलना request level पर करें — web बनाम Android, एक अकाउंट बनाम दूसरा: दोनों requests कैप्चर करें और responses का diff देखें।
• Stack trace अपने कोड के पहले frame से पढ़ें; कोड बदलने से पहले configuration, feature flags और डेटा जाँचें।
• Findings defect रिकॉर्ड में लिखें, सिर्फ़ चैट में नहीं, ताकि अगला व्यक्ति फिर से शुरू न करे।

आज़माएँ: AI एरर मैसेज एनालाइज़र आज़माएँ: HTTP रिक्वेस्ट इंस्पेक्टर आज़माएँ: cURL जनरेटर आज़माएँ: API रिस्पॉन्स एनालाइज़र

Root cause analysis: 5 whys, fishbone और origin

फ़िक्स एक defect हटाता है; root cause analysis पूछता है कि error क्यों हुआ और पहले क्यों नहीं पकड़ा गया, ताकि उसी तरह के defect रोके जा सकें। ISTQB Foundation syllabus root cause को defect से और उससे होने वाले failure से अलग रखता है। Root cause analysis Blocker और Critical defect, production escapes और बार-बार आने वाले पैटर्न के लिए करें — हर टाइपो के लिए नहीं।

5 whys तकनीक failure से शुरू करके बार-बार "क्यों?" पूछती है, जब तक जवाब कोई ऐसा process कारण न हो जिसे टीम बदल सके। पाँच एक heuristic है, नियम नहीं; जवाब actionable होते ही रुकें, और जब एक जवाब के कई कारण हों तो शाखाएँ बनाएँ। Fishbone (Ishikawa) diagram संभावित कारणों को श्रेणियों में रखता है ताकि चर्चा पहले विश्वसनीय लगने वाले कारण पर अटक न जाए। सॉफ़्टवेयर के लिए उपयोगी श्रेणियाँ नीचे की origin classes ही हैं, साथ में people और process।

हर defect को उसके origin के हिसाब से वर्गीकृत करें। IEEE 1044 anomalies को वर्गीकृत करने के लिए कहीं ज़्यादा समृद्ध एट्रिब्यूट परिभाषित करता है; नीचे के छह origins एक सरल शुरुआत हैं जिन्हें ज़्यादातर टीमें ट्रायेज में लगातार लागू कर सकती हैं।

• Requirements — requirement ग़ायब, अस्पष्ट, ग़लत, या बदली गई लेकिन बदलाव हर consumer तक नहीं पहुँचा।
• Design — architecture या interface का ग़लत या असंगत फ़ैसला।
• Code — implementation की गलती: logic, boundaries, null handling, concurrency, duplicated logic।
• Environment — configuration, infrastructure, versions, third-party service, deployment।
• Data — अप्रत्याशित, malformed या ग़लत तरीके से migrate हुआ डेटा; ग़लत reference data।
• Test — defect ख़ुद test में था (false positive), या test gap की वजह से बच निकला; test gaps को contributing cause के रूप में दर्ज करें।

उदाहरण: VAT defect का root cause

एक काल्पनिक उदाहरण, जो डिफ़ेक्ट लाइफ़साइकल गाइड में फ़ॉलो किए गए defect को आगे बढ़ाता है: fixed-amount coupon लगाने पर Android checkout ने 184.00 की जगह 190.00 SAR लिए, क्योंकि VAT डिस्काउंट से पहले कैलकुलेट हुआ।

नीचे के उदाहरण में "क्यों" की कड़ी: राशि ग़लत क्यों थी? क्योंकि API v2 की pricing ने 15% VAT निकालने के बाद coupon लगाया। ऐसा क्यों? क्योंकि v2 के पास pricing function की अपनी कॉपी है, जो v1 से fork हुई थी। कॉपी अपडेट क्यों नहीं हुई? क्योंकि "VAT डिस्काउंट के बाद की कीमत पर" वाला नियम (release 5.1) सिर्फ़ web checkout की story के रूप में लिखा गया था, और pricing इस्तेमाल करने वाले बाक़ी हिस्सों की सूची किसी ने नहीं बनाई। टेस्ट ने इसे क्यों नहीं पकड़ा? क्योंकि v2 के API tests में coupon वाले केस नहीं थे, और टेस्ट डेटा में भी coupon नहीं थे। Coupon वाला केस क्यों नहीं था? क्योंकि v2 के tests v1 के happy-path केस से कॉपी हुए थे और pricing decision table से कभी मिलाए नहीं गए। वर्गीकरण: मुख्य origin requirements, और code व test सहायक कारण; कार्रवाइयाँ, हर एक का owner और तारीख़ के साथ: v1, v2 और web के लिए एक ही pricing service, decision table पर आधारित API tests (coupon का प्रकार × VAT × rounding), और story टेम्पलेट में नया सवाल: "यह नियम कौन-से clients या APIs इस्तेमाल करते हैं?"।

• विश्लेषण मालिकों और तारीख़ों वाले process बदलावों पर ख़त्म होता है, किसी दोषी व्यक्ति पर नहीं।
• Primary origin वह जगह है जहाँ defect आया; contributing causes बताते हैं कि वह बचा क्यों रहा।
• Test वाला action failure को स्थायी check में बदलता है, जो रोकथाम का सबसे सस्ता हिस्सा है।

DEF-2417  Android checkout charges 190.00 SAR instead of 184.00 with a fixed-amount coupon

5 whys
1  Why was the amount wrong?       API v2 pricing applied the coupon after calculating 15% VAT.
2  Why did v2 do that?             v2 has its own copy of the pricing function, forked from v1.
3  Why was the copy not updated?   The rule "VAT on the discounted price" (release 5.1) was written
                                   as a story for web checkout only; no one listed the other
                                   consumers of pricing.
4  Why did tests not catch it?     v2 API tests had no coupon cases; the test data had no coupons.
5  Why was there no coupon case?   v2 tests were copied from v1 happy-path cases and never reviewed
                                   against the pricing decision table.

Fishbone (contributing causes)
  Requirements  rule change scoped to one client
  Design        pricing logic duplicated per API version
  Code          order of operations in v2 price() and summary()
  Test          no coupon x VAT combinations at API level; test data without coupons
  Environment   none (reproduced on staging and locally)
  Data          none

Classification  origin: requirements (primary); code, test (contributing)
Actions (owner, due)
  - One pricing service used by v1, v2 and web              (omar.k, release 5.4)
  - Decision-table API tests: coupon type x VAT x rounding  (layla.h, 2026-09-25)
  - Story template asks "Which clients or APIs use this rule?" (product owner, next refinement)

ट्रायेज के anti-patterns

• ट्रायेज को status meeting बनाना — नए defect पर फ़ैसला लेने के बजाय हर खुला defect पढ़ना।
• Priority inflation — जब सब कुछ High है, तो High का कोई मतलब नहीं। वितरण पर नज़र रखें।
• Severity पर मोलभाव — exit criterion पास करने के लिए severity घटाना। Severity बदलने के लिए नया सबूत चाहिए।
• "टीम" को असाइन करना — defect का कोई मालिक नहीं, इसलिए कोई उसे ठीक नहीं करता।
• बिना reference के reject करना — कोई requirement या डिज़ाइन उद्धृत किए बिना "works as designed"।
• Cannot reproduce को कूड़ेदान बनाना — क्या आज़माया यह दर्ज किए बिना या सबूत रखे बिना intermittent defect बंद करना।
• स्थायी deferral — बिना review तारीख़ के deferred defect छिपा हुआ backlog बन जाता है।
• मीटिंग में debugging — जाँच ट्रायेज के बाद मालिक का काम है।
• दोषारोपण — जो root cause analysis "डेवलपर X लापरवाह था" पर ख़त्म होता है, उसने root cause नहीं खोजा।
• चैट में फ़ैसले — जो ट्रैकर में नहीं, वह हुआ ही नहीं।

ट्रायेज क्या देता है

ट्रायेज सेशन तब पूरा होता है जब उसने छुआ हर defect दर्ज फ़ैसले के साथ New से निकल जाए। AI लिखने वाले हिस्से को तेज़ कर सकता है — साफ़ टाइटल, structured description, justification के साथ सुझाई severity और priority — लेकिन फ़ैसले उन्हीं लोगों के पास रहते हैं जो उनके मालिक हैं।

• हर defect के लिए: नया स्टेट, severity, priority, मालिक, target release, links, और किसी भी बिना-फ़िक्स resolution का कारण।
• नामित व्यक्ति को ठीक-ठीक सवाल के साथ भेजे गए Needs info अनुरोध।
• रिलीज़ के फ़ैसले के लिए अपडेट की गई known-issues और risk सूची।
• Escalations: Blocker और Critical defect उसी दिन release manager को बताए जाएँ।
• योग्य defect के लिए root cause analysis tasks, मालिकों और तारीख़ों के साथ।
• ट्रायेज मेट्रिक्स: untriaged count और age, फ़ैसले तक का समय, rejected और duplicate rates।

आज़माएँ: AI बग टाइटल जनरेटर आज़माएँ: AI बग विवरण जनरेटर

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

संदर्भ

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
• ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
• Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024टेस्टिंग प्रबंधन पर ISTQB का advanced पाठ्यक्रम: टेस्ट योजना और अनुमान, risk-based testing, निगरानी, मेट्रिक्स और रिपोर्टिंग।
• IEEE 1044-2009 — IEEE Standard Classification for Software AnomaliesIEEE Standards Association · 2009सॉफ़्टवेयर anomalies — defects, failures और उनके प्रभाव — को वर्गीकृत करने के मानक शब्द और एट्रिब्यूट (IEEE इसे inactive-reserved सूचीबद्ध करता है)।
• Editing a Bug (section "Life Cycle of a Bug") — Bugzilla DocumentationBugzilla Project (Mozilla)एक व्यापक रूप से इस्तेमाल होने वाले ट्रैकर का डिफ़ॉल्ट बग workflow — statuses, resolutions (fixed, invalid, won't fix, duplicate, works for me) और transitions — lifecycle का ठोस उदाहरण।
• Lessons Learned in Software Testing: A Context-Driven Approach (Cem Kaner, James Bach, Bret Pettichord)Wiley · 2001बग रिपोर्टिंग, टेस्ट डिज़ाइन, ऑटोमेशन और टेस्टिंग प्रबंधन पर व्यावहारिक सबक — कॉन्टेक्स्ट-ड्रिवन स्कूल।