डिफ़ेक्ट लाइफ़साइकल

Error, defect, failure: शब्द सही रखें

ISTQB glossary और Foundation syllabus एक कारण-श्रृंखला बताते हैं। कोई व्यक्ति error (जिसे mistake भी कहते हैं) करता है: requirement ग़लत पढ़ता है, कोई boundary भूल जाता है, ग़लत operator लिख देता है। Error से किसी work product में defect (जिसे fault या bug भी कहते हैं) बनता है — requirement, डिज़ाइन, कोड, test script या configuration में। जब defect वाला हिस्सा सही परिस्थितियों में चलता है तो वह failure पैदा कर सकता है: सिस्टम वह नहीं करता जो उसे करना चाहिए, और कोई व्यक्ति या सिस्टम उसे देखता है। हर defect failure नहीं बनता — ऐसे कोड का defect जो कभी चलता ही नहीं, या सिर्फ़ ऐसे डेटा से चलता है जो कोई डालता नहीं, छिपा रहता है — और syllabus यह भी बताता है कि failure पर्यावरणीय परिस्थितियों से भी हो सकता है।

दो और शब्द उलझन पैदा करते हैं। Anomaly तटस्थ शब्द है: अपेक्षा से देखा गया विचलन, इससे पहले कि कोई तय करे कि यह defect है, ग़लतफ़हमी है, test की गलती है या change request। IEEE 1044, Standard Classification for Software Anomalies (जिसे IEEE inactive-reserved सूचीबद्ध करता है), anomaly को छत्र-शब्द के रूप में इस्तेमाल करता है और anomalies को वर्गीकृत करने के एट्रिब्यूट परिभाषित करता है। Incident के कई अर्थ हैं: ISO/IEC/IEEE 29119-3 defect report को "incident report" कहता है (ISTQB Foundation syllabus भी यह बताता है), जबकि operations में incident किसी live सर्विस में अनियोजित रुकावट या गिरावट है, जिसका कारण defect भी हो सकता है और capacity, configuration या कोई third party भी।

• Error (mistake) — इंसानी काम जिससे ग़लत नतीजा निकलता है।
• Defect (fault, bug) — किसी work product में कमी; इसे कुछ भी चलाए बिना review से पकड़ा जा सकता है।
• Failure — चलते सिस्टम का अपेक्षित व्यवहार से देखा गया विचलन।
• Root cause — error होने या defect न रोके जा पाने का मूल कारण; root cause analysis का लक्ष्य।
• Anomaly — अपेक्षा से कोई भी देखा गया विचलन, जो अभी वर्गीकृत नहीं हुआ।

Defect कहाँ मिलते हैं: review, testing और production

Defect SDLC के हर चरण में आते हैं और उसके अलग-अलग बिंदुओं पर मिलते हैं। एक requirement जो दूसरी से टकराती है, वह defect है जो कोई कोड बनने से पहले review में पकड़ा जाता है। ग़लत calculation STLC के दौरान unit, API या system test से पकड़ी जाती है। जो defect हर जाँच से बच निकलता है वह production में मिलता है, आमतौर पर यूज़र की रिपोर्ट या monitoring के alert के रूप में। SDLC और STLC गाइड और software testing life cycle गाइड इन चरणों को बताती हैं; यह पेज बताता है कि मिलने के बाद defect के साथ क्या होता है।

तीनों स्थितियों में लाइफ़साइकल का आकार एक है, लेकिन entry point और लागत अलग है। Defect चाहे जैसे मिले, वह प्रक्रिया में रिपोर्ट के ज़रिए आता है; ऐसी रिपोर्ट कैसे लिखें जिस पर डेवलपर काम कर सके, और severity व priority में क्या फ़र्क़ है, यह बग रिपोर्ट गाइड का विषय है। फिर ट्रायेज रिपोर्ट को फ़ैसले में बदलता है, जिसे डिफ़ेक्ट ट्रायेज गाइड विस्तार से कवर करती है। हर defect कहाँ मिला — review, test level या production — यह दर्ज करना ही बाद में यह मापने देता है कि हर चरण से कितने defect निकल भागे।

