बग हंटिंग और रिस्क-आधारित एक्सप्लोरेशन

Mutqan Soft QA टीम द्वारा · अपडेट 6 अक्टूबर 2026 · 21 मिनट · मध्यम

Bug hunting ऐसी exploratory testing है जिसका एक साफ़ लक्ष्य होता है: सीमित समय में सबसे अहम failures ढूँढना। पूरे product को बराबर explore करने के बजाय आप उन हिस्सों पर निशाना साधते हैं जहाँ failure की संभावना सबसे ज़्यादा है और नुक़सान सबसे बड़ा होगा — यही risk-based exploration है — और heuristics व tours को अपनी tactics की तरह इस्तेमाल करते हैं। उदाहरण: एक clinic booking app family accounts रिलीज़ करने वाला है; उससे पहले एक tester 90 मिनट का session इस कोशिश में लगाता है कि shared wallet से दो बार पैसे कट जाएँ, क्योंकि इस failure से परिवारों का पैसा जाएगा और clinic उनका भरोसा खो देगा।

Bug bash ऐसा bug hunt है जिसे कई लोग एक साथ करते हैं: एक time-boxed event में testers, developers, product owners, support staff और designers एक ही build को explore करते हैं, जो मिलता है उसे एक जगह log करते हैं, और बाद में टीम findings का triage करके नतीजे report करती है। Bug hunting और bug bash industry के शब्द हैं जिन्हें ISTQB Foundation syllabus परिभाषित नहीं करता; उसकी भाषा में दोनों exploratory testing हैं, यानी experience-based test technique, जिसे risk दिशा देता है।

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

Testing का समय हमेशा सीमित होता है, और seven testing principles में से दो बताते हैं कि निशाना क्यों ज़रूरी है: exhaustive testing असंभव है, और defects कुछ जगहों पर इकट्ठा होते हैं। पूरे product में भटकने वाला exploration अपना ज़्यादातर समय वहाँ लगाता है जहाँ कुछ गलत नहीं; risk पर निशाना साधने वाला exploration उसे वहाँ लगाता है जहाँ failure महँगा पड़ेगा — पैसा, permissions, और ऐसा data जो वापस नहीं आ सकता।

Bug bash कम समय में कई अलग-अलग नज़रें जोड़ता है: support agent वह आज़माता है जिसकी customers शिकायत करते हैं, designer layout की समस्याएँ पकड़ता है, developer वे failure modes जाँचता है जो वह code से जानता है। Tester के लिए इसे आयोजित करना quality के काम को lead करने का साफ़ मौका है — लेकिन इसकी value event से नहीं, बल्कि उस तैयारी से आती है जो उसे निशाना देती है और उस report से जो raw findings को फ़ैसलों में बदलती है।

Risk-based exploration: explore करने से पहले निशाना साधें

Risk-based exploration का मतलब है risk-based testing को exploratory काम पर लागू करना: risk level तय करता है कि आप पहले कहाँ explore करेंगे, कितनी गहराई से और कितने लोगों के साथ। Release के product risks से शुरू करें, जिन्हें risk-based testing की तरह likelihood और impact से आँका गया हो। एक feature के लिए पूरे risk register की ज़रूरत नहीं; product owner और एक developer के साथ तय की गई छोटी, क्रम वाली सूची काफ़ी है।

फिर हर high risk को session-based test management वाले template से charters में बदलें, और level को गहराई तय करने दें। Very high risk को कई sessions, दूसरा tester या bug bash मिल सकता है; high risk को कम से कम एक पूरा session; medium risk को समय हो तो एक छोटा session; low risk को छोटा tour या कुछ नहीं — बशर्ते यह फ़ैसला दर्ज हो। Likelihood आम तौर पर इन संकेतों के साथ बढ़ती है:

नया या दोबारा लिखा गया code, और वह code जिसे इस release में कई लोगों ने बदला।
जटिल rules: पैसा, dates और time zones, permissions, ऐसे flows जो कई क्रमों में किए जा सकते हैं।
Integrations: payment providers, SMS और email, दूसरी teams के APIs, और उनके धीमे या fail होने पर क्या होता है।
Defect clusters: ऐसे components जिनमें पिछली releases में बहुत defects, reopened defects या production incidents रहे।
Customer संकेत: support tickets, app store reviews और analytics जो दिखाएँ कि users कहाँ अटकते हैं।
Gaps: कमज़ोर automated coverage या अस्पष्ट acceptance criteria।

आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर

Heuristics और tours: hunt की tactics

Exploratory testing guide heuristics (अंगूठा-नियम जो सुझाते हैं कि आगे क्या आज़माएँ) और tours (product में थीम वाले रास्ते) समझाती है। Hunt में आप इन्हें उस risk के हिसाब से चुनते हैं जिस पर निशाना है, ताकि tactic happy path दोहराने के बजाय उस failure पर हमला करे जिसका डर है; error guessing वाली typical errors की सूची भी पास रखें। एक छोटा recap, आम risks के साथ:

गलत पैसा — inputs बदलें: discounts, rounding, शून्य और maximum amounts, ऐसे totals जो बराबर नहीं बँटते। नाम के बावजूद Money tour यहाँ की tactic नहीं है: वह उन features पर जाता है जो product बेचते हैं, यानी जो demos में दिखाए जाते हैं।
खोया या असंगत data — FedEx tour: एक record को हर उस screen, email, export और API तक follow करें जो उसे छूता है।
State conflicts — states और sequences बदलें: दो tabs, दो devices, back और forward, दो बार submit; Obsessive-compulsive tour एक ही action तब तक दोहराता है जब तक कुछ टूट न जाए।
Fail होती dependencies — Saboteur tour और रुकावटें: धीमा या कटा network, timeouts, sandbox में decline हुआ payment।
गलत access — कोई persona अपनाएँ: हटाया गया member, guest, या ऐसा user जिसका session expire हो गया।
Display और localisation — Supermodel tour: Arabic और English, right-to-left layout, लंबे नाम, zoom।
उपेक्षित कोने — Back-alley tour: settings, error pages और वे limits जिन्हें कोई demo नहीं करता।

आज़माएँ: एज केस जनरेटर आज़माएँ: स्पेशल कैरेक्टर डेटासेट जनरेटर

Bug bash आयोजित करना

Bug bash अलग-अलग जानकारी वाले लोगों को एक ही build पर छोटे, तीव्र hunt के लिए इकट्ठा करता है। इसकी value तैयारी पर टिकी है: तैयारी के बिना दर्जन भर लोग पहला आधा घंटा login करने में बिताते हैं, एक ही happy path टेस्ट करते हैं और पहले से known bugs report करते हैं। आम तौर पर एक tester facilitator बनता है; product owner लक्ष्य पर सहमति देता है, और development lead build freeze करने और fixes के लिए समय रखने पर।

इसे इतनी जल्दी रखें कि जो मिले उसे ठीक किया जा सके। Release से एक दिन पहले के bug bash के बाद आम तौर पर समस्याओं की सूची बनाने का ही समय बचता है, उन्हें ठीक करने का नहीं।

Bug bash के तीन चरण: risks का क्रम तय करें और build, data व charters तैयार करें; एक time box में pairs में hunt करें; फिर triage करें, coverage, defects, gaps और बचा risk report करें, और follow up करें। वैचारिक मॉडल

पहले: निशाना और तैयारी
Event से कुछ दिन पहले
1. 1Risks का क्रम तय करेंLikelihood × impact; product owner के साथ goal और scope तय करें
2. 2Build और data तैयार करेंFrozen build, test accounts, sandbox cards, known-issues सूची
3. 3Pairs को charters देंसबसे ऊँचे risks पहले; जहाँ हो सके, tester के साथ non-tester
उस दिन: hunt
एक time box, जैसे 60 से 90 मिनट
1. 4Kick-offGoal, scope, rules और report करने का तरीका
2. 5Pairs में huntCharter पर निशाना साधते heuristics और tours; हर finding shared sheet में
  दोहराता है: Facilitator सवालों के जवाब देता है, duplicates और blockers पकड़ता है
