मॉड्यूल 25 · प्रोफ़ेशनल QA और टेस्ट मैनेजमेंट

टेस्ट स्कोप

Mutqan Soft QA टीम द्वारा · · 19 मिनट · उन्नत

Test scope किसी एक project, release या sprint के लिए testing की सहमत सीमा है: कौन-से test items टेस्ट होंगे (applications, services और उनके versions), कौन-से features और quality characteristics, किन test levels पर, किन platforms पर और किन भाषाओं में — और उतनी ही साफ़ तरह से, क्या टेस्ट नहीं होगा। ISTQB Foundation syllabus (v4.0) test plan में test scope को context of testing का हिस्सा बताता है, test objectives और test basis के साथ।

उदाहरण: Bustan Market, यानी test strategy guide वाले काल्पनिक marketplace, का release 4.2 एक external provider के ज़रिए किस्तों में payment (instalments) जोड़ता है। In scope: web और दोनों apps पर Arabic और English में नया payment option, eligibility rules, refunds, और उन payment methods का regression जो उसका code share करते हैं। Out of scope: provider का अपना credit decision, जिसे provider खुद टेस्ट करता है।

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

अस्पष्ट scope दो तरफ़ से नुकसान करता है। Gaps तब बनते हैं जब हर कोई मान लेता है कि किसी हिस्से को कोई और टेस्ट कर रहा है — refunds, Arabic receipt, app का पुराना version जो customers अब भी इस्तेमाल करते हैं — और उसका पहला test production में होता है। बर्बादी तब होती है जब टीम उन हिस्सों पर दिन लगा देती है जो बदले ही नहीं या जिनकी owner कोई और टीम है।

Scope estimate, schedule, environments और exit criteria का input भी है। जब scope बढ़ता है और कोई इन्हें adjust नहीं करता, तो टीम या तो date miss करती है या चुपचाप छोड़े गए tests के साथ release कर देती है। Tester के लिए लिखा और सहमत scope सुरक्षा भी है और ज़िम्मेदारी भी: अगर किसी ऐसे हिस्से में defect आए जिसे product owner की मानी हुई वजह से बाहर रखा गया था, तो बात उस फ़ैसले पर होती है, दोष पर नहीं — और हर exclusion का risk बताना आपसे अपेक्षित है।

Test scope क्या-क्या तय करता है

काम का scope statement इतना specific होता है कि "क्या यह टेस्ट होगा?" का जवाब दो लोग एक जैसा दें: यह items को ID और version से पहचानता है, "checkout" या "app" जैसे शब्दों से नहीं। Test strategy के default scope से शुरू करें और उसे बदले हुए हिस्सों पर इन dimensions में लागू करें:

  • Test items: test object के वे हिस्से जो टेस्ट होंगे, जैसे applications और services, हर एक अपने version के साथ, जैसे web 4.2, iOS और Android apps 4.2 और payments API v3।
  • Features और changes: stories, requirements या change requests उनकी ID के साथ, और वे मौजूदा features जिन पर change असर डालता है।
  • Quality characteristics और test types: functional, performance, security, accessibility, compatibility — और इस बार कौन-से लागू हैं।
  • Test levels: जैसे QA द्वारा system और system integration testing, developers द्वारा CI में component testing।
  • Platforms, browsers, devices, भाषाएँ और regions जो असल में इस्तेमाल होंगे।
  • Interfaces: हमारी testing कहाँ रुकती है, जैसे "payment provider integration का हमारा हिस्सा, उसके sandbox में"।
  • Depth: in scope कोई हाँ/ना flag नहीं है। ISTQB syllabus में product risk analysis test scope और उसकी thoroughness, दोनों तय करता है: हर item का एक risk level और उससे निकलने वाली depth होती है।

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

Out of scope: वजह के साथ लिया गया फ़ैसला