• Review findings — review log या review comments में दर्ज; तब बंद जब author ने work product ठीक कर दिया और reviewer ने सुधार जाँच लिया।
• Testing चरण के defect — ट्रैकर में पूरा लाइफ़साइकल, क्लोज़र से पहले confirmation testing और regression testing के साथ।
• Production defect — operational incident से लिंक, live सर्विस प्रभावित हो तो तुरंत ट्रायेज, और फ़िक्स deploy होने के बाद production में verify।

लाइफ़साइकल के स्टेट: डायग्राम

ट्रैकर के workflow अलग-अलग होते हैं, लेकिन लगभग सभी वही बुनियादी स्टेट लागू करते हैं। डायग्राम सामान्य नाम इस्तेमाल करता है; आगे का सेक्शन इन्हें असली टूल से जोड़ता है। ठोस तीर New से Closed तक का मुख्य रास्ता दिखाते हैं; डैश वाले तीर शाखाएँ हैं: वे defect को बिना कोड बदले ख़त्म करते हैं, बाद के लिए रख देते हैं, या fix न टिकने पर उसे वापस भेजते हैं।

• New — दर्ज हुआ, अभी review नहीं हुआ। कुछ ट्रैकर इसे Unconfirmed, Submitted या Untriaged कहते हैं।
• Needs info — रिपोर्टर से किसी ख़ास जानकारी का इंतज़ार; aging की घड़ी चलती रहती है।
• Open / Assigned — valid माना गया, severity, priority, मालिक और target release के साथ।
• In Progress — मालिक सक्रिय रूप से जाँच या फ़िक्स कर रहा है।
• Resolved — मालिक के हिसाब से काम पूरा, या तो fixed या किसी और resolution के साथ।
• Reopened — resolution टिका नहीं; defect अपने मालिक के पास लौटता है।
• Verified — टेस्टर ने बताए गए build में फ़िक्स की पुष्टि की।
• Closed — आगे कोई काम नहीं; रिकॉर्ड इतिहास और मेट्रिक्स के लिए रहता है।
• Deferred — valid, लेकिन सोच-समझकर बाद की रिलीज़ तक टाला गया; अब भी ज्ञात खुला defect गिना जाता है।

  failure observed, or defect found in a review
                 |
                 v
             [ New ] ----- facts missing -----> [ Needs info ]
                 |  <------ facts supplied ------------+
                 |
                 +------- triage: no fix needed ------> [ Resolved ]  duplicate | rejected (not a bug)
                 |                                           |         cannot reproduce | won't fix | by design
                 | triage: accepted                          |
                 v                                           | reporter / QA agrees (if not: back to triage)
        [ Open / Assigned ] <----- re-planned -----+         |
             |        |                            |         |
             |        +------ postpone ----> [ Deferred ]    |
             | developer starts                              |
             v                                               |
        [ In Progress ]                                      |
             +-- cannot reproduce --> back to [ Needs info ] |
             | fix merged, build number stated               |
             v                                               |
     [ Resolved: fixed ] -- retest fails --> [ Reopened ] --> back to [ Open / Assigned ]
             |                                               |
             | confirmation test passes, regression green    |
             v                                               v
        [ Verified ] ------- fix shipped ------------> [ Closed ]
                                                             |
                                same failure seen again -----+--> [ Reopened ]

ट्रांज़िशन: defect कौन आगे बढ़ाता है और क्या सच होना चाहिए

कोई स्टेट तभी काम का है जब सबको पता हो कि उससे defect को कौन निकाल सकता है और पहले क्या सच होना चाहिए। ये नियम ट्रैकर के workflow में डालें जहाँ वह conditions और required fields सपोर्ट करता हो, और जहाँ न करता हो वहाँ टीम के working agreement में लिखें।