3. 6Wrap-upसबसे अहम finding; जहाँ कोई नहीं पहुँचा
बाद में: फ़ैसला और follow-up
उसी दिन या अगली सुबह
1. 7Findings का triageDuplicates हटाएँ, reproduce करें, severity और priority तय करें, defects file करें
  शाखा: Duplicates, known issues और non-defects: कारण के साथ बंद
2. 8नतीजे report करेंCoverage, defects, gaps, सवाल और अब का risk
3. 9Follow upFixes, confirmation testing, regression cases, नए charters

उदाहरण वाला क्रम: समय और roles टीम के हिसाब से बदलते हैं; तैयारी और triage event से ज़्यादा मायने रखते हैं।

लक्ष्य और scope — एक वाक्य कि bash किसलिए है, risk के क्रम में scope वाले हिस्से, क्या scope से बाहर है, और known issues की सूची ताकि कोई उन्हें दोबारा report न करे।
Environment और data — तय test environment में stable build, हर charter के लिए ज़रूरी roles वाले test accounts, synthetic data और sandbox payment cards। असली customer data कभी नहीं।
Charters और pairs — हर pair को एक charter, सबसे ऊँचे risks पहले; जहाँ हो सके, tester को non-tester के साथ जोड़ें ताकि अलग-अलग जानकारी मिले।
Reporting — एक shared sheet, या tracker label, तय fields के साथ: reporter, charter, title, steps, expected और actual result, evidence, device और build। Raw findings पहले वहाँ जाती हैं; triage तय करता है कि क्या defect report बनेगा।
उस दिन — goal, scope, rules और reporting पर छोटा kick-off; 60 से 90 मिनट जैसा time box; facilitator जो सवालों के जवाब दे और duplicates व blockers पर नज़र रखे; और wrap-up round: सबसे अहम finding और जहाँ कोई नहीं पहुँचा।
बाद में — उसी दिन या अगली सुबह triage: duplicates हटाएँ, reproduce करें, severity और priority तय करें, defects को bash से link करके file करें, फिर नतीजे report करें।

आज़माएँ: फ़ेक यूज़र जनरेटर आज़माएँ: टेस्ट सिनेरियो जनरेटर

Worked example: family accounts की release से पहले bug bash

एक काल्पनिक clinic booking app family accounts जोड़ रहा है: account holder 5 तक members जोड़ता है, उनके appointments book करता है और shared wallet से pay करता है; appointment से 24 घंटे से ज़्यादा पहले cancel करने पर पैसा wallet में वापस आता है। Release से दो हफ़्ते पहले QA lead product owner और एक developer के साथ risks का क्रम तय करता है और 12 लोगों के लिए, छह pairs में, 90 मिनट का bug bash करता है।

दो pairs wallet लेते हैं, क्योंकि double charge या गलत refund सबसे ऊँचा risk है। बाकी pairs लेते हैं: दो members का एक साथ आख़िरी खाली slot book करना, किसी member को हटाने के बाद privacy, 24 घंटे वाला cancellation rule, और Arabic व English screens। अगली सुबह QA lead और development lead 31 raw findings का triage करते हैं, और QA lead यह summary भेजता है (VH very high, H high, M medium):

Critical: timeout के बाद Pay दोबारा दबाने पर wallet से दो बार पैसे कटते हैं।
Critical: हटाया गया member saved link से परिवार के आने वाले appointments अब भी खोल सकता है।
सवाल: appointment से ठीक 24 घंटे पहले cancel करने पर refund मिलता है, जबकि rule कहता है "24 घंटे से ज़्यादा"। इनमें से कौन-सा व्यवहार चाहिए?

Bug bash: family accounts    build 4.6.0 (staging)    90 min, 12 people, 6 pairs

Risk (level)                    Pairs  Raw  New defects  Highest severity
Wallet charge and refund (VH)     2     9        4       Critical
Last slot, two members (VH)       1     5        2       Major
Removed member privacy (VH)       1     4        1       Critical
24 h cancellation rule (H)        1     6        2       Major
Arabic and English screens (M)    1     7        3       Minor

