सेशन-बेस्ड टेस्ट मैनेजमेंट (SBTM)

SBTM कौन-सी समस्या हल करता है

बिना मैनेज की गई exploratory testing को प्लान करना और रिपोर्ट करना मुश्किल होता है। "checkout का कितना हिस्सा टेस्ट हो चुका?" पूछने वाले मैनेजर को "काफ़ी" जैसा जवाब मिलता है, और जिस टेस्टर ने सुबह टूटे एनवायरनमेंट से जूझते बिताई वह उतना ही उत्पादक दिखता है जितना सुबह टेस्टिंग करने वाला। SBTM exploration की आज़ादी बनाए रखता है पर उसके चारों ओर काम की एक इकाई रखता है — session — ताकि प्रयास को प्लान, दर्ज और तुलना किया जा सके।

ISTQB Foundation Level सिलेबस (CTFL v4.0) यही विचार सामान्य शब्दों में बताता है: तय time-box में की गई exploratory testing, जिसे टेस्ट के उद्देश्यों वाला test charter गाइड करता है। SBTM, जो 2000 में प्रकाशित हुआ, इसी विचार पर बना एक पुराना और ज़्यादा विस्तृत तरीका है।

• Charter — एक session का मिशन: क्या explore करना है, किसके साथ, और क्या ढूँढना है।
• Session — एक charter पर बिना रुकावट, समय-सीमित टेस्टिंग की अवधि।
• Session sheet — session का संरचित रिकॉर्ड: charter, टेस्टर, समय, नोट्स, बग, issues, डेटा फ़ाइलें और समय का बँटवारा।
• Debrief — session के तुरंत बाद टेस्टर और lead के बीच छोटी बातचीत।
• Metrics — session sheets से जोड़ी गई गिनतियाँ और समय के अनुपात, जो अगले session की दिशा तय करते हैं।

Charter लिखना

Charter एक या दो वाक्य हैं जो टेस्टर को बताते हैं कि कहाँ जाना है और क्यों, बिना यह बताए कि कहाँ क्लिक करना है। Elisabeth Hendrickson की किताब Explore It! का एक लोकप्रिय टेम्पलेट तीन हिस्सों वाला है: Explore <target> with <resources> to discover <information>। Target कोई हिस्सा, फ़ीचर या रिस्क है; resources डेटा, टूल, कॉन्फ़िगरेशन या तकनीकें हैं; information उस तरह की समस्या या जानकारी है जिसकी आपको तलाश है।

अच्छे charter रिस्क, requirements, हाल के बदलाव, पुराने बग के समूह, debrief में उठे सवाल और ऑटोमेटेड कवरेज के गैप से आते हैं। जितने चला सकें उससे ज़्यादा charter लिखें, उन्हें रिस्क के क्रम में रखें और सूची के ऊपर वाले चलाएँ। उदाहरण के लिए, SAR में बेचने वाले एक काल्पनिक ऑनलाइन स्टोर के checkout के लिए नीचे के छह charter (C-01 से C-06) ये हिस्से कवर करते हैं: डिस्काउंट, कूपन और 15% VAT के साथ ऑर्डर टोटल, ताकि राउंडिंग और गणना की गलतियाँ मिलें; declined, timed-out और 3-D Secure वाले sandbox कार्ड से पेमेंट, ताकि पता चले कि विफलताएँ कैसे संभाली जाती हैं और ऑर्डर दोहराए तो नहीं जाते; हर स्टेप पर बाधित checkout (Back, refresh, बंद टैब, नेटवर्क जाना), ताकि खोए या असंगत ऑर्डर मिलें; एक ही यूज़र का cart दो टैब और दो डिवाइस पर, ताकि session के बीच state के टकराव मिलें; अरबी, अंग्रेज़ी और मिले-जुले इनपुट के साथ सऊदी National Address फ़ॉर्म, ताकि validation और डिस्प्ले की समस्याएँ मिलें; और confirmation ईमेल, invoice PDF व order history, ताकि checkout में दिखी जानकारी से असंगतियाँ मिलें।

• बहुत चौड़ा: "Checkout को explore करें।" — कोई दिशा नहीं, और एक session में पूरा नहीं हो सकता।
• बहुत संकरा: "कूपन SAVE10 डालें और जाँचें कि टोटल 90.00 है।" — यह test case है, charter नहीं।
• सही: एक हिस्सा, एक तरह का रिस्क, एक session में पूरा होने लायक, और टेस्टर के लिए तरीके चुनने की जगह।

C-01  Explore the order total with discounts, coupons and 15% VAT
      to discover rounding and calculation errors.