• New → Open / Assigned — ट्रायेज ग्रुप (test lead, product owner, development lead) — रिप्रोड्यूस हुआ या भरोसेमंद सबूत है, duplicate नहीं, severity और priority तय, नामित मालिक और target release।
• New → Needs info — ट्रायेज या डेवलपर — ठीक-ठीक कौन-सी चीज़ चाहिए वह लिखा जाए (build number, अकाउंट, request id), सिर्फ़ "more info please" नहीं।
• Needs info → New — रिपोर्टर, या जिससे जानकारी माँगी गई थी — माँगी गई जानकारी रिपोर्ट में जोड़ दी गई; defect सीधे किसी डेवलपर के पास नहीं, दोबारा ट्रायेज में जाता है।
• New → duplicate, rejected, cannot reproduce, won't fix या by design के रूप में Resolved — ट्रायेज ग्रुप — कारण दर्ज, duplicate मूल से लिंक, रिपोर्टर को सूचना।
• Open → Deferred — product owner — लिखित कारण और target release या review की तारीख़; जोखिम वह स्वीकार करे जिसके पास स्वीकार करने का अधिकार हो।
• Deferred → Open / Assigned — product owner — review की तारीख़ या target release आ गई, और defect को मालिक और रिलीज़ के साथ फिर से प्लान किया गया; टालने की अवधि बढ़े तो नया लिखित कारण चाहिए।
• Open → In Progress — असाइन किया डेवलपर — काम शुरू; जो डेवलपर रिप्रोड्यूस नहीं कर पाता वह इसे खाली पड़ा रहने देने के बजाय Needs info में लौटाता है।
• In Progress → Resolved: fixed — डेवलपर — फ़िक्स merge, जिस build में है वह बताया गया, और जहाँ संभव हो failure को कवर करने वाला test जोड़ा गया।
• Resolved: fixed → Verified — टेस्टर, बेहतर हो तो रिपोर्टर — बताए गए build में मूल स्टेप और डेटा से confirmation test पास, और बदलाव के आसपास के तय regression checks हरे।
• Resolved: fixed → Reopened — टेस्टर — बताए गए build में मूल failure अब भी होता है; सबूत अटैच। Retest में मिली कोई अलग failure नया defect है।
• Reopened → Open / Assigned — test lead या ट्रायेज ग्रुप — defect retest के सबूत के साथ फ़िक्स के मालिक के पास लौटता है, और वहाँ से पहले की तरह In Progress में जाता है।
• Verified → Closed — टेस्टर या release manager — फ़िक्स target release में ship हो गया, या अगर यही तय नियम है तो टीम verification पर ही बंद करती है।
• Closed → Reopened — कोई भी, ट्रायेज के ज़रिए — फ़िक्स वाले build में वही failure फिर दिखा। अलग लक्षण को नया, लिंक किया defect मिलता है।
• Resolved (बिना फ़िक्स) → Closed — रिपोर्टर या QA — resolution स्वीकार करता है; असहमति हो तो defect comments की बहस के बजाय ट्रायेज में लौटता है।

Fixed के अलावा के अंत

बहुत से defect रिकॉर्ड बिना किसी कोड बदलाव के ख़त्म होते हैं। ISTQB Foundation syllabus बताता है कि रिपोर्ट की गई anomaly असल में defect निकले, यह ज़रूरी नहीं — वह false positive या change request भी हो सकती है। हर बिना-फ़िक्स अंत को ऐसा कारण चाहिए जिसे कोई महीनों बाद भी जाँच सके।