Triage:      31 raw -> 12 new defects, 9 duplicates, 4 known issues,
             3 questions, 3 not a defect
Not reached: refund to an expired card (no sandbox card for it)
Risk now:    wallet and privacy stay VH until the Critical fixes pass confirmation
             testing; refunds to expired cards are still untested;
             slot, cancellation and screens lower once their fixes are confirmed
Follow-up:   6 regression cases (2 automated at API level),
             2 charters for the next sprint

नतीजों की reporting

Bug hunt या bug bash का नतीजा किसी फ़ैसले के लिए जानकारी है, score नहीं। काम की report चार सवालों का जवाब देती है: हमने क्या cover किया, क्या पाया, कहाँ नहीं पहुँचे, और अब risk कितना है? इसे product owner और development lead को भेजें और release की test progress reporting में जोड़ें; release का फ़ैसला उन्हीं का रहता है।

Numbers के साथ सावधान रहें। बारह defects अपने आप में कम बताते हैं, और किसी हिस्से में कम defects का मतलब हो सकता है कि वह मज़बूत है या किसी ने ठीक से देखा ही नहीं। पहला testing principle कहता है: testing defects की मौजूदगी दिखाती है, उनकी गैरमौजूदगी नहीं।

Coverage — कौन-से risks और charters explore हुए, कितने लोगों ने और कितनी देर।
Findings — severity के हिसाब से नए defects उनकी IDs के साथ; duplicates, known issues और non-defects अलग गिने हुए, जिससे पता चले कि triage हुआ।
Gaps — कहाँ नहीं पहुँचे और क्यों: blocked environment, कम data, कम समय।
सवाल — owner वाले खुले सवाल, जैसे hunt के दौरान मिले अस्पष्ट rules।
अब का risk — हर risk के लिए: घटा, वैसा ही रहा या अब भी अज्ञात है, और क्यों।
Follow-up — fixes और confirmation testing, नए regression cases और उनमें से किन्हें automate करना है, नए charters, और अगले bash में क्या बदलना है।

आम गलतियाँ

सबसे जोखिम वाले हिस्सों पर पहले निशाना साधने के बजाय बराबर, या जहाँ पहुँचना आसान हो वहाँ explore करना।
बिना तैयारी bug bash करना: unstable build, न accounts न data, न known issues की सूची। समय setup और known bugs दोबारा report करने में चला जाता है।
Charters या areas न बाँटना, जिससे सब एक ही happy path टेस्ट करते हैं।
हर raw finding सीधे tracker में file करना, जिससे developers के पास duplicates और अस्पष्ट reports रह जाती हैं।
मिले bugs की गिनती पर इनाम देना, जो trivial और duplicate reports को बढ़ावा देता है। अगर कुछ देना ही है, तो सबसे अहम finding को दें।
सिर्फ़ bug count report करना, बिना coverage, gaps और बचे risk के, या कम bugs को quality का सबूत मान लेना।

QA का नज़रिया

असली टीम में bug hunting planned testing का हिस्सा है, उसका विकल्प नहीं। इसके आम मौके हैं: बड़ी release, बड़ा refactoring, नए market या भाषा में launch, या ऐसा feature जो "done" है पर टीम को उस पर अब भी पूरा भरोसा नहीं। Product owner के साथ risks तय करें, support से पूछें कि customers किस बात की शिकायत करते हैं, developers से पूछें कि किन हिस्सों पर उन्हें सबसे कम भरोसा है, और शुरू में ही एक सवाल पूछें: जो मिलेगा उसे कौन और कब ठीक करेगा?

सारे सबूत एक साथ रखें: participants, build, charters, shared sheet, triage के फ़ैसले और report। हर defect को bash से link करें और हर नए regression case को उस defect से जिससे वह निकला। कुछ bashes के बाद तुलना करें कि defects कहाँ मिले और टीम ने उन्हें कहाँ अपेक्षित किया था; यह तुलना अगली risk ranking सुधारती है।

अभ्यास

Group-order feature के लिए bug bash की योजना बनाएँ

आपका काम

