बग रिपोर्ट कैसे लिखें
बग रिपोर्ट का एक ही काम है: जो वहाँ मौजूद नहीं था, वह समस्या को रिप्रोड्यूस कर सके, उसका असर समझ सके और आपसे एक भी सवाल पूछे बिना उसे ठीक कर सके। जो रिपोर्ट यह करती हैं वे ठीक होती हैं; जो नहीं करतीं उन्हें "cannot reproduce" का लेबल लगाकर बंद कर दिया जाता है। फ़र्क़ लेखन कौशल का नहीं है — सही तथ्य सही क्रम में शामिल करने का है।
यह गाइड ऐसी रिपोर्ट की बनावट देती है जिस पर काम होता है, Jira, GitHub Issues या किसी भी ट्रैकर के लिए टेम्पलेट, पूरा उदाहरण, और उन दो फ़ील्ड की साफ़ व्याख्या जिनमें लोग सबसे ज़्यादा उलझते हैं: severity और priority।
अच्छी बग रिपोर्ट में क्या होता है
- टाइटल — एक खास लाइन में लक्षण: "डिस्काउंट वाला आइटम कार्ट में होने पर Checkout 500 देता है" "Checkout टूटा है" से बेहतर है।
- एनवायरनमेंट — ऐप वर्ज़न या बिल्ड, ब्राउज़र/OS या डिवाइस, API एनवायरनमेंट (staging, production), इस्तेमाल किया अकाउंट या रोल।
- प्रीकंडीशन — स्टेप से पहले क्या सच होना चाहिए: कार्ट में आइटम वाला लॉग-इन यूज़र, कोई खास फ़ीचर फ़्लैग।
- रिप्रोड्यूस करने के स्टेप — नंबर वाले, न्यूनतम, सटीक। इस्तेमाल किया डेटा (या जनरेट किया समकक्ष) और API बग हो तो रिक्वेस्ट शामिल करें।
- अपेक्षित परिणाम — क्या होना चाहिए था, बेहतर हो तो requirement या डिज़ाइन के रेफ़रेंस के साथ।
- वास्तविक परिणाम — इसके बजाय क्या हुआ, हूबहू उद्धृत: मैसेज, स्टेटस कोड, गलत वैल्यू।
- सबूत — स्क्रीनशॉट या रिकॉर्डिंग, HTTP रिक्वेस्ट और रिस्पॉन्स, कंसोल या सर्वर लॉग लाइन, स्टैक ट्रेस।
- फ़्रीक्वेंसी — हमेशा, कभी-कभी (कितनी बार), सिर्फ़ पहले लोड पर।
- Severity और priority — यह कितना बुरा है और कितनी जल्दी ठीक होना चाहिए (नीचे देखें)।
बग रिपोर्ट टेम्पलेट
Title: Checkout returns 500 when the cart contains a discounted item
Environment: Web app 4.12.0 · Chrome 128 / Windows 11 · staging · customer role
Severity: Major Priority: High Frequency: Always
Preconditions:
- Logged in as a verified customer
- Cart contains one item with an active 20% discount (SKU A-100)
Steps to reproduce:
1. Open /checkout
2. Select "Card" as the payment method
3. Click "Place order"
Expected result:
Order is created (201), confirmation page shows the discounted total 199.20
Actual result:
Page shows "Something went wrong". POST /api/v1/orders returns 500:
{"error":{"code":"INTERNAL","requestId":"9f1c…"}}
Evidence:
- screenshot-checkout-500.png
- request/response captured (attached)
- server log: TypeError: cannot read "rate" of undefined (discount.ts:41)
Notes:
Works when the cart has no discounted item. Started after release 4.12.0.आज़माएँ: AI बग विवरण जनरेटर आज़माएँ: HTTP रिक्वेस्ट इंस्पेक्टर
Severity बनाम Priority
Severity सिस्टम या यूज़र पर असर मापती है: कितना टूटा है और किसके लिए। Priority बिज़नेस के लिए तात्कालिकता मापती है: दूसरे काम की तुलना में यह कितनी जल्दी ठीक होना चाहिए। इन्हें अलग-अलग लोग तय करते हैं और अक्सर ये मेल नहीं खातीं।
लॉगिन पेज पर कंपनी के नाम में टाइपो trivial severity लेकिन high priority है। तिमाही में एक बार चलने वाला एडमिन export, जो बिना बताए कुछ rows छोड़ देता है, Critical severity (डेटा लॉस) लेकिन अगला रन पास आने तक low priority है। दोनों को अलग-अलग दर्ज करना ही टीम को ईमानदारी से प्लान करने देता है।
- Severity — Blocker (कोर फ़्लो बेकार, कोई वर्कअराउंड नहीं), Critical (डेटा लॉस या करप्शन, सिक्योरिटी एक्सपोज़र, पेमेंट फ़ेल, या ज़्यादातर यूज़र के लिए कोई बड़ा फ़ंक्शन टूटा), Major (अहम फ़ंक्शन टूटा पर वर्कअराउंड मौजूद, या कम यूज़र प्रभावित), Minor (छोटा फ़ंक्शनल, कॉस्मेटिक या एज-केस दोष), Trivial (टाइपो या नगण्य कॉस्मेटिक ब्यौरा) — ऊपर से जाँचें और जो पहला फ़िट हो वही लें।
- Priority — Highest / High (रिलीज़ से पहले या अभी ठीक करें), Medium (अगला स्प्रिंट), Low (बैकलॉग)।
आज़माएँ: AI बग गंभीरता सुझाव आज़माएँ: AI बग प्राथमिकता सुझाव
फ़ाइल करने से पहले: बग को अलग करें
- इसे दो बार रिप्रोड्यूस करें। एक बार हो तो intermittent लिखें और दर्ज करें क्या अलग था।
- स्टेप को उतने न्यूनतम करें जितने में यह अब भी ट्रिगर हो। जो नतीजा न बदले उसे हटा दें।
- एक बार में एक वेरिएबल बदलें — दूसरा ब्राउज़र, दूसरा अकाउंट, दूसरा डेटा — ट्रिगर खोजने के लिए।
- जाँचें कि पहले से रिपोर्ट तो नहीं: ट्रैकर में एरर मैसेज और एंडपॉइंट खोजें।
- सबूत तभी कैप्चर करें जब वह स्क्रीन पर हो: रिक्वेस्ट, रिस्पॉन्स, कंसोल, सटीक मैसेज।
आज़माएँ: AI एरर मैसेज एनालाइज़र आज़माएँ: API रिस्पॉन्स एनालाइज़र
वे गलतियाँ जिनसे रिपोर्ट वापस लौटती हैं
- कोई स्टेप नहीं, सिर्फ़ लक्षण का वर्णन।
- वास्तविक परिणाम में "काम नहीं करता", बिना मैसेज, कोड या स्क्रीनशॉट।
- एक रिपोर्ट में कई बग — हर बग को अपना लाइफ़साइकल चाहिए।
- टाइटल में राय ("यह बहुत बुरा है") लक्षण की जगह।
- रिपोर्ट में असली कस्टमर डेटा पेस्ट करना। वही शेप देने वाला जनरेट किया टेस्ट डेटा इस्तेमाल करें।
- एनवायरनमेंट गायब — जो बग सिर्फ़ iOS के Safari पर दिखता है, वह न बताने पर पूरा दिन बर्बाद करता है।
API बग रिपोर्ट करना
API डिफ़ेक्ट में रिप्रोडक्शन ही रिक्वेस्ट है। मेथड, URL, हेडर (टोकन हटाकर), बॉडी, और पूरा रिस्पॉन्स — स्टेटस, हेडर और बॉडी — शामिल करें, साथ में request id अगर API लौटाता है। cURL कमांड सबसे पोर्टेबल रूप है: डेवलपर उसे पेस्ट करके तुरंत फ़ेलियर देख सकता है।
अक्सर पूछे जाने वाले सवाल
severity और priority में क्या फ़र्क़ है?
Severity यह है कि बग सिस्टम या यूज़र को कितनी बुरी तरह प्रभावित करता है; priority यह है कि बिज़नेस उसे कितनी जल्दी ठीक चाहता है। होमपेज पर कॉस्मेटिक बग low severity और high priority हो सकता है।
बग रिपोर्ट में कितने स्टेप होने चाहिए?
उतने कम जितने में समस्या भरोसेमंद तरीके से रिप्रोड्यूस हो — आमतौर पर तीन से सात। हर स्टेप एक ऐसा एक्शन हो जिसे कोई अजनबी कर सके।
क्या स्क्रीनशॉट शामिल करना चाहिए?
हाँ, जब भी बग दिखाई देता हो। API बग के लिए इसकी जगह रिक्वेस्ट और रिस्पॉन्स शामिल करें; क्रैश के लिए स्टैक ट्रेस या लॉग लाइन।
अच्छा बग टाइटल क्या बनाता है?
लक्षण, जगह और शर्त एक लाइन में: "तीन बार गलत OTP डालने के बाद लॉगिन पेज खाली स्क्रीन दिखाता है"।
क्या AI बग रिपोर्ट लिख सकता है?
AI कच्चे नोट्स, एरर मैसेज या कैप्चर की गई रिक्वेस्ट को साफ़ टाइटल और सुझाई severity वाली सुव्यवस्थित रिपोर्ट में बदल सकता है। फ़ाइल करने से पहले टेस्टर फिर भी स्टेप और असर वेरिफ़ाई करता है।
अगर बग लगातार रिप्रोड्यूस न हो तो?
फिर भी फ़ाइल करें, intermittent मार्क करें, बताएँ कितनी बार होता है, और जिन बार हुआ उनके हर सबूत — लॉग, टाइमस्टैम्प, request id — अटैच करें। कई रिपोर्ट से पैटर्न उभरते हैं।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
अभ्यास
कमज़ोर बग रिपोर्ट दोबारा लिखें: फ़ेल हुआ बिल पेमेंट
आप एक काल्पनिक बैंक की वेब बैंकिंग का रिलीज़ 7.3.0 staging एनवायरनमेंट पर टेस्ट कर रहे हैं। बिल पेमेंट टेस्ट करते समय एक साथी को समस्या मिली; उसने नीचे वाला ड्राफ़्ट ट्रैकर में बिना फ़ाइल किए छोड़ दिया और आपसे उसे पूरा करने को कहा। तब से आप समस्या ख़ुद रिप्रोड्यूस कर चुके हैं: आपके नोट्स, requirement और साथी की ब्राउज़र से कॉपी की गई रिक्वेस्ट मटीरियल में हैं।
ड्राफ़्ट को ऐसी रिपोर्ट में बदलें जिस पर डेवलपर आपसे एक भी सवाल पूछे बिना काम कर सके। पहले तय करें कि ड्राफ़्ट में क्या अलग defect है, क्या मुख्य रिपोर्ट का हिस्सा है और क्या defect है ही नहीं। फिर पेमेंट failure की पूरी रिपोर्ट गाइड के हर फ़ील्ड के साथ लिखें — टाइटल, एनवायरनमेंट, प्रीकंडीशन, रिप्रोड्यूस करने के स्टेप, अपेक्षित परिणाम, वास्तविक परिणाम, सबूत, फ़्रीक्वेंसी, severity और priority — साथ में नोट्स कि आपने क्या isolate किया। दूसरे defect के लिए टाइटल और सुझाई गई severity व priority काफ़ी है।
काग़ज़ और पेन काफ़ी हैं; लगभग 25 मिनट रखें। cURL पार्सर कॉपी किए गए कमांड को हेडर में तोड़ देता है ताकि आप तय कर सकें कि क्या रखना है, और cURL जनरेटर साफ़ कमांड दोबारा बना देता है। बाद में तुलना चाहें तो गाइड की टूल सूची का AI बग विवरण जनरेटर (sign-in ज़रूरी) उन्हीं नोट्स से रिपोर्ट बना देता है — नोट्स को टोकन और cookies के बिना पेस्ट करें, और उसके ड्राफ़्ट को अपने वर्ज़न से परखें, उल्टा नहीं।
काल्पनिक बैंक, वेब बैंकिंग। रिलीज़ 7.3.0 staging एनवायरनमेंट पर टेस्टिंग में है।
Production और UAT एनवायरनमेंट अब भी 7.2.4 चलाते हैं।
Requirement BILL-3: बिल पेमेंट
ग्राहक किसी saved biller को अपने किसी अकाउंट से 1.00 से 10,000.00 SAR तक की कोई भी
राशि, अधिकतम दो decimal places के साथ, चुकाता है। सफल होने पर पेमेंट reference number
के साथ अकाउंट history में दिखता है, और confirmation पेज वही नंबर दिखाता है।
--- एक साथी का ट्रैकर में छोड़ा ड्राफ़्ट (फ़ाइल नहीं हुआ) ---
Title: बिल पेमेंट पूरी तरह टूटा है!!! URGENT
Description: बिजली का बिल भरने की कोशिश की, काम नहीं करता, हर बार error। और मोबाइल
पर Arabic में pay बटन कटा हुआ है, और error मैसेज बेकार है, उसे बताना चाहिए कि
गलत क्या है। जल्दी से जल्दी ठीक करें।
Request (ब्राउज़र से Copy as cURL):
curl 'https://staging.bank.example/api/v2/bill-payments' \
-H 'accept: application/json' \
-H 'accept-language: en-US,en;q=0.9' \
-H 'authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJ0ZXN0LWN1c3QtMDcifQ...' \
-H 'content-type: application/json' \
-b 'SESSION=7f3c9a1e52d84b0c; _ga=GA1.2.884120.1727' \
-H 'sec-ch-ua-platform: "Windows"' \
-H 'user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/129.0.0.0' \
--data-raw '{"billerId":"BLR-ELEC-01","fromAccount":"ACC-TEST-0007","amount":"250.75"}'
Response: 500
{"error":{"code":"INTERNAL","message":"Unexpected error","requestId":"b7e2-41c9"}}
--- आपके रिप्रोडक्शन नोट्स (staging, build 7.3.0, retail customer, English UI) ---
फ़्लो: Payments > Pay a bill > biller चुनें > अकाउंट चुनें > Amount > "Pay bill"।
Run 1: Chrome 129 / Windows 11, test-cust-07, biller Electricity, 250.00: पेमेंट
हुआ, reference दिखा, बैलेंस 250.00 घटा।
Run 2: run 1 जैसा, 250.75 के साथ: लाल बैनर "Something went wrong. Please try
again later." POST /api/v2/bill-payments ने ऊपर वाले रिस्पॉन्स के साथ 500
लौटाया। History में कोई पेमेंट नहीं, बैलेंस नहीं बदला।
Run 3: run 2 दोहराया: वही नतीजा।
Run 4: Firefox 131 / Windows 11, test-cust-07, Electricity, 250.75: वही नतीजा।
Run 5: Chrome, test-cust-12, biller Water, 99.50: वही नतीजा।
Run 6: Chrome, test-cust-07, Electricity, 1000.00: पेमेंट हुआ, reference दिखा।
Run 7: UAT (build 7.2.4), Chrome, uat-cust-03, Electricity, 250.75: पेमेंट हुआ,
reference दिखा।
सर्वर लॉग व्यूअर, requestId b7e2-41c9 (exception और application का पहला stack frame):
java.lang.NumberFormatException: For input string: "250.75"
at bank.payments.AmountMapper.toMinorUnits(AmountMapper.java:58)
ट्रैकर में "bill-payments" और "NumberFormatException" खोजा: कोई open defect नहीं।
मोबाइल जाँच: Chrome device toolbar, 360 px चौड़ाई। Arabic UI में pay बटन का लेबल
शब्द के बीच में कट जाता है; 412 px पर पूरा दिखता है। English लेबल 360 px पर
पूरा दिखता है। बटन टैप करना अब भी काम करता है।- ड्राफ़्ट पढ़ें और उसमें बताई हर अलग समस्या लिखें। हर एक के लिए तय करें: अपनी अलग रिपोर्ट, मुख्य रिपोर्ट का हिस्सा, या defect नहीं।
- अपने नोट्स के runs की तुलना एक बार में एक वेरिएबल लेकर करें: ब्राउज़र, अकाउंट, biller, राशि। लिखें कि failure को क्या ट्रिगर करता है और किससे कोई फ़र्क़ नहीं पड़ता।
- टाइटल लिखें: लक्षण, जगह और शर्त एक लाइन में, बिना राय के।
- एनवायरनमेंट, प्रीकंडीशन और सटीक डेटा के साथ न्यूनतम नंबर वाले स्टेप लिखें, फिर BILL-3 के रेफ़रेंस के साथ अपेक्षित परिणाम और हूबहू उद्धृत वास्तविक परिणाम।
- सबूत साफ़ करें: सिर्फ़ वही रखें जो रिक्वेस्ट को रिप्रोड्यूस करे, bearer टोकन की जगह placeholder रखें, cookies हटाएँ, और वे हेडर निकाल दें जो ब्राउज़र अपने आप जोड़ता है।
- गाइड के स्केल से फ़्रीक्वेंसी, severity और priority तय करें, हर एक के साथ एक वाक्य का कारण; फिर दूसरे defect का टाइटल, severity और priority लिखें।
मॉडल उत्तर दिखाएँ
ड्राफ़्ट को छाँटना (स्टेप 1)। इसमें तीन समस्याएँ मिली हुई हैं। पहली, कुछ राशियों पर बिल पेमेंट फ़ेल होता है: यही मुख्य defect है और इसकी अपनी रिपोर्ट बनती है। दूसरी, संकरी चौड़ाई पर Arabic UI में pay बटन का लेबल कट जाता है: यह अलग defect है जिसका कारण, fix और लाइफ़साइकल अलग है, इसलिए इसकी भी अलग रिपोर्ट बनती है। तीसरी, "error मैसेज बेकार है": अनपेक्षित server error पर सामान्य मैसेज दिखाना उचित व्यवहार है, BILL-3 error के शब्दों के बारे में कुछ नहीं कहता, और 500 ठीक होते ही इन पेमेंट पर यह मैसेज दिखेगा ही नहीं। यह defect नहीं है; अगर आपको लगता है कि शब्द बदलने चाहिए, तो इसे product owner के सामने अलग improvement सुझाव के रूप में रखें। कॉपी की गई रिक्वेस्ट और 500 वाला रिस्पॉन्स अपने आप में समस्याएँ नहीं हैं: साफ़ करने के बाद (स्टेप 5) वे मुख्य रिपोर्ट में सबूत के रूप में जाते हैं। बाक़ी किसी रिपोर्ट में नहीं जाता: "पूरी तरह टूटा है", "URGENT" और "जल्दी से जल्दी" राय है, और "हर बार error" बिना मापा दावा है जिसे run 1 और 6 ग़लत साबित करते हैं।
ट्रिगर को isolate करना (स्टेप 2)। Run 1 और 2 में सिर्फ़ राशि का फ़र्क़ है: 250.00 सफल होता है और 250.75 फ़ेल, और run 3, run 2 को दोहराकर वही नतीजा देता है, इसलिए यह एक बार की घटना नहीं। ब्राउज़र बदलने (run 4) से कुछ नहीं बदलता। Run 5 अकाउंट, biller और राशि तीनों एक साथ बदलता है और फिर भी फ़ेल होता है, इसलिए failure इनमें से किसी ख़ास वैल्यू पर निर्भर नहीं। Run 6 (1000.00) run 1 की तरह सफल होता है। तो ट्रिगर है ऐसी राशि जिसका decimal हिस्सा शून्य नहीं है। Run 7, 7.2.4 पर सफल होता है, जो 7.3.0 में आए regression की ओर इशारा करता है; पर UAT, staging से build के अलावा और बातों में भी अलग है, इसलिए इसे पक्का तथ्य नहीं, मज़बूत संकेत के रूप में लिखें। लॉग लाइन डेवलपर को बताती है कि कहाँ देखना है (AmountMapper.java:58), पर टेस्टर उसे सबूत के रूप में देता है, टाइटल में निदान के रूप में नहीं।
मुख्य defect की मॉडल रिपोर्ट। टाइटल: Pay a bill 500 लौटाता है और कोई पेमेंट नहीं बनाता जब राशि का decimal हिस्सा शून्य न हो, जैसे 250.75। एनवायरनमेंट: वेब बैंकिंग 7.3.0, staging, English UI; Chrome 129 / Windows 11, Firefox 131 / Windows 11 पर भी रिप्रोड्यूस हुआ; retail customer रोल, टेस्ट अकाउंट test-cust-07 और test-cust-12। Severity: Critical। Priority: High। फ़्रीक्वेंसी: हमेशा — ऐसी राशि वाली चारों कोशिशें फ़ेल हुईं (run 2 से 5), और बिना decimal वाली दोनों राशियाँ सफल रहीं।
प्रीकंडीशन: retail customer के रूप में लॉग-इन (जैसे test-cust-07), एक saved biller (Electricity, BLR-ELEC-01) और एक अकाउंट (ACC-TEST-0007) जिसका बैलेंस राशि के लिए काफ़ी हो। रिप्रोड्यूस करने के स्टेप: 1. Payments > Pay a bill खोलें। 2. Biller Electricity और अकाउंट ACC-TEST-0007 चुनें। 3. Amount में 250.75 डालें। 4. "Pay bill" पर क्लिक करें।
अपेक्षित परिणाम: पेमेंट बनता है, confirmation पेज reference number दिखाता है, पेमेंट उसी नंबर के साथ अकाउंट history में दिखता है, और बैलेंस 250.75 घटता है (BILL-3: 1.00 से 10,000.00 SAR तक कोई भी राशि, अधिकतम दो decimal places के साथ)। वास्तविक परिणाम: लाल बैनर "Something went wrong. Please try again later." दिखता है; POST /api/v2/bill-payments 500 लौटाता है, बॉडी {"error":{"code":"INTERNAL","message":"Unexpected error","requestId":"b7e2-41c9"}}; history में कोई पेमेंट नहीं दिखता और बैलेंस नहीं बदलता।
सबूत: बैनर का स्क्रीनशॉट; ऊपर वाला रिस्पॉन्स; request id b7e2-41c9 की सर्वर लॉग लाइन java.lang.NumberFormatException: For input string: "250.75", जो bank.payments.AmountMapper.toMinorUnits(AmountMapper.java:58) पर आई; और साफ़ किया हुआ cURL कमांड: curl 'https://staging.bank.example/api/v2/bill-payments' -H 'accept: application/json' -H 'authorization: Bearer [REDACTED]' -H 'content-type: application/json' --data-raw '{"billerId":"BLR-ELEC-01","fromAccount":"ACC-TEST-0007","amount":"250.75"}'। Bearer टोकन की जगह [REDACTED] लिखा गया है, क्योंकि जब तक वह valid है, ट्रैकर पढ़ सकने वाला कोई भी उसे इस्तेमाल कर सकता है; उसकी जगह डेवलपर अपने टेस्ट अकाउंट का टोकन डालता है। पूरा -b ऑप्शन भी हटता है: उसमें session cookie है, जो उतनी ही इस्तेमाल लायक है, और analytics cookie _ga है। कॉपी किए गए कमांड में cookies हेडर की जगह -b में भी हो सकती हैं, इसलिए redact करते समय दोनों जगह देखें। accept-language, sec-ch-ua-platform और user-agent हेडर हटते हैं क्योंकि ब्राउज़र उन्हें अपने आप जोड़ता है और run 4 दिखाता है कि ब्राउज़र से फ़र्क़ नहीं पड़ता। accept और content-type हेडर रहते हैं क्योंकि वे बताते हैं कि रिक्वेस्ट क्या भेजती है और बदले में क्या चाहती है; content-type के बिना curl --data-raw बॉडी को application/x-www-form-urlencoded बताकर भेजेगा। असली काम में अटैच करने से पहले साफ़ कमांड को अपने नए टोकन के साथ एक बार चलाएँ: अगर वह फिर भी 500 लौटाए, तो आपने जो हटाया उसकी ज़रूरत नहीं थी।
नोट्स: बिना decimal वाली राशियाँ सफल होती हैं (250.00, 1000.00); failure ब्राउज़र, अकाउंट या biller पर निर्भर नहीं (run 4 और 5)। 250.75 का वही पेमेंट UAT पर सफल होता है, जो 7.2.4 चलाता है, इसलिए शायद 7.3.0 ने इसे पैदा किया; UAT, staging से build के अलावा और बातों में भी अलग है, इसलिए यह सबूत नहीं, मज़बूत संकेत है। bill-payments या NumberFormatException के लिए कोई open defect नहीं मिला।
Critical क्यों: गाइड के severity स्केल पर ऊपर से नीचे जाएँ। Blocker फ़िट नहीं होता, क्योंकि बिना decimal वाली राशियों के लिए बिल पेमेंट अब भी काम करता है। Critical फ़िट होता है: यह पेमेंट फ़ेल है, और जिस बिल में decimal हिस्सा है उसकी सटीक राशि ग्राहक चुका ही नहीं सकता। कुछ टीमें Blocker की दलील देंगी क्योंकि कई असली बिलों में decimal हिस्सा होता है; इस तर्क के साथ दोनों में से कोई भी स्तर ठीक है, पर Major या उससे नीचे नहीं, क्योंकि पेमेंट फ़ेल होते हैं। High क्यों: production अब भी 7.2.4 चलाता है, वही build जिस पर UAT में वही पेमेंट सफल होता है, इसलिए इस defect के साथ 7.3.0 रिलीज़ करने से ग्राहकों का हर ऐसा बिल पेमेंट फ़ेल होगा जिसकी राशि का decimal हिस्सा शून्य नहीं है — इसे रिलीज़ से पहले ठीक होना चाहिए। अगर 7.3.0 पहले से live होता, तो priority Highest होती। टेस्टर के रूप में आप priority सुझाते हैं; triage मीटिंग या product owner उसे तय करता है।
दूसरी रिपोर्ट। टाइटल: 360 px viewport चौड़ाई पर Arabic UI में Pay bill बटन का लेबल कट जाता है। एनवायरनमेंट: वेब बैंकिंग 7.3.0, staging, Chrome device toolbar 360 px पर; लेबल 412 px पर पूरा दिखता है, और English लेबल 360 px पर पूरा दिखता है। Severity: Minor — कॉस्मेटिक, बटन अब भी काम करता है। Priority: Medium, सुझाव के तौर पर (अगला स्प्रिंट), क्योंकि संकरे फ़ोन पर Arabic यूज़र के लिए यह पेज का मुख्य एक्शन है; product owner रिलीज़ से पहले इसे High कर सकता है। 360 px और 412 px के स्क्रीनशॉट अटैच करें, और हो सके तो उसी चौड़ाई वाले असली फ़ोन पर पुष्टि करके उसका नाम लिखें: device emulation असली डिवाइस नहीं है।
Fix के बाद: confirmation testing उन्हीं स्टेप को 250.75 और 99.50 के साथ दोहराती है। बदलाव के आसपास regression जाँचें जोड़ें: बिना decimal वाली राशियाँ, BILL-3 की boundaries (1.00 और 10,000.00 accept, 0.99 और 10,000.01 reject), एक decimal place वाली राशि, जैसे 250.5 (accept), और तीन decimal places वाली, जैसे 250.755 (reject, क्योंकि BILL-3 अधिकतम दो की अनुमति देता है)।
अपना काम जाँचें। आपकी रिपोर्ट पूरी है अगर ड्राफ़्ट कभी न देखने वाला डेवलपर सिर्फ़ आपके स्टेप से failure रिप्रोड्यूस कर सके; टाइटल बिना राय के लक्षण, जगह और शर्त बताए; स्टेप एक सटीक राशि इस्तेमाल करें और बाक़ी runs नोट्स के लिए छोड़ें; अपेक्षित परिणाम BILL-3 का हवाला दे; वास्तविक परिणाम बैनर, स्टेटस कोड और request id हूबहू उद्धृत करे; टोकन redact हो और cookies हट चुकी हों; severity और priority अलग-अलग, हर एक कारण के साथ तय हों; और न बटन वाला defect, न error मैसेज के शब्दों की शिकायत इस रिपोर्ट में हो। ISTQB की भाषा में आपने एक failure देखा — 500 और ग़ायब पेमेंट; रिपोर्ट डेवलपर को उसके पीछे का defect ढूँढने के लिए ज़रूरी सब कुछ देती है, और लॉग लाइन सबूत है, आपका निदान नहीं।
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।
QA रोडमैप का हिस्सा
इस गाइड में बताए गए टूल्स
मोटे-मोटे नोट्स को पूरी बग रिपोर्ट में बदलें: reproduce करने के स्टेप, अपेक्षित बनाम वास्तविक, environment, गंभीरता और attachments चेकलिस्ट।
Mutqan AI से बिखरे हुए विवरण से स्पष्ट और खोजने में आसान बग टाइटल बनाएँ।
Mutqan AI से कारण सहित सुझाई गई गंभीरता (Blocker / Critical / Major / Minor / Trivial) पाएँ।
Mutqan AI से व्यावसायिक प्रभाव, प्रभावित यूज़र, समयसीमा और गंभीरता को देखते हुए सुझाई गई प्राथमिकता (P0–P3) पाएँ।
Mutqan AI से stack trace और एरर मैसेज समझें, संभावित मूल कारण पहचानें और डिबगिंग के अगले क़दम जानें।
देखें कि आपका क्लाइंट असल में क्या भेजता है: method, हेडर, query, बॉडी, IP और TLS जानकारी।
किसी API रिस्पॉन्स का विश्लेषण करें: संरचना, फ़ील्ड टाइप, null, डुप्लिकेट, साइज़ और संभावित डेटा-क्वालिटी समस्याएँ।
सिंथेटिक टेस्ट डेटा की एक ही जगह पर फ़ैक्टरी: users, customers, companies, पते, संख्याएँ, तारीख़ें और स्ट्रिंग — JSON, CSV, SQL या XML में।