• Duplicate — वही मूल defect पहले से दर्ज है। मूल से लिंक करें, बेहतर सबूत वहाँ ले जाएँ, और नए रिकॉर्ड को resolve करें। एक जैसा लक्षण हमेशा एक जैसा कारण नहीं होता; शक हो तो फ़िक्स साबित करने तक दोनों को लिंक रखें।
• Rejected / invalid / not a bug — व्यवहार requirement के अनुसार है, या रिपोर्ट test की गलती से बनी, जैसे ग़लत डेटा या ग़लत environment। Requirement उद्धृत करें। अगर requirement ही ग़लत है तो वह requirements defect या change request है, rejection नहीं।
• Cannot reproduce / works for me — उपलब्ध जानकारी से कोई भी failure दोबारा नहीं ला पाता। क्या-क्या आज़माया (builds, devices, डेटा) दर्ज करें और logs व request ids रखें: intermittent defect अक्सर लौटते हैं, और पहली रिपोर्ट ही सबूत होती है।
• Won't fix — असली defect जिसे टीम ने ठीक न करने का फ़ैसला किया, आमतौर पर क्योंकि लागत असर से ज़्यादा है या फ़ीचर हटाया जा रहा है। यह बिज़नेस फ़ैसला है जिसका मालिक product owner है, और कारण के साथ दर्ज होता है।
• Deferred — असली defect जो बाद की रिलीज़ तक टाला गया। Won't fix के विपरीत यह खुला रहता है और release notes के साथ जाने वाली known-issues सूची में होता है।
• By design / as designed — व्यवहार जानबूझकर है। जब डिज़ाइन यूज़र को चौंकाता हो, तो सोचें कि क्या वह चौंकना ख़ुद एक usability defect है जिसका अलग रिकॉर्ड बनना चाहिए।

ट्रैकर इन्हें क्या कहते हैं: Bugzilla, Jira और issue tracker

Bugzilla का documentation अपने bug workflow को customizable बताता है और एक default workflow दिखाता है। Default में status हैं UNCONFIRMED, CONFIRMED, IN_PROGRESS, RESOLVED और VERIFIED, और resolved bug पर इनमें से एक resolution होता है: FIXED, INVALID, WONTFIX, DUPLICATE या WORKSFORME। Bugzilla की field help VERIFIED को वह बिंदु बताती है जहाँ QA ने bug और उसका resolution देखकर सहमति दी, और इसे अंतिम status कहती है। दो डिज़ाइन फ़ैसले अपनाने लायक हैं: resolution, status से अलग फ़ील्ड है, और "cannot reproduce" सिर्फ़ comment नहीं बल्कि औपचारिक अंत है।

Jira configurable रास्ता अपनाता है: हर workflow अपने status और transitions तय करता है, और admin तय करते हैं कि कौन-से resolutions उपलब्ध हों, इसलिए एक ही कंपनी के दो प्रोजेक्ट एक ही लाइफ़साइकल के लिए अलग नाम और रास्ते इस्तेमाल कर सकते हैं। हल्के issue tracker लगभग सिर्फ़ open और closed रखते हैं, और टीम बाक़ी labels (needs-info, duplicate, wontfix) और लिंक किए pull या merge requests से दिखाती है। टूल जो भी हो, अपने ट्रैकर के नामों को सामान्य लाइफ़साइकल से जोड़ने वाली एक पेज की mapping रखें ताकि मेट्रिक्स हर प्रोजेक्ट में एक ही मतलब रखें।

नीचे की टेबल ऐसे पढ़ें: New, Bugzilla में UNCONFIRMED है और उदाहरण वाले Jira प्रोजेक्ट में untriaged label के साथ Open; Open / Assigned, assignee के साथ CONFIRMED और assignee के साथ To Do; In Progress, दोनों में IN_PROGRESS / In Progress; Resolved: fixed, FIXED resolution के साथ RESOLVED और Fixed resolution के साथ Ready for QA; Resolved: other, INVALID, WONTFIX, DUPLICATE या WORKSFORME resolution के साथ RESOLVED और Duplicate, Won't Do या Cannot Reproduce resolution के साथ Done; Verified, Bugzilla में VERIFIED (जो वहाँ अंतिम status है) और Jira में Verified; Closed के लिए Bugzilla के default workflow में अलग state नहीं है, जबकि Jira में यह Closed है।