एक काल्पनिक food delivery app group orders जोड़ रहा है और दो हफ़्ते में release करेगा। आपके पास 90 मिनट के bug bash के लिए आठ लोग हैं: दो testers, तीन developers, एक product owner, एक support agent और एक designer। नीचे दी गई सामग्री से bash की योजना बनाएँ और बाद में भेजी जाने वाली report की रूपरेखा लिखें।

सामग्री

Feature: group order (staging पर build 3.2.0)
- Host एक group cart बनाता है और एक link share करता है, जो 60 मिनट valid है।
- 10 तक guests link से जुड़ते हैं और अपने items जोड़ते हैं।
- Host cart lock करता है और सबके लिए card या wallet से pay करता है।
- हर guest app में अपना हिस्सा host को वापस pay कर सकता है।
- Delivery fee और कोई भी discount सभी लोगों में बराबर बाँटे जाते हैं।
Known issue: GRP-12  बिना profile photo वाले guests का avatar नहीं दिखता।

चरण

कम से कम पाँच product risks लिखें और likelihood व impact के हिसाब से उनका क्रम तय करें।
चारों pairs में से हर एक के लिए एक charter लिखें, और बताएँ कि हर pair कौन-सा heuristic या tour इस्तेमाल करे।
Bash से पहले क्या तैयार होना चाहिए और reporting sheet के fields क्या होंगे, यह लिखें।
Outcome report के sections की रूपरेखा बनाएँ।

मॉडल उत्तर दिखाएँ

मॉडल उत्तर

Risks, सबसे ऊँचे पहले: lock, retry या card और wallet के बीच switch करने के बाद host से गलत या दोहरा charge (very high); fee और discount बाँटते समय गलत हिस्से, rounding समेत (very high); cart lock होने या link expire होने के बाद guests का जुड़ना या items बदलना (high); 10 से ज़्यादा guests, या दो guests का एक साथ आख़िरी जगह लेना (high); किसी guest को host की payment details या दूसरे guests के phone numbers दिखना (high); Arabic या लंबे item names से shared cart का बिगड़ना (medium)। दोनों payment risks सबसे ऊपर हैं क्योंकि failure से असली पैसा जाता है (high impact) और retries व दो payment तरीकों वाला payment code नया और जटिल है (high likelihood); privacy risk का impact high है पर likelihood कम, और display risk में इसका उल्टा। Missing avatar (GRP-12) known issue है और उसका risk low है।

Charters: Pair 1, एक tester और एक developer: lock के बाद payment को card, wallet, retries और धीमे network के साथ explore करें (Saboteur tour, रुकावटें) ताकि गलत या दोहरे charges मिलें। Pair 2, एक tester और product owner: fees, discounts और बराबर न बँटने वाले totals के साथ share-back explore करें (inputs बदलना) ताकि बँटवारे और rounding की गलतियाँ मिलें। Pair 3, एक developer और support agent: cart lock, 10-guest limit और 60 मिनट की expiry के आसपास link और cart को कई tabs और devices में explore करें (states और sequences बदलना) ताकि state conflicts मिलें। Pair 4, एक developer और designer: Arabic और English में guest बनकर cart explore करें (Supermodel tour, guest persona) ताकि display और privacy की समस्याएँ मिलें। Facilitator आप हैं। सिर्फ़ दो testers होने से pair 3 और pair 4 में कोई tester नहीं है, इसलिए उन्हें सबसे ठोस charters दें और सबसे पहले उन पर नज़र डालें।

Bash से पहले तैयार: staging पर frozen build; हर pair के लिए test accounts, जिनमें pair 3 के लिए 12 ताकि वह सभी 10 guest जगहें भर सके और 11वाँ guest आज़मा सके; sandbox cards और wallet balances; GRP-12 वाली known-issues सूची; charters; और shared sheet जिसके fields हों: reporter, charter, title, steps, expected result, actual result, evidence, device, build। 10 मिनट का kick-off, 70 मिनट hunting और 10 मिनट का wrap-up रखें, फिर अगली सुबह development lead और product owner के साथ triage करें।