C-02  Explore payment with declined, timed-out and 3-D Secure sandbox cards
      to discover how failures are handled and whether orders are duplicated.
C-03  Explore checkout interrupted at each step (Back, refresh, closed tab,
      lost network) to discover lost or inconsistent orders.
C-04  Explore the cart in two tabs and on two devices for the same user
      to discover state conflicts between sessions.
C-05  Explore the Saudi National Address form with Arabic, English and mixed
      input to discover validation and display problems.
C-06  Explore the confirmation email, invoice PDF and order history
      to discover inconsistencies with what checkout showed.

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

समय-सीमित session चलाना

Session में रुकावट नहीं होती: उसकी अवधि में कोई मीटिंग, चैट या ईमेल नहीं। मूल विवरण में एक normal session लगभग नब्बे मिनट का होता है; पैंतालीस मिनट के क़रीब वाला session short और दो घंटे के क़रीब वाला long गिना जाता है, और session का समय सख़्ती से नहीं नापा जाता। बिना रुकावट का समय इसलिए अहम है क्योंकि exploration प्रोडक्ट का एक मानसिक मॉडल बनाता है जो हर context switch पर खो जाता है।

Charter पर टिके रहें, पर कठोरता से नहीं। अगर charter के बाहर कुछ अहम मिले तो उसे नोट करें, और या तो थोड़ी देर उसका पीछा करें — उस समय को "opportunity" काम के रूप में दर्ज किया जाता है — या उसके लिए नया charter सुझाएँ। अगर charter ग़लत या ब्लॉक निकले, तो session जल्दी ख़त्म करें और sheet पर यह लिखें; यह उपयोगी जानकारी है, विफलता नहीं।

• पहले: charter पढ़ें, टेस्ट डेटा और अकाउंट तैयार करें, बिल्ड और एनवायरनमेंट जाँचें, नोट्स फ़ाइल खोलें और अगर टीम इस्तेमाल करती है तो स्क्रीन रिकॉर्डिंग शुरू करें।
• दौरान: टेस्ट करें, टाइमस्टैम्प वाले नोट्स लें, हर संदिग्ध चीज़ का सबूत कैप्चर करें, सवालों और नए charter आइडिया की सूची रखें।
• अंत में: time-box पर रुकें, कुछ मिनट नोट्स साफ़ करने में लगाएँ, समय के बँटवारे का अनुमान लगाएँ, और बग रिपोर्ट का ड्राफ़्ट बनाएँ।

आज़माएँ: टेस्ट डेटा फ़ैक्टरी

Session sheet

Session sheet एक plain-text या फ़ॉर्म रिकॉर्ड है जो session को रिपोर्ट करने लायक बनाता है। मूल तरीके में sheets में तय हेडिंग होती थीं ताकि एक छोटा टूल उन्हें पढ़कर जोड़ सके; आज कोई भी ट्रैकर, स्प्रेडशीट या विकी टेम्पलेट चलता है, बशर्ते हर sheet में वही फ़ील्ड हों। नीचे का उदाहरण उदाहरण-मात्र है और मूल हेडिंग की भावना के अनुसार है।

• Bugs प्रोडक्ट की समस्याएँ हैं। Issues वह सब है जिसने session को ख़तरे में डाला या जिस पर फ़ैसला चाहिए — ब्लॉक एनवायरनमेंट, डेटा की कमी, खुले सवाल।
• नोट्स टेस्टर और debrief के लिए हैं; वे स्क्रिप्ट नहीं हैं, पर इतने होने चाहिए कि जो कवर हुआ उसे फिर से समझा जा सके।
• डेटा फ़ाइलें (रिकॉर्डिंग, कैप्चर किया ट्रैफ़िक, लॉग) sheet के साथ रखें ताकि बग रिपोर्ट उनका हवाला दे सकें।

CHARTER
  C-03  Explore checkout interrupted at each step (Back, refresh, closed tab,
        lost network) to discover lost or inconsistent orders.

AREAS     Checkout | Payment | Order history | Web, Chrome 129, Windows 11
BUILD     5.2.0 (staging)
START     2026-09-28 09:30
TESTER    Omar K.
DURATION  normal (90 min)

TASK BREAKDOWN
  Test design and execution         60%
  Bug investigation and reporting   25%
  Session setup                     15%
  Charter vs opportunity            85 / 15

DATA FILES
  c03-notes.txt   c03-recording.mp4   c03-checkout.har

TEST NOTES
  09:41  Refresh on shipping step keeps the address. OK.
  09:52  Network off right after "Pay": spinner never ends, no retry message.
  10:05  Back after payment success returns to the pay step; "Pay" enabled.
  10:11  Paid again from that page -> second order ORD-7781 created.  BUG
  10:30  Opportunity: order history lists ORD-7781 twice after refresh.