Generic state      Bugzilla default               Example Jira project (configured)
-----------------  -----------------------------  ---------------------------------
New                UNCONFIRMED                    Open + label "untriaged"
Open / Assigned    CONFIRMED + assignee           To Do + assignee
In Progress        IN_PROGRESS                    In Progress
Resolved: fixed    RESOLVED / FIXED               Ready for QA, resolution Fixed
Resolved: other    RESOLVED / INVALID, WONTFIX,   Done, resolution Duplicate,
                   DUPLICATE, WORKSFORME          Won't Do, Cannot Reproduce
Verified           VERIFIED (final status)        Verified
Closed             (no separate state)            Closed

Confirmation testing, regression testing और reopen

फ़िक्स के बाद दो अलग test होते हैं, और ISTQB syllabus इन्हें अलग-अलग नाम देता है। Confirmation testing, जिसे अक्सर retesting कहते हैं, फ़िक्स वाले build में फ़ेल हुए स्टेप दोबारा चलाता है ताकि पक्का हो कि defect चला गया। Regression testing जाँचता है कि बदलाव ने कुछ और नहीं तोड़ा: पड़ोसी फ़ीचर, बदले गए कोड को कॉल करने वाले दूसरे हिस्से, दूसरे प्लेटफ़ॉर्म और locales। पहला पास होने पर defect verified है; रिलीज़ तभी सुरक्षित है जब दूसरा भी पास हो।

Confirmation testing मूल डेटा और environment से शुरू होना चाहिए और फिर एक बार में एक चीज़ बदलनी चाहिए — दूसरा ब्राउज़र, दूसरा रोल, रिपोर्ट की गई value के बगल वाली boundary — क्योंकि फ़िक्स अक्सर ठीक वही रिपोर्ट किया केस कवर करता है और उसके भाई-बहन छोड़ देता है। Regression का दायरा बदलाव से आता है: diff ने कौन-से मॉड्यूल छुए और उन पर क्या निर्भर है। Smoke, sanity और regression testing गाइड बताती है कि इन suites का आकार कैसे तय करें।

• Retest resolution में बताए build में करें, "latest" में कभी नहीं। वह build deploy नहीं हुआ तो defect retest के लिए तैयार नहीं।
• Reopen सिर्फ़ उसी failure के लिए। नए लक्षण के लिए नया defect बनाएँ और उसे पहले वाले defect से लिंक करें; वरना दोनों का इतिहास पढ़ने लायक नहीं रहता।
• Reopen गिनें। दो बार reopen हुआ defect फ़िक्स प्रक्रिया के बारे में बताता है — कोई test नहीं जोड़ा, कोई review नहीं, अस्पष्ट expected result — सिर्फ़ उस defect के बारे में नहीं।
• Confirmation स्टेप को सबसे निचले level पर automated test में बदलें जहाँ वे व्यक्त हो सकें, ताकि defect चुपचाप न लौटे।

आज़माएँ: रिग्रेशन सिनेरियो जनरेटर

उदाहरण: एक defect खोज से क्लोज़र तक

नीचे एक काल्पनिक retail ऐप का काल्पनिक defect है, यथार्थवादी डेटा के साथ। कीमतें सऊदी रियाल (SAR) में हैं और 15% VAT लागू है; इस उदाहरण में प्रोडक्ट नियम यह है कि VAT डिस्काउंट के बाद की कीमत पर लगता है।