Out-of-scope list फ़ैसलों की list है, भूली हुई चीज़ों की नहीं। हर exclusion में item, वजह, उसकी जगह कौन cover करता है और किसने सहमति दी, यह लिखा होता है; अगर इससे कोई risk बचता है, तो release का owner, आम तौर पर product owner, उसे साफ़ तौर पर accept करता है। Test documentation standard ISO/IEC/IEEE 29119-3 भी test plan के test scope में इसका मूल हिस्सा माँगता है: testing से बाहर रखे गए features और उन्हें बाहर रखने का औचित्य।

Exclusion साफ़ तौर पर तय होता है: testing शुरू होने से पहले scope पर सहमति के समय, या बाद में एक दर्ज scope change के रूप में। जो planned test चला ही नहीं — blocked environment, समय ख़त्म — वह "out of scope" नहीं है: वह coverage gap है, जिसे progress और completion reports में residual risk के रूप में दिखाना ज़रूरी है।

Scope review में आम तौर पर टिकने वाली वजहें:

  • बदला नहीं और change से प्रभावित नहीं; regression suite उसे cover करता है।
  • किसी और टीम या vendor का: वे उसे टेस्ट करते हैं; आप interface का अपना हिस्सा टेस्ट करते हैं और उनका evidence माँगते हैं।
  • इस release का हिस्सा नहीं।
  • उपलब्ध environments में टेस्ट नहीं हो सकता: लिखें कि उसकी जगह क्या होगा, जैसे mocked responses या deployment के बाद एक check।
  • कम risk, जिसे product owner ने साफ़ तौर पर accept किया।
Bustan Market 4.2 में in scope बनाम out of scope: in-scope item के साथ उसकी ID, risk और depth होती है; exclusion के साथ वजह, उसकी जगह कौन cover करता है और किसने सहमति दी, और कोई residual risk हो तो product owner उसे accept करता है।

In scope

इस release में, तय depth के साथ टेस्ट होता है

हर entry में:
Item ID, version, risk level और depth
आम वजह:
नया या बदला हुआ, या change से प्रभावित
उदाहरण: Bustan Market 4.2:
Checkout पर instalment option, web और apps, Arabic और English
कौन तय करता है:
QA प्रस्ताव देता है; product owner और dev lead सहमति देते हैं
बदलने पर:
इसे हटाना या depth घटाना scope change है: इसके लिए फ़ैसला चाहिए
Test completion पर:
Coverage, results और open defects report होते हैं

Out of scope

इस release में यह टीम इसे जानबूझकर टेस्ट नहीं करती

हर entry में:
वजह, उसकी जगह कौन cover करता है, किसने सहमति दी
आम वजह:
बदला नहीं, किसी और टीम या vendor का, या इस release में नहीं
उदाहरण: Bustan Market 4.2:
Provider का credit decision: provider टेस्ट करता है; हम उसके sandbox में अपना हिस्सा
कौन तय करता है:
QA प्रस्ताव देता है; product owner residual risk accept करता है
बदलने पर:
इसे अंदर लाने के लिए impact estimate और फ़ैसला चाहिए
Test completion पर:
Accepted risk के साथ फिर से not tested के रूप में सूचीबद्ध

Scope पर सहमति कैसे बनाएँ और उसे document कैसे करें

Scope testing टीम प्रस्तावित करती है; सहमति product और release के owners देते हैं, आम तौर पर एक छोटे scope review में।

  • Basis इकट्ठा करें: release notes, stories और acceptance criteria, change list और strategy का default scope।
  • पता करें कि change किसे छूता है: developers से पूछें कि कौन-से components, data और integrations प्रभावित हैं; traceability जुड़े requirements और tests दिखाती है।
  • दोनों lists लिखें — in scope के साथ ID, risk और depth, out of scope के साथ वजह और owner — और अंदाज़ा लगाने की बजाय खुले सवाल चिह्नित करें।
  • Product owner, development lead और किसी excluded item को cover करने वाले हर व्यक्ति के साथ review करें। Out-of-scope list ज़ोर से पढ़ें; गलतफ़हमियाँ वहीं सामने आती हैं।
  • नतीजा test plan के scope section में या one-page sprint test plan में version, तारीख़ और approver के साथ दर्ज करें।
  • Change rule तय करें: change कौन माँग सकता है, उसका impact कौन estimate करता है और फ़ैसला कौन करता है।