BUGS
  BUG-2214  Back after successful payment allows a second charge
  BUG-2215  No error or retry when the network drops after "Pay"

ISSUES
  - Payment sandbox timed out 3 times (about 10 min lost to setup).
  - Is paying again after Back ever valid? Asked the product owner.

समय कहाँ जाता है, इसे ट्रैक करना

SBTM टेस्टर से अनुमान माँगता है कि session का समय तीन तरह के काम में कैसे बँटा: test design और execution (समस्याएँ खोजना), bug investigation और reporting (जो मिला उसे रिप्रोड्यूस करना, अलग करना और लिखना), और session setup (एनवायरनमेंट, डेटा और टूल तैयार करना और रुकावटों से निपटना)। Sheet यह भी दर्ज करती है कि कितना समय charter पर गया और कितना रास्ते में मिले opportunities पर। मूल तरीके में ये तीन अनुपात session के charter वाले हिस्से का बँटवारा बताते हैं और opportunity का हिस्सा इनके साथ अलग दर्ज होता है; इसलिए charter पर टेस्टिंग का समय लगभग session की लंबाई × charter का हिस्सा × test का हिस्सा होता है: C-03 sheet के लिए 90 मिनट × 85% × 60% ≈ 46 मिनट, जिसे नीचे की रिपोर्ट 0.8 h दिखाती है। मोटे प्रतिशत काफ़ी हैं; लक्ष्य कई session में दिखने वाला रुझान है, टाइमशीट नहीं।

यह बँटवारा निदान का औज़ार है। सिर्फ़ पहली श्रेणी सीधे टेस्ट कवरेज बढ़ाती है, इसलिए जब वह घटे तो कुछ टेस्टिंग का समय खा रहा है — और बाक़ी दो श्रेणियाँ बताती हैं कि क्या।

• कई session में setup समय ज़्यादा — अस्थिर एनवायरनमेंट, धीमी deployment या टेस्ट डेटा की कमी; इन्फ़्रास्ट्रक्चर ठीक करें, टेस्टरों को नहीं।
• Bug investigation समय ज़्यादा — हिस्से में बग ज़्यादा हैं (रिस्क के लिए उपयोगी इनपुट) या बग रिप्रोड्यूस करना मुश्किल है, जो बेहतर लॉग और डायग्नॉस्टिक्स की ज़रूरत बताता है।
• Opportunity हिस्सा ज़्यादा — शायद charter ठीक निशाने पर नहीं हैं, या प्रोडक्ट टेस्टरों को बार-बार चौंका रहा है; charter सूची की समीक्षा करें।
• कई session में टेस्ट समय ज़्यादा पर बग कम — शायद हिस्सा मज़बूत है; session को ज़्यादा रिस्की हिस्सों में ले जाने पर विचार करें।

Session का debrief

Debrief टेस्टर और test lead या किसी साथी के बीच एक छोटी बातचीत है, जो session के तुरंत बाद होती है, जब याददाश्त ताज़ा हो। यह एक व्यक्ति के exploration को साझा ज्ञान में बदलता है; यहीं lead कोचिंग करता है, नोट्स और बग रिपोर्ट की गुणवत्ता जाँचता है, और तय करता है कि आगे क्या टेस्ट करना है।

Debrief ठोस नतीजों के साथ ख़त्म होता है: session sheet स्वीकार या सुधारी जाती है, बग फ़ाइल होते हैं, हर सवाल को एक owner मिलता है और charter सूची अपडेट होती है। Checkout के उदाहरण में debrief बार-बार होने वाले पेमेंट रिक्वेस्ट पर एक नया charter जोड़ेगा और डबल-चार्ज वाले बग को सीधे triage में भेजेगा।

• क्या हुआ? आपने क्या कवर किया, और किस तक नहीं पहुँच पाए?
• क्या मिला — बग, issues, सवाल? क्या बग रिपोर्ट फ़ाइल करने के लिए तैयार हैं?
• क्या रुकावट बना — एनवायरनमेंट, डेटा, एक्सेस, अस्पष्ट requirements?
• आगे क्या होना चाहिए — नए charter, फ़ॉलो-अप, वे हिस्से जिन्हें और session चाहिए?
• अब आप इस हिस्से को कैसे आँकते हैं — रिस्की, मज़बूत, या अब भी अनजान?

Session sheets से रिपोर्टिंग