• ट्रायेज ने severity Major से Critical की क्योंकि टीम का स्केल ग़लत पेमेंट राशि को Critical में रखता है — severity स्केल से तय होती है, रिपोर्टर के पहले अनुमान से नहीं।
• Reopen सही था: वही मूल defect दूसरी स्क्रीन पर दिख रहा था। अलग लक्षण होता तो नया, लिंक किया रिकॉर्ड बनता।
• Verification ने बताया गया build इस्तेमाल किया और सिर्फ़ मूल स्टेप दोहराने के बजाय coupon का प्रकार और प्लेटफ़ॉर्म बदला।
• रिकॉर्ड में वह सब है जो बाद में मेट्रिक्स को चाहिए: कब और कहाँ मिला, age, reopen count और root cause origin।

DEF-2417  Android checkout charges 190.00 SAR instead of 184.00 with a fixed-amount coupon
Found in: system testing, release 5.3.0     Reporter: layla.h@example.com
Environment: Android app 5.3.0 (build 530-rc2), Android 14 emulator, staging, API v2

2026-09-14 09:40  NEW          Cart 200.00 SAR, coupon SAVE40 (-40.00). Expected (200 - 40) x 1.15 = 184.00.
                               Actual: charged 190.00 (VAT 30.00 computed on 200.00, then -40.00).
                               Web checkout, same account: correct. Request and response attached.
                               Reported severity: Major.
2026-09-14 14:00  OPEN         Triage: reproduced 3/3 by a second tester; no duplicate ("VAT", "coupon").
                               Severity raised to Critical (customer charged a wrong amount).
                               Priority Highest (release 5.3.0 due 2026-09-21).
                               Owner: omar.k (payments API). Target: 5.3.0.
2026-09-15 10:15  IN PROGRESS  API v2 POST /orders/price applies the coupon after VAT; v1 was changed
                               in 5.1 when the rule changed, v2 was not.
2026-09-15 17:30  RESOLVED     Fixed in build 530-rc3. API tests added for fixed and % coupons.
2026-09-16 11:05  REOPENED     Retest on rc3: amount charged is 184.00, but the order summary before
                               payment still shows 190.00 (GET /orders/summary, v2). Same defect.
2026-09-16 11:20  OPEN         Back to omar.k with the retest evidence. Target unchanged: 5.3.0.
2026-09-16 13:40  IN PROGRESS  GET /orders/summary (v2) still calls the old pricing function.
2026-09-16 18:20  RESOLVED     Fixed in build 530-rc4: summary uses the corrected pricing function.
2026-09-17 12:40  VERIFIED     Confirmation on rc4: 184.00 on both screens; also 20% coupon, web and
                               Android. Regression: checkout and pricing pack 38/38 passed.
2026-09-21 16:00  CLOSED       Shipped in 5.3.0.

Age at verification: 3 d 3 h   Reopen count: 1   Found in: system test
Root cause origin: requirements (rule change scoped to web only); contributing: code, test

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

Defect aging, defect मेट्रिक्स और summary report

Defect age वह समय है जितने दिन defect खुला रहा: खुले defect के लिए बनने से अब तक, और पूरे हो चुके defect के लिए resolution या closure तक — एक परिभाषा चुनें और उसी पर टिकें। हर स्टेट में बिताया समय कुल age से ज़्यादा उपयोगी है, क्योंकि वह दिखाता है कि defect कहाँ रुके हैं: New में दिन मतलब ट्रायेज नहीं हो रहा; Resolved में दिन मतलब retest queue bottleneck है; Needs info में दिन मतलब रिपोर्टों में तथ्य कम हैं।

कुछ ही defect मेट्रिक्स असली फ़ैसलों में मदद करते हैं: severity और age के हिसाब से खुले defect (release readiness), समय के साथ आने वाले बनाम बंद होने वाले (क्या backlog घट रहा है?), reopen rate (फ़िक्स की गुणवत्ता), rejected और duplicate rate (रिपोर्ट की गुणवत्ता और ट्रैकर search), और हर चरण में मिले defect का production की तुलना में हिस्सा — ISTQB glossary में defect detection percentage के पीछे यही विचार है। Test metrics गाइड परिभाषाएँ, फ़ॉर्मूले और मेट्रिक्स के साथ होने वाली हेराफेरी कवर करती है।