आज़माएँ: Requirements → टेस्ट केस

Worked example: instalment payments वाले release का scope

नीचे दिया statement Bustan Market 4.2 का सहमत scope है, 30 मिनट के review के बाद। Out of scope की हर line में वजह और owner है, provider के साथ सीमा सटीक है, और जो एक risk accept हुआ वह लिखा हुआ है।

Depth column हर risk level को ठोस tests में बदलता है: BUS-902 eligibility range की 2-value boundary values लिखता है, और regression वाली line उन unchanged payment methods को scope में लाती है, क्योंकि वे बदला हुआ checkout code share करते हैं।

TEST SCOPE - Bustan Market 4.2 "Pay in instalments" (fictional)          v1.0
Basis: BUS-901..905, test strategy v1.2     Agreed: PO, dev lead, QA lead (day 1)

IN SCOPE                                            Risk    Depth
BUS-901  Instalment option at checkout,             High    boundaries, negative,
         web + iOS + Android, ar/en                         exploratory, auto API
BUS-902  Eligibility: total 200.00 to 5,000.00      High    199.99 / 200.00 /
         SAR, signed-in customers only                      5,000.00 / 5,000.01
BUS-903  Instalment schedule in "My orders"         Medium  dates, amounts, ar/en
BUS-904  Refund, partial refund, cancellation       High    before and after the
         of instalment orders                               first instalment
BUS-905  Our handling of provider webhooks          Medium  approved, declined,
         (approved, declined, expired)                      expired, duplicate
Regr.    Card, mada, Apple Pay, cash on delivery    Medium  automated checkout
         (they share the checkout code)                     suite + 2 devices

OUT OF SCOPE                Reason                      Covered by
Provider credit decision    provider-owned service      provider; we test our
and the provider app                                    side in its sandbox
Seller portal               unchanged in 4.2            nightly regression suite
Load test of provider API   not ours to load-test       provider SLA (PO agreed)

Accepted risk  provider outage tested with mocked responses only (PO, day 1)
Assumptions    provider sandbox from day 1; synthetic customers only
Changes        request to PO -> QA impact note -> PO decides -> scope v1.1, v1.2

Scope creep: पहचानें और नियंत्रित करें

Scope creep सहमति के बाद scope का ऐसा बढ़ना है जिसके साथ समय, लोगों या exit criteria में कोई बदलाव नहीं होता। यह शायद ही कभी formal request बनकर आता है: यह ऐसा दिखता है — "वैसे भी टेस्ट कर रहे हो, ज़रा यह भी देख लो…", test design के बाद दोबारा लिखे गए acceptance criteria (पुराने और नए text की तुलना करें ताकि ठीक-ठीक दिखे कि क्या बदला), या release branch में देर से merge हुआ change।

Change अपने आप में सामान्य है। 2020 Scrum Guide कहता है कि Sprint के दौरान, जैसे-जैसे ज़्यादा पता चले, scope को Product Owner के साथ स्पष्ट और फिर से तय (renegotiate) किया जा सकता है, और Sprint Goal को ख़तरे में डालने वाला कोई change नहीं किया जाता। समस्या वह change है जो सहमति को bypass करे।

Bustan Market release के दूसरे हफ़्ते में message आता है: "क्या instalments gift card orders पर भी चल सकते हैं? छोटा-सा change है।" Tester एक impact note (अलग refund rule, gift card checkout का regression, लगभग तीन extra tester-days) और तीन options के साथ जवाब देता है: testing बढ़ाना, इसे 4.3 में ले जाना, या instalment option (BUS-901) की exploratory testing घटाकर वह risk accept करना। Product owner 4.3 चुनता है; scope v1.1 इसे दर्ज करता है।

  • Assess करें: नए tests, regression, मेहनत और risk।
  • Options दें: ज़्यादा समय, change को टालना, या कुछ और घटाना, उसका risk accept करवाकर।
  • फ़ैसला और record: owner चुनता है; scope version, estimate और exit criteria update करें।
  • उल्टी दिशा पर भी नज़र रखें: समय कम पड़ने पर आख़िर में planned tests छोड़ना भी सहमत scope को बदलता है; इसके लिए वही फ़ैसला चाहिए, और इसे residual risk के रूप में report किया जाता है, "out of scope" का नया label देकर नहीं।

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

आम गलतियाँ

  • सिर्फ़ in-scope list लिखना, जिससे हर stakeholder मान लेता है कि उसका हिस्सा cover है।
  • बिना वजह या owner के items बाहर करना: "टेस्ट नहीं किया" कोई फ़ैसला नहीं है।
  • Scope को IDs, versions, platforms और भाषाओं की बजाय आम शब्दों ("checkout", "app") में लिखना।
  • In scope की हर चीज़ को एक जैसी मेहनत देना, जिससे high-risk payment rule और label change, दोनों को एक ही सरसरी जाँच मिलती है।
  • "छोटे" additions को बिना impact assessment के समा लेना, फिर date miss करना या चुपचाप tests काटना।
  • Exclusions का फ़ैसला अकेले करना: business की ओर से risk accept करना product owner का फ़ैसला है।

QA का नज़रिया

असली टीम में scope का draft test planning में बनता है, release या sprint planning के ठीक बाद, और हर change पर दोबारा देखा जाता है। आप product owner के साथ तय करते हैं कि क्या मायने रखता है, developers के साथ कि change किसे छूता है, और vendors व shared components के owners के साथ कि हर interface पर कौन क्या टेस्ट करता है। सबसे काम के सवाल: "क्या बदला, और उस पर क्या निर्भर है?", "इसे और कौन टेस्ट करता है, और किस evidence के साथ?" और "अगर हम इसे टेस्ट न करें तो क्या होगा?"।

Scope statement को version के साथ रखें और उसी के सामने report करें: status reports सहमत scope की coverage दिखाते हैं, और test completion report exclusions और accepted residual risks को दोहराती है, ताकि release का फ़ैसला पूरी तस्वीर के साथ हो। ISTQB syllabus scope creep को project risks में गिनता है: अगर यह बार-बार हो, तो इसे risk register में दर्ज करें।

अभ्यास

Clinic booking release का scope लिखें और change request संभालें

आपका काम

Shifa Clinics के release 3.1 में — जो web, Android और iOS पर, Arabic और English में एक काल्पनिक booking app है — ये बदलाव हैं: (1) video consultations की booking और card payment; (2) appointment से 24 घंटे पहले जाने वाले reminder SMS में cancellation link; (3) admin portal में डॉक्टरों के लिए weekly schedule view।

Context: video call एक external service पर चलती है जो app में embedded है और जिसे उसका vendor टेस्ट करता है। Patient records और lab results नहीं बदले। SMS gateway pharmacy app के साथ shared है और उसकी owner दूसरी टीम है। आपके पास दो testers और दस working days हैं। Scope statement लिखें। छठे दिन product owner chat में लिखता है: "क्या आप video consultations के लिए insurance से payment भी check कर सकते हैं? छोटा-सा change है।"

चरण
  1. हर बदले हुए item को, वह जिसे छूता है उसके साथ, in scope (depth के note के साथ) या out of scope (वजह और owner के साथ) में रखें।
  2. कम से कम तीन सवाल लिखें जो scope पर सहमति से पहले सुलझने चाहिए।
  3. छठे दिन की request को scope change की तरह handle करें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

In scope: सभी platforms पर दोनों भाषाओं में video booking और card payment, high risk (slots, time zones, payment failure, double booking, refunds); video integration का हमारा हिस्सा (call शुरू करना, camera permission deny होना, service का बंद होना); SMS cancellation link (valid, expired और पहले से इस्तेमाल हुआ link; ar/en text) और weekly view (हफ़्ते की शुरुआत और अंत, आधी रात के आर-पार जाने वाले appointments), medium risk; और in-clinic booking व मौजूदा payments का regression, जो वही code share करते हैं।

Out of scope, हर एक product owner की सहमति से: video service और call quality (vendor की; उनका evidence माँगें), patient records और lab results (बदले नहीं; मौजूदा regression suite), SMS gateway delivery (messaging team की; हम सिर्फ़ अपना text और link check करते हैं)।

सवाल: app के कौन-से पुराने versions नई booking API के साथ चलने चाहिए? SMS link से cancel होने पर क्या paid consultation का refund अपने आप होता है? क्या video vendor test results या sandbox देगा?

छठा दिन: चुपचाप शुरू न करें। Impact estimate करें (नया payment path, eligibility rules, insurer integration, refunds: लगभग तीन से चार tester-days, ऊपर से payment regression) और options दें: ज़्यादा समय, 3.2 तक टालना, या कहीं और कम depth के साथ risk accept करना। Acceptance criteria वाली story माँगें, फ़ैसला scope v1.1 में दर्ज करें, और estimate व exit criteria update करें।

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

Test scope और project scope में क्या फ़र्क़ है?

Project scope वह काम है जो project को अपने product के features और बाकी outputs deliver करने के लिए करना है। Test scope वह है जो testing cover करती है। दोनों overlap करते हैं पर बराबर नहीं हैं: कोई feature release में हो सकता है जबकि उसका एक हिस्सा test scope से बाहर हो (vendor का component), और test scope उससे आगे भी जा सकता है जो release बदलता है: change पर निर्भर unchanged हिस्सों का regression, और हर supported platform।

Out of scope क्या है, यह कौन तय करता है?

Tester या QA lead प्रस्ताव देता है। Release risk का owner, आम तौर पर product owner या project manager, सहमति देता है, और development lead व excluded components के owners पुष्टि करते हैं कि उन्हें कौन cover करता है। Tester अकेले items नहीं हटाता और business की ओर से risk accept नहीं करता।

क्या हर scope change, scope creep है?

नहीं। Change अपेक्षित है, ख़ासकर agile टीमों में; 2020 Scrum Guide Sprint के दौरान Product Owner के साथ scope को स्पष्ट और renegotiate करने की अनुमति देता है। यह creep तब बनता है जब यह सहमति को bypass करे: बिना impact assessment के और समय, लोगों या criteria को adjust किए बिना जोड़ा जाए।

Agile टीम में scope कहाँ document करूँ?

Sprint या release के one-page test plan में, या test plan के scope section में। Sprint Backlog की stories अपने acceptance criteria के साथ in-scope list का मूल हैं; उनसे प्रभावित regression areas और platforms जोड़ें, और exclusions उसी page पर अपनी वजहों के साथ लिखें, जिसे team board से link किया जाए।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • 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 रिपोर्ट।
  • The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020Scrum की परिभाषा: उसकी ज़िम्मेदारियाँ, events और artifacts, Definition of Done सहित जिसे पूरा करने में टेस्टिंग मदद करती है।
टूल्स

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

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

फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।

टेस्ट डिज़ाइन

Requirements → टेस्ट केस

क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।

टेस्ट डिज़ाइन

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

बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।

टेस्ट डिज़ाइन

टेक्स्ट डिफ़

दो टेक्स्ट की लाइन-दर-लाइन या शब्द-दर-शब्द तुलना करें और अंतर हाइलाइट करें।

फ़ॉर्मेटिंग

और गहराई से

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

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