क्योंकि हर session का एक charter, एक हिस्सा और समय का बँटवारा होता है, sheets को जोड़ा जा सकता है: हर हिस्से के session, असल टेस्टिंग में लगा समय, हर हिस्से के बग और issues, और अभी खुले charter। यह मैनेजर के सवाल का ईमानदार जवाब देता है — उदाहरण के लिए, "इस स्प्रिंट में checkout के छह session हुए और लगभग साढ़े पाँच घंटे charter पर टेस्टिंग हुई; पेमेंट विफलता हैंडलिंग के अभी दो charter खुले हैं और एक critical बग है"।

कवरेज की तुलना रिस्क से करें: कम session वाला हाई-रिस्क हिस्सा गैप है, और बहुत सारे session खा जाने वाला लो-रिस्क हिस्सा शायद ज़रूरत से ज़्यादा टेस्ट हुआ है। संख्याओं को बातचीत की शुरुआत मानें। Session और बग की गिनती व्यक्तियों की उत्पादकता का कमज़ोर पैमाना है, और उन्हें ऐसे इस्तेमाल करना छोटे, सतही session और मामूली बग रिपोर्ट को बढ़ावा देता है; टेस्ट metrics को सामान्य रूप से चुनना और इस्तेमाल करना test metrics गाइड में है।

Area               Sessions  On-charter testing  Bugs  Issues  Open charters
Order total            2          2.1 h            1      0          0
Payment failures       2          1.4 h            3      2          2
Interrupted flow       1          0.8 h            2      2          1
Address (Arabic/RTL)   1          1.2 h            1      0          0

टीम में SBTM शुरू करना

• छोटे से शुरू करें — एक फ़ीचर, पाँच से दस charter की सूची, दिन में एक-दो session और हर एक के बाद debrief।
• पहले से मौजूद टेम्पलेट इस्तेमाल करें — ट्रैकर का टिकट टाइप, विकी पेज या हर session के लिए साझा डॉक्यूमेंट; टूल से ज़्यादा फ़ील्ड की एकरूपता मायने रखती है।
• Charter को वर्कफ़्लो से जोड़ें — हर रिस्की स्टोरी के लिए refinement में charter का ड्राफ़्ट बनाएँ और स्टोरी के टेस्ट एनवायरनमेंट में पहुँचने पर उन्हें चलाएँ।
• Session को बग और regression से जोड़ें — हर बग अपने session से लिंक हो, और session से निकले हर regression case का एक owner हो; जिसका expected result स्थिर हो वह CI पाइपलाइन में ऑटोमेटेड चेक बने।
• जोड़ी में काम करें — एक स्क्रीन पर डेवलपर या प्रोडक्ट ओनर के साथ टेस्टर प्रोडक्ट ज्ञान फैलाता है और अलग बग ढूँढता है।
• हर स्प्रिंट charter सूची की समीक्षा करें — कवर हुए charter बंद करें और debrief, incidents और बदलावों से नए जोड़ें।

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

SBTM में आम गलतियाँ

• ऐसे session जो सच में बिना रुकावट नहीं हैं — मीटिंग और चैट से भरा 90 मिनट का session असल में कई छोटे, सतही session है।
• शेड्यूल तंग होने पर debrief छोड़ देना, जिससे वह कोचिंग और सीख ख़त्म हो जाती है जिस पर SBTM टिका है।
• अगले दिन याददाश्त से session sheet भरना।
• Test case की तरह लिखे charter, जो exploration को अतिरिक्त काग़ज़ी काम के साथ फिर से स्क्रिप्टेड टेस्टिंग बना देते हैं।
• ब्लॉक हुए session को जल्दी ख़त्म न करना — sheet में रुकावट दिखनी चाहिए, एक घंटे का "setup" नहीं।
• टेस्टरों की रैंकिंग के लिए session और बग की गिनती का इस्तेमाल।
• नोट्स में ही रह जाने वाली खोजें — बग फ़ाइल नहीं हुए, सवाल पूछे नहीं गए, regression आइडिया कभी केस नहीं बने।

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

संदर्भ

• Session-Based Test Management (Jonathan Bach)Satisfice, Inc. · 2000session-based test management का मूल विवरण: चार्टर वाले, समय-सीमित exploratory सेशन, session sheet और debrief।
• 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एक्सप्लोरेटरी टेस्टिंग का अनुशासन: चार्टर, इनपुट और स्टेट बदलने के ह्यूरिस्टिक, और यह स्क्रिप्टेड टेस्ट का पूरक कैसे है।
• Lessons Learned in Software Testing: A Context-Driven Approach (Cem Kaner, James Bach, Bret Pettichord)Wiley · 2001बग रिपोर्टिंग, टेस्ट डिज़ाइन, ऑटोमेशन और टेस्टिंग प्रबंधन पर व्यावहारिक सबक — कॉन्टेक्स्ट-ड्रिवन स्कूल।
• ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।