Defect summary report यह सब उन लोगों के सामने रखती है जो ट्रैकर में नहीं रहते, आमतौर पर test progress report या test completion report के हिस्से के रूप में। इसमें संख्याएँ और रुझान होते हैं, और उन ख़ास खुले defect के नाम जो रिलीज़ के फ़ैसले पर असर डालते हैं, हर एक की severity, priority, मालिक और योजना के साथ।

• हर severity के लिए age की सीमा तय करें — जैसे Critical defect एक working day बाद भी untriaged, या Major defect तीन दिन से ज़्यादा Resolved में — और हर हफ़्ते उल्लंघन review करें।
• Deferred defect साफ़-साफ़ रिपोर्ट करें; deferred defect रिलीज़ में ज्ञात जोखिम है, बंद defect नहीं।

Defect summary - release 5.3.0 - week ending 2026-09-18
Open by severity:     Blocker 0 | Critical 1 | Major 6 | Minor 14 | Trivial 9   (total 30)
Arrivals / closures:  23 / 31 this week (backlog down 8)
Age of open defects:  under 7 d: 18 | 7-30 d: 9 | over 30 d: 3 (all Minor, deferred to 5.4)
Reopen rate:          3 of 58 fixes in the last 4 weeks (5%)
Found in:             reviews 11 | system test 37 | UAT 6 | production 2
Release-relevant:     DEF-2451 Critical / Highest / omar.k - fix in rc5, retest 2026-09-19
Deferred, risk accepted by product owner on 2026-09-17: DEF-2290, DEF-2304

लाइफ़साइकल अच्छी तरह चलाना: चेकलिस्ट

AI सहायता लाइफ़साइकल के टेक्स्ट-भारी स्टेप में फ़िट बैठती है: कच्चे नोट्स को structured रिपोर्ट में बदलना, searchable टाइटल सुझाना, justification के साथ severity और priority सुझाना, और stack trace समझाना। आउटपुट को ड्राफ़्ट मानें — टेस्टर स्टेप और सबूत की पुष्टि करता है, और अंतिम severity व priority ट्रायेज तय करता है।

• हर प्रोडक्ट के लिए एक ट्रैकर और एक documented workflow, सामान्य स्टेट से mapping के साथ।
• हर स्टेट का मालिक और exit condition; सबसे अहम शर्तें required fields से लागू हों।
• तय ट्रायेज cadence, और untriaged queue लगभग शून्य।
• हर बिना-फ़िक्स resolution के लिए अनिवार्य कारण, duplicate लिंक के साथ।
• हर फ़िक्स अपना build बताए; हर retest उसी build में हो; regression का दायरा diff से आए।
• हर defect कहाँ मिला और उसका root cause origin दर्ज करें, ताकि escapes मापे जा सकें।
• रिलीज़ के दौरान हर हफ़्ते aging, reopen rate और deferred सूची review करें।

आज़माएँ: AI बग टाइटल जनरेटर आज़माएँ: AI बग विवरण जनरेटर आज़माएँ: AI बग गंभीरता सुझाव आज़माएँ: AI बग प्राथमिकता सुझाव आज़माएँ: AI एरर मैसेज एनालाइज़र

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

संदर्भ

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
• ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
• 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 का ठोस उदाहरण।
• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021टेस्ट दस्तावेज़ों के टेम्पलेट और सामग्री — test policy, strategy, plan, status व completion रिपोर्ट, incident रिपोर्ट।
• Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024टेस्टिंग प्रबंधन पर ISTQB का advanced पाठ्यक्रम: टेस्ट योजना और अनुमान, risk-based testing, निगरानी, मेट्रिक्स और रिपोर्टिंग।