फ़ेल और ब्लॉक्ड टेस्ट
Test तब fail होता है जब वह चलता है और actual result, expected result से अलग आता है। Test तब blocked होता है जब वह चल ही नहीं पाता, या उस step तक नहीं पहुँच पाता जिसे वह check करता है, क्योंकि test के बाहर की कोई चीज़ रास्ता रोक रही है: पिछले step में defect, बंद environment, या missing data या access। अगर cart में bundle जोड़ना fail होता है, तो bundle जोड़ने का test fail होता है, और bundle discount वाला test, जिसे cart में bundle चाहिए, blocked होता है।
Failed result अभी product defect साबित नहीं करता: ISTQB के अनुसार test execution में actual results की expected results से तुलना होती है, और हर anomaly का analysis करके उसका संभावित कारण खोजा जाता है, उसके बाद ही उसे report किया जाता है।
यह क्यों ज़रूरी है
गलती से product defect के रूप में report हुआ failed test developer का समय बर्बाद करता है, reject होता है और अगली report का थोड़ा भरोसा छीन लेता है। असली failure को "बस environment है" कहकर टाल देना और बुरा है: defect users तक पहुँच जाता है।
Blocked tests का risk ज़्यादा चुपचाप होता है: वे न pass हैं न fail, और उनके पीछे के features untested हैं। 40 passed और 30 blocked tests वाला run quality के बारे में उससे कहीं कम बताता है जितना उसका pass count दिखाता है।
Test fail क्यों होता है: product, test या environment
Actual और expected result के फ़र्क़ के तीन संभावित स्रोत हैं: product defect (software वैसा व्यवहार नहीं करता जैसा test basis कहता है), test की समस्या (test case, script, expected result या execution गलत है), या environment या test data की समस्या (build, services, configuration या data वैसे नहीं हैं जैसा test मानकर चलता है)। आख़िरी दो false positives हैं, जैसा error, defect और failure वाले lesson में आया था।
सस्ते explanations पहले इसी क्रम में खारिज करें। चारों सवाल पार करने वाला failure product defect के रूप में report होता है; जो पहले तीन पार करे पर दोहराया न जाए, वह भी intermittent के रूप में चिह्नित करके report होता है।
- क्या test उस step तक पहुँचा जो उसका expected result check करता है? नहीं पहुँचा तो वह blocked है, failed नहीं।
- क्या build, services, configuration और data वैसे थे जैसे test को चाहिए? पुराना build या पहले से इस्तेमाल हुआ single-use coupon ऐसे tests fail कर देता है जिनमें product pass होता। अगला lesson, environment और test data की समस्याओं वाला, इनके संकेत और इन्हें record करने का तरीका बताता है।
- क्या steps और expected result मौजूदा requirement के हिसाब से सही हैं, और क्या उन्हें follow किया गया? Approved बदलाव से नाम "Pay now" हो जाने के बाद भी "Checkout" expect करने वाला test गलत है, product नहीं।
- पिछले lesson की तरह reproduce करने पर क्या failure फिर होता है? नहीं होता तो उसे failed दर्ज करें, passed कभी नहीं, और evidence और rate के साथ intermittent के रूप में report करें।
उत्तर: नहीं
परिणाम: BlockedBlocker के ticket ID और owner के साथ Blocked दर्ज करें; blocker हटने पर इसे चलाएँ।सावधानीउत्तर: हाँ
प्रश्न 2: क्या build, services, configuration और data वैसे थे जैसा test मानता है?उत्तर: नहीं
परिणाम: Environment या test data की समस्याProduct defect नहीं। Environment: environment ticket से Blocked दर्ज करें, owner को बताएँ, fix के बाद दोबारा चलाएँ। Test data: data ठीक करें या दोबारा बनाएँ, result पर कारण लिखें, rerun को नए execution के रूप में दर्ज करें।उत्तर: हाँ
प्रश्न 3: क्या steps और expected result मौजूदा requirement के हिसाब से सही हैं, और क्या उन्हें follow किया गया?उत्तर: नहीं
परिणाम: Test की समस्याTest basis के हिसाब से test case या script ठीक करें, कारण लिखें और दोबारा चलाएँ।उत्तर: हाँ
प्रश्न 4: Test दोहराने पर क्या failure फिर होता है?उत्तर: नहीं
परिणाम: Intermittent failureEvidence और rate के साथ Failed दर्ज करें, intermittent बताकर report करें और इसे कभी passed न करें।सावधानीउत्तर: हाँ
परिणाम: Product defectFailed दर्ज करें, defect को evidence के साथ report करें और test से link करें।फ़ेल
यह जाँच का क्रम है, सख़्त नियम नहीं: जब evidence साफ़ तौर पर एक कारण दिखाए, वहीं से शुरू करें।
Blocked tests: जब test अपने check तक न पहुँचे
Blocked test ने उस चीज़ के बारे में कोई result नहीं दिया जिसे वह check करता है। आम blockers हैं: पिछले step में या उस feature में defect जिस पर test निर्भर है, बंद service, missing data या permissions, और ऐसा feature जो अभी deploy नहीं हुआ।
नियम: failure उस test का है जिसका अपना check fail हुआ, और हर दूसरा test जिसे वह step चाहिए था, उसी से blocked है। अगर login fail होता है, तो login test fail है और checkout के tests blocked हैं। सबको failed दर्ज करने से एक defect कई failures जैसा दिखता है और यह छिप जाता है कि वे features कभी check ही नहीं हुए। कुछ टीमें इन्हें defect के link के साथ failed दर्ज करती हैं; एक convention तय करें।
- पहले कोई दूसरा valid रास्ता खोजें, जैसे API से order बनाना, और कोई भी workaround result में लिखें।
- Blocker हटने पर blocked tests पहली बार चलते हैं। वे retest नहीं हैं, और ऐसे defects दिखा सकते हैं जिन्हें blocker छिपा रहा था: error, defect और failure वाले lesson का defect masking।
हर result के लिए क्या दर्ज करें
सिर्फ़ "Failed" लिखना किसी और को आपका काम दोहराने पर मजबूर करता है।
- हर result: test case ID, run, build, environment, tester और तारीख़।
- Failed: fail हुआ step, expected के बगल में actual, evidence (screenshot, log, response), कारण की category और defect ID।
- Blocked: क्या रोक रहा है और किस step पर, blocker का ticket ID और owner, और कब से।
- Test की समस्या: क्या गलत था, कैसे ठीक और review किया गया, और ठीक करने के बाद का result, साथ में requirement के किसी भी बदलाव का link।
- Retest: defect ID, fix वाला build, result और उसका evidence, नए execution के रूप में, ताकि मूल failure history में बना रहे।
Worked example: एक checkout run की triage
Staging में build 4.12.0 पर checkout के छह tests चलते हैं, और पहली बार में उनमें से पाँच pass नहीं होते। Log triage के बाद के results दिखाता है।
- TC-206 cart में bundle जोड़ना check करता है, इसलिए HTTP 500 error (server की ओर की error) उसका अपना failure है: Failed, defect DEF-480। TC-203 bundle discount check करता है और step 2 पर रुकता है: DEF-480 से Blocked, दूसरा defect नहीं।
- TC-202 ठीक environment में अपने check तक पहुँचा, उसका expected total requirement के मुताबिक़ है और failure दोबारा हुआ: Failed, product defect DEF-482।
- TC-204 payment पर रुका: third-party payment sandbox ने हर card के लिए 503 (service unavailable) लौटाया और उसका health check भी fail हुआ। Environment ticket ENV-77 से Blocked, कोई product defect नहीं।
- TC-205 ने "Checkout" expect किया, जबकि एक approved design change ने button का नाम "Pay now" कर दिया था: test की समस्या। Test case को उस change के हिसाब से ठीक किया गया और टीम के सामान्य review के बाद वह TC-205 v2 बना; फिर tester ने उसे change के link के साथ दोबारा चलाया: Passed।
- नतीजा: 2 passed, 2 failed, 2 blocked, और पाँच की जगह दो defect reports।
Run: checkout regression, cycle 3 Build: 4.12.0 Environment: staging
Test Result Step Note Link
TC-201 Passed - - -
TC-202 Failed 4 10% coupon: total 115.00, expected 103.50 DEF-482
TC-203 Blocked 2 Cannot add bundle to cart (HTTP 500) DEF-480
TC-204 Blocked 5 Payment sandbox returns 503 for every card ENV-77
TC-205 Passed 3 Re-run after test fix: label is now "Pay now" TC-205 v2
TC-206 Failed 2 Adding a bundle to the cart returns HTTP 500 DEF-480Fix के बाद retesting
Confirmation testing (retesting) बताए गए fix को जाँचती है (confirmation और regression testing वाला lesson देखें)। जब DEF-480 build 4.12.1 में fix होता है, तो TC-206 का retest होता है और TC-203 पहली बार चलता है। अगर TC-203 तब discount पर fail होता है, तो यह नया defect है जिसे blocker छिपा रहा था, DEF-480 का reopen नहीं।
- पक्का करें कि test हो रहे build में fix है (defect या release notes देखें); पुराने build पर retest कुछ साबित नहीं करता।
- मूल steps, data और conditions दोहराएँ, साथ में कुछ आसपास के variations जैसे दूसरे bundle types, और retest को नए execution के रूप में दर्ज करें।
- Pass हो तो defect को अपने lifecycle के अनुसार update करें; वैसे ही fail हो तो नए build और evidence के साथ reopen करें; अलग तरह से fail हो तो नया defect report करें और दोनों को link करें।
- फिर वे tests चलाएँ जिन्हें defect रोक रहा था, और उस change के लिए चुने गए regression tests।
आम गलतियाँ
- हर failed test को पहले environment, data और expected result जाँचे बिना product defect के रूप में report करना।
- बिना evidence के "environment" या "flakiness" को दोष देना, या दूसरी बार संयोग से pass होने पर test को passed दर्ज करना।
- ऐसे tests को failed दर्ज करना जो अपने check तक पहुँचे ही नहीं, जिससे एक defect कई failures जैसा दिखता है।
- ऐसे build पर retest करना जिसमें fix नहीं है, या मूल failed result को overwrite करना।
- Expected result को product जो भी करे उसके बराबर कर देना, requirement देखे बिना।
QA का नज़रिया
Failure के तुरंत बाद triage करें, जब environment और data अभी वैसे ही हों, और सस्ते checks से शुरू करें: build, services, और मौजूदा requirement के सामने test case। पक्का न हो तो evidence लेकर developer से पूछें। Category बताती है कि किससे बात करनी है: developer, test author, environment owner, या requirement अस्पष्ट हो तो product owner।
Blocked tests को daily status में blocker के हिसाब से report करें: "checkout के 12 tests मंगलवार से DEF-480 से blocked हैं" जैसा वाक्य test lead को एक fix के लिए ज़ोर देने देता है। अगर blocked tests से exit criteria ख़तरे में हों तो यह जल्दी बताएँ, ताकि टीम सोच-समझकर चुन सके: blocker ठीक करना, plan बदलना या risk स्वीकार करना।
अभ्यास
Booking app के run से पाँच results की triage करें
आप build 2.7.0 पर एक clinic booking app का cycle 2 चला रहे हैं, और पाँच tests pass नहीं हुए। हर note को product defect, test की समस्या, environment या data की समस्या, blocked test या intermittent failure में classify करें, और दर्ज करने वाला result और अगला action बताएँ। फिर booking defect fix होने पर retest plan करें।
Clinic booking app, build 2.7.0, test environment, cycle 2
TC-31 Patient registration: welcome e-mail नहीं आया। Mail service का status
page दिखाता है कि test mail server 09:00 से बंद है।
TC-32 Booking cancel करना: शुरू नहीं हो पाता; step 1 (slot book करना) हर
खाली slot के लिए "Slot unavailable" दिखाता है।
TC-33 Slot book करना: हर खाली slot के लिए "Slot unavailable"। 2 doctors और
नए users के साथ 3 बार दोहराया। Server log: NullPointerException।
TC-34 Doctor list: expected 8 doctors, दिखे 9। Clinic ने 9वें doctor को
पिछले हफ़्ते जोड़ा, change request CR-19 में approved।
TC-35 Booking history: patient B से login करने पर patient A की एक booking
दिखी। एक बार हुआ; 5 कोशिशों में दोबारा नहीं हुआ।मॉडल उत्तर दिखाएँ
TC-31: environment की समस्या, कोई product defect नहीं। बंद mail server registration के बारे में कुछ नहीं बताता: test को environment ticket से blocked दर्ज करें, environment owner को बताएँ और बाद में दोबारा चलाएँ।
TC-33: product defect। अपने check तक पहुँचा, server log environment के बंद होने की जगह application का exception दिखाता है, उसका expected result requirement के मुताबिक़ है और दूसरे doctors और users के साथ दोहराया जाता है। Failed दर्ज करें और report करें, मान लें DEF-501, steps, message, log line और build के साथ।
TC-32: DEF-501 से Blocked, क्योंकि booking, जो TC-33 का check है, fail होती है। दूसरी report सिर्फ़ DEF-501 की duplicate होगी।
TC-34: test की समस्या। Product CR-19 के मुताबिक़ है: test case को 9 doctors पर update करें, CR-19 link करें और बदलाव को टीम के सामान्य review से गुज़ारें, फिर दोबारा चलाएँ और ठीक किया गया result दर्ज करें।
TC-35: intermittent, पर छोड़ने लायक नहीं: दूसरे patient की booking दिखना एक बार भी हो तो privacy की समस्या है। Screenshot, समय, दोनों accounts और उन पाँच कोशिशों के साथ Failed दर्ज करें जिनमें यह दोहराया नहीं गया, इसे intermittent के रूप में report करें और developer को अभी बताएँ।
Retest: DEF-501 fix होने पर पक्का करें कि build में fix है, TC-33 को उन्हीं और दूसरे doctors के साथ नए execution के रूप में retest करें और DEF-501 update करें। फिर TC-32 पहली बार चलाएँ, और चुने गए regression tests भी।
अक्सर पूछे जाने वाले सवाल
Blocked test का blocker कौन हटाता है, और test कब तक blocked रह सकता है?
Blocker का owner उसे हटाता है: defect हो तो developer, service बंद हो तो environment owner, permission न हो तो access देने वाला व्यक्ति। आपका काम है blocker का ticket ID, owner और कब से, यह दर्ज करना, कोई दूसरा valid रास्ता खोजना, और blocked tests को daily status में blocker के हिसाब से report करना। कोई तय सीमा नहीं है: जब blocked tests से exit criteria ख़तरे में हों, तो test lead को बताएँ, ताकि टीम blocker ठीक करना, plan बदलना या risk स्वीकार करना चुन सके।
अगर तय न कर पाऊँ कि product defect है या test की समस्या, तो?
Test basis पर लौटें। अगर requirement, acceptance criteria या कोई approved change बताता है कि क्या होना चाहिए, तो उससे तुलना करें। अगर test basis चुप है या उसमें विरोधाभास है, तो product owner या business analyst से पूछें और कुछ भी report करने से पहले जवाब test case में दर्ज करें।
क्या failed test को pass होने तक दोबारा चला सकता हूँ?
नहीं। दूसरी कोशिश में pass होना पहले failure को रद्द नहीं करता। दोनों results दर्ज करें, test को intermittent मानें और जाँच करें; product में intermittent failure, जैसे timing की समस्या, फिर भी defect है।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISTQB Glossaryटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
- ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesटेस्ट प्रक्रिया मॉडल: संगठनात्मक, टेस्ट प्रबंधन और dynamic टेस्ट प्रक्रियाएँ, उनकी गतिविधियों और परिणामों के साथ।
Mutqan tools से अभ्यास करें
दो टेक्स्ट की लाइन-दर-लाइन या शब्द-दर-शब्द तुलना करें और अंतर हाइलाइट करें।
दो JSON डॉक्यूमेंट की सिमैंटिक तुलना करें और जोड़ी गई, हटाई गई तथा बदली गई वैल्यू हाइलाइट करें।
एक साथ कई API health endpoint जाँचें और स्टेटस, latency तथा pass/fail सारांश पाएँ।
दो API रिस्पॉन्स (जैसे staging बनाम production) की तुलना करें और हर संरचनात्मक तथा वैल्यू का अंतर देखें।
बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।