Report की रूपरेखा: goal, build और participants; हर risk और charter की coverage; severity के हिसाब से नए defects IDs के साथ, और duplicates, known issues व non-defects; कहाँ नहीं पहुँचे और क्यों; owners के साथ खुले सवाल; अब हर risk का level; follow-up actions: fixes, confirmation testing, regression cases और किन्हें automate करना है, और नए charters।

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

Exploratory session, bug hunting और bug bash में क्या फ़र्क है?

Exploratory session एक tester या pair का एक charter पर time box में किया गया काम है। Bug hunting ऐसा exploration है जिसका मुख्य लक्ष्य risky हिस्सों में अहम failures ढूँढना है, एक session में या कई में। Bug bash ऐसा bug hunt है जिसे कई लोग एक ही समय पर एक event के रूप में करते हैं, और आम तौर पर इसमें ऐसे लोग भी होते हैं जो tester नहीं हैं।

Bug bash में किसे शामिल होना चाहिए?

वे लोग जो product को अलग-अलग तरह से देखते हैं: testers, इस और पड़ोसी teams के developers, product owner, support staff और designers। जहाँ हो सके, हर non-tester को एक tester के साथ जोड़ें। Group इतना छोटा रखें कि एक facilitator shared sheet पर नज़र रख सके, या बड़े group को areas में बाँटें, हर area का अपना facilitator हो।

क्या bug bash planned testing की जगह ले सकता है?

नहीं। यह कम समय के लिए कई नज़रिए जोड़कर planned और automated testing का पूरक बनता है। यह requirements का systematic coverage नहीं देता, और इसकी findings को अब भी triage, fixes, confirmation testing और regression cases चाहिए।

कैसे पता करें कि bug bash फ़ायदेमंद रहा?

देखें कि उसने क्या बदला: release से पहले मिले अहम defects, ऐसे risks जिन्हें अब ज़्यादा भरोसे से आँका जा सकता है, requirements के सवाल जिनके जवाब मिले, और जोड़े गए charters व regression cases। उसकी findings की तुलना पहले की testing से करें। Reports की raw गिनती अकेले बहुत कम बताती है।

संदर्भ

ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
Explore It! Reduce Risk and Increase Confidence with Exploratory Testing (Elisabeth Hendrickson)The Pragmatic Bookshelf · 2013एक्सप्लोरेटरी टेस्टिंग का अनुशासन: चार्टर, इनपुट और स्टेट बदलने के ह्यूरिस्टिक, और यह स्क्रिप्टेड टेस्ट का पूरक कैसे है।
Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design (James A. Whittaker)Addison-Wesley (Pearson) · 2009वह किताब जिसने exploratory testing को "tours" के इर्द-गिर्द व्यवस्थित किया — फ़ीचर, डेटा और यूज़र यात्राओं को खोजने के संरचित तरीके।
Session-Based Test Management (Jonathan Bach)Satisfice, Inc. · 2000session-based test management का मूल विवरण: चार्टर वाले, समय-सीमित exploratory सेशन, session sheet और debrief।

बग हंटिंग और रिस्क-आधारित एक्सप्लोरेशन

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

Risk-based exploration: explore करने से पहले निशाना साधें

Heuristics और tours: hunt की tactics

Bug bash आयोजित करना

Worked example: family accounts की release से पहले bug bash

नतीजों की reporting

आम गलतियाँ

QA का नज़रिया

अभ्यास

Group-order feature के लिए bug bash की योजना बनाएँ

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

संदर्भ

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

रिस्क-बेस्ड टेस्ट जनरेटर

टेस्ट सिनेरियो जनरेटर

एज केस जनरेटर

स्पेशल कैरेक्टर डेटासेट जनरेटर

फ़ेक यूज़र जनरेटर

और गहराई से

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

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

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

Risk-based exploration: explore करने से पहले निशाना साधें

Heuristics और tours: hunt की tactics

Bug bash आयोजित करना

Worked example: family accounts की release से पहले bug bash

नतीजों की reporting

आम गलतियाँ

QA का नज़रिया

अभ्यास

Group-order feature के लिए bug bash की योजना बनाएँ

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

संदर्भ

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

और गहराई से

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

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

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics