मॉड्यूल 6 · टेस्ट सिनेरियो और टेस्ट केस

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

Mutqan Soft QA टीम द्वारा · · 17 मिनट · शुरुआती

Test scenario एक लाइन का statement है जो बताता है कि system को किस स्थिति को संभालना है: कौन क्या करता है, किस condition में, और कौन-सा नतीजा मायने रखता है। "Customer card से paid order को out for delivery होने से पहले cancel करता है और पूरा refund पाता है" एक scenario है। यह बताता है कि क्या टेस्ट होगा, कैसे नहीं: न steps, न exact data, न screen की details।

हर scenario आम तौर पर बाद में एक या ज़्यादा test cases में फैलता है। Scenarios पहले आते हैं क्योंकि एक-एक लाइन वाली स्थितियों की छोटी list पूरी team मिनटों में review कर सकती है।

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

सबसे महँगे gaps वे स्थितियाँ हैं जिनके बारे में किसी ने सोचा ही नहीं, और detailed test cases का ढेर उन्हें छिपा देता है। जो teams story से सीधे test cases पर कूद जाती हैं, वे अक्सर main path के लिए बहुत-से cases लिखती हैं और fail होने वाले refund या इरादा बदलने वाले user के लिए एक भी नहीं। Scenarios की list scope को उस स्तर पर दिखाती है जहाँ ऐसे gaps साफ़ नज़र आते हैं।

Scenarios scope पर सहमति बनाने का सबसे सस्ता तरीका भी हैं: product owner और developers किसी के steps लिखने से पहले उन्हें review कर सकते हैं, और जिस scenario का expected result कोई न बता सके, वह coding से पहले मिला requirement का सवाल है।

Test scenario क्या है, और क्या नहीं

अच्छा scenario एक actor, एक स्थिति और मायने रखने वाले नतीजे का नाम लेता है, और अपने source तक trace होता है: user story, acceptance criterion, business flow का कोई step या risk। यह screens या concrete data पर निर्भर नहीं होता, इसलिए redesign के बाद भी टिका रहता है।

"Test scenario" ISTQB Foundation syllabus का key term नहीं है, और teams इसे अलग-अलग तरह इस्तेमाल करती हैं। सबसे नज़दीकी ISTQB terms हैं test condition, यानी component या system का testable पहलू जिसे testing के आधार के रूप में पहचाना गया हो, और test procedure, यानी execution के क्रम में test cases की sequence। Scenario अक्सर कई test conditions को एक ऐसी स्थिति में जोड़ता है जिससे user शुरू से अंत तक गुज़रता है। जो teams इस शब्द को test cases की क्रमबद्ध sequence के लिए इस्तेमाल करती हैं, उनका मतलब test procedure के करीब होता है।

  • अच्छा: "Customer ऐसा order cancel करने की कोशिश करता है जो पहले ही out for delivery हो चुका है।"
  • बहुत vague: "Order cancellation टेस्ट करें।" यह feature का नाम है, स्थिति का नहीं।
  • बहुत detailed: "Order 1042 खोलें, Cancel दबाएँ, Yes दबाएँ, message check करें।" यह test case है।

Scenario बनाम test case

Scenario जवाब देता है "कौन-सी स्थिति टेस्ट करें?"; test case जवाब देता है "ठीक-ठीक कैसे, किस data के साथ, और क्या result?"। एक scenario आम तौर पर कई test cases में फैलता है, data, state, role या boundary के हर variation के लिए एक, और हर case अपने scenario तक और उसके ज़रिए requirement तक trace होता है।

  • Detail: scenario एक लाइन है; test case में preconditions, data, steps और expected result होते हैं।
  • मक़सद: scenarios scope पर सहमति बनाते हैं और gaps दिखाते हैं; test cases execution को repeatable बनाते हैं।
  • पाठक: product owners scenarios review करते हैं; test cases उसके लिए हैं जो उन्हें चलाता है, इंसान हो या tool।
  • बदलाव: screen redesign होने पर test cases बदलते हैं, जबकि scenarios आम तौर पर वैसे ही रहते हैं।
Scenario TS-04 एक स्थिति, यानी देर से किया गया cancel, एक लाइन में बताता है; उसके तीन test cases order status, payment method और exact expected result जोड़ते हैं।

टेस्ट सिनेरियोएक लाइन

कौन-सी स्थिति टेस्ट करें?

क्या होता है:
Actor, स्थिति, मायने रखने वाला नतीजा, source
मक़सद:
Scope पर सहमति, छूटी हुई स्थितियाँ दिखाना
कौन review करता है:
Product owner, developers और testers
Screen redesign के बाद:
आम तौर पर वैसा ही
  • TS-04 Customer ऐसा order cancel करने की कोशिश करता है जो out for delivery हो चुका है

टेस्ट केसहर variation का एक

ठीक-ठीक कैसे, किस data से, और क्या result?

क्या होता है:
Preconditions, test data, steps, expected result
मक़सद:
Repeatable execution, साफ़ results
कौन review करता है:
Testers, और जो भी tests चलाए: इंसान या tool
Screen redesign के बाद:
Steps और checks update करने पड़ सकते हैं
  • TC-04.1 Out for delivery, card से paid: reject, कारण और support link
  • TC-04.2 Out for delivery, cash on delivery: reject, वही message
  • TC-04.3 Delivered, card से paid: reject, कुछ नहीं बदलता
TS-04  Customer ऐसा order cancel करने की कोशिश करता है जो out for delivery हो चुका है

TC-04.1  Order "Out for delivery", card से paid
         Expected: cancel reject; app कारण बताता है और support का link दिखाता है;
                   order status और payment नहीं बदलते
TC-04.2  Order "Out for delivery", cash on delivery
         Expected: TC-04.1 वाले message के साथ reject; status नहीं बदलता
TC-04.3  Order "Delivered", card से paid
         Expected: reject; order status और payment नहीं बदलते

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

Stories और flows से scenarios निकालना

User story एक goal का नाम लेती है और उसके acceptance criteria rules बताते हैं। Story, कोई भी flow diagram और main object जिन states से गुज़रता है, इनकी मदद से उस flow पर चलें जिससे user goal तक पहुँचता है, और हर step पर पूछें: और क्या हो सकता है?

तीन तरह के flows खोजें। Main flow, जिसे अक्सर happy path कहते हैं, goal तक पहुँचने का आम रास्ता है। Alternative flow बिना किसी error वाला दूसरा valid रास्ता है: कोई और payment method, या user जो इरादा बदलकर रुक जाता है। Exception flow वह है जो कुछ गलत होने पर होता है: कोई rule action को मना कर देता है, payment provider जैसी कोई dependency fail हो जाती है, या user के काम करते-करते data बदल जाता है। ज़्यादातर exception flows goal तक पहुँचे बिना ख़त्म होते हैं, लेकिन कुछ recover होकर main flow में लौट आते हैं।

  • Main flow को user के नज़रिए से कुछ छोटे steps में लिखें।
  • हर step पर पूछें कि कौन-सा दूसरा choice, data, state या role संभव है, और क्या गलत हो सकता है। नतीजा बदलने वाला हर जवाब एक संभावित scenario है।
  • पक्का करें कि हर acceptance criterion का कोई scenario हो।
  • हर scenario को id, flow type और source दें। अगर उसका expected result नहीं बता पा रहे, तो product owner के लिए सवाल लिखें।

आज़माएँ: User Story → टेस्ट सिनेरियो

Worked example: grocery order cancel करना

नीचे की story एक grocery delivery app की है। इसका main flow: customer order खोलता है, Cancel दबाता है और confirm करता है; order Cancelled हो जाता है, card payment refund होता है और confirmation आता है। इस flow पर चलने से story के नीचे लिखे छह scenarios मिलते हैं: एक main, दो alternative और तीन exception।

TS-05 और TS-06 का expected result criteria में नहीं है: कहीं नहीं लिखा कि refund fail होने पर क्या होता है, या देर से किए गए cancel में कौन-सा पल गिना जाएगा, dialog खुलने का या confirm करने का। किसी के test case लिखने से पहले ही दोनों product owner के लिए सवाल बन गए।

GRO-31  Order cancel करना
एक customer के रूप में, मैं अपना दिया हुआ order cancel करना चाहता हूँ,
ताकि जिस चीज़ की अब ज़रूरत नहीं उसके पैसे न दूँ।

AC1  Order तब तक cancel हो सकता है जब तक वह out for delivery न हो।
AC2  Cancel करने पर चुकाई गई पूरी रकम उसी card पर refund होती है जिससे payment हुआ;
     cash on delivery वाले order को refund की ज़रूरत नहीं।
AC3  Out for delivery वाला order cancel नहीं हो सकता: app कारण बताता है
     और support का link दिखाता है।
AC4  Cancel के बाद customer को app में और SMS से confirmation मिलता है।
Order statuses: Placed > Packed > Out for delivery > Delivered, या Cancelled

Scenarios
TS-01  main         AC1, AC2, AC4
       Out for delivery से पहले card से paid order cancel: order cancel,
       पूरी रकम card पर वापस, app में और SMS से confirmation
TS-02  alternative  AC1, AC2, AC4
       Cash on delivery वाला order cancel: order cancel, कोई refund नहीं, confirmation
TS-03  alternative  कोई criterion नहीं (flow का confirm step)
       Cancel dialog खोलकर order रखने का फ़ैसला: order जैसा था वैसा रहता है
TS-04  exception    AC1, AC3
       Out for delivery हो चुका order cancel करने की कोशिश: कारण और support link
       के साथ reject
TS-05  exception    कोई criterion नहीं
       Payment provider पर card का refund fail: expected result?  Q1
TS-06  exception    AC1, AC3
       Cancel dialog खुला रहते हुए order out for delivery हो जाता है:
       कौन-सा पल गिना जाएगा, dialog खुलने का या confirm करने का?  Q2

Scenario coverage: क्या कुछ छूट रहा है?

Scenario coverage पूछता है कि आपके चुने हुए test basis का हर item, जैसे acceptance criteria, flows, states, roles या risks, कम से कम एक scenario से exercise होता है या नहीं। Scenarios को उनके items से एक table में map करें, जिसमें हर scenario की एक row और हर item का एक column हो: यह एक सरल traceability matrix है। जिस item का कोई scenario नहीं, वह आपके tests में gap है; जिस scenario का कोई item नहीं, वह requirement में gap है या story से बाहर का काम, और उस पर सवाल बनता है।

Grocery order cancel करने का scenario coverage: छह scenarios चारों acceptance criteria को exercise करते हैं, TS-03 और TS-05 किसी criterion से trace नहीं होते, और TS-05 व TS-06 खुले सवालों पर ख़त्म होते हैं।
ScenarioAC1out for delivery तक cancelAC2card पर पूरा refundAC3देर से cancel rejectAC4app और SMS में confirmationExpected result
TS-01main · cancel, card से paidexercise होता हैexercise होता हैexercise नहीं होताexercise होता हैcriteria में लिखा है
TS-02alternative · cash on deliveryexercise होता हैexercise होता हैexercise नहीं होताexercise होता हैcriteria में लिखा है
TS-03alternative · order रखता हैexercise नहीं होताexercise नहीं होताexercise नहीं होताexercise नहीं होतासाफ़ है: order नहीं बदलता
TS-04exception · out for deliveryexercise होता हैexercise नहीं होताexercise होता हैexercise नहीं होताcriteria में लिखा है
TS-05exception · refund failexercise नहीं होताexercise नहीं होताexercise नहीं होताexercise नहीं होताखुला: सवाल Q1
TS-06exception · dialog के दौरान निकल जाता हैexercise होता हैexercise नहीं होताexercise होता हैexercise नहीं होताखुला: सवाल Q2
  • Scenario इस criterion को exercise करता है
  • Expected result तय नहीं: product owner के लिए सवाल

यह काग़ज़ पर coverage है: कोई criterion असल में तभी exercise होता है जब इन scenarios से बने test cases चलते हैं, और वह पूरा हुआ है, यह तभी साबित होता है जब वे pass होते हैं।

  • Criteria coverage: 4 में से 4। AC1 को चार scenarios exercise करते हैं, और AC2, AC3 व AC4 में से हर एक को दो।
  • Flow coverage: 6 में से 6, लेकिन सिर्फ़ list में मौजूद flows के लिए; जिस flow के बारे में किसी ने सोचा ही नहीं, वह denominator में नहीं होता।
  • Coverage items गिनता है, depth नहीं: AC2 के मुख्य checks, यानी exact रकम और वही card, उसके test cases में होते हैं।
  • यह coverage सिर्फ़ काग़ज़ पर है: criteria असल में तभी exercise होते हैं जब scenarios से बने test cases चलते हैं, और criteria पूरे हुए हैं, यह तभी साबित होता है जब वे tests pass होते हैं।

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

आम गलतियाँ

  • Clicks और data से भरे scenarios लिखना, जिससे list review के लिए बहुत लंबी हो जाती है और हर redesign पर टूट जाती है।
  • "Checkout टेस्ट करें" जैसे इतने broad scenarios लिखना कि कोई नहीं देख पाता कि क्या छूटा।
  • सिर्फ़ main flow और लिखे हुए criteria से scenarios निकालना, और alternative व exception flows भूल जाना।
  • हर scenario का source न लिखना, जिससे coverage जाँचा नहीं जा सकता और बदलाव trace नहीं होते।
  • Requirement में न दिया गया expected result पूछने की बजाय अंदाज़े से तय कर लेना।
  • 100% scenario coverage को testing पूरी होने का सबूत मान लेना।

QA का नज़रिया

Story refinement के लिए तैयार होते ही scenarios का draft बनाएँ और product owner व किसी developer के साथ उन्हें ज़ोर से पढ़ें: business के लोग गलत scenario सेकंडों में ठीक कर देते हैं, और developers ऐसे exception flows जोड़ते हैं जिन्हें वे जानते हैं कि code संभालता है, जैसे timeouts और retries। List story पर या test management tool में रखें।

सबसे ज़्यादा risk वाले scenarios को पहले test cases में बदलें, और हर खुले सवाल का एक owner तय करें। जब कोई criterion बदलता है, तो criterion से scenario और test case तक का trace बताता है कि कौन-से tests update करने हैं। Reports में results हर scenario के हिसाब से दें: stakeholders steps की गिनती से बेहतर स्थितियों को समझते हैं।

अभ्यास

Delivery slot वाली story के scenarios निकालें

आपका काम

नीचे की story का main flow लिखें, उसके main, alternative और exception flows के लिए scenarios निकालें, और जाँचें कि हर acceptance criterion exercise होता है। जिस expected result को आप नहीं बता सकते, उसे product owner के लिए सवाल बनाएँ।

फिर अपनी list की तुलना उस list से करें जो User Story → Test Scenarios tool निकालता है।

सामग्री
GRO-40  Delivery का समय बदलना
एक customer के रूप में, मैं अपनी delivery को दूसरे time slot पर ले जाना चाहता हूँ,
ताकि जब वह पहुँचे तब घर पर कोई हो।

AC1  Delivery का समय slot शुरू होने से 2 घंटे पहले तक बदला जा सकता है।
AC2  सिर्फ़ अगले 7 दिनों के वे slots दिखाए जाते हैं जिनमें अभी जगह ख़ाली है।
AC3  पहला बदलाव free है; दूसरे पर 5.00 SAR लगते हैं।
AC4  नया slot order पर दिखता है और SMS से confirm होता है।
चरण
  1. Main flow चार से छह छोटे steps में लिखें।
  2. हर step पर दूसरे choices और क्या गलत हो सकता है, यह नोट करें।
  3. हर scenario को id, flow type और sources के साथ एक लाइन में लिखें।
  4. Scenarios को AC1 से AC4 तक map करें, फिर खुले सवाल लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Main flow: order खोलें, Change slot चुनें, कोई ख़ाली slot चुनें, confirm करें और fee हो तो भरें, नया slot देखें, SMS पाएँ।

Scenarios: TS-01 (main) पहला बदलाव, 2 घंटे से ज़्यादा पहले: free, नया slot दिखता है, SMS जाता है (AC1 से AC4)। TS-02 (alternative) दूसरा बदलाव: 5.00 SAR लगते हैं (AC3, AC4)। TS-03 (alternative) customer बिना चुने निकल जाता है। TS-04 (exception) slot से 2 घंटे से कम पहले: reject (AC1)। TS-05 (exception) अगले 7 दिनों में कोई ख़ाली slot नहीं (AC2)। TS-06 (exception) confirm से पहले चुना हुआ slot भर जाता है। TS-07 (exception) fee का payment fail हो जाता है। TS-08 (flow type Q5 के जवाब पर निर्भर) तीसरा बदलाव (AC3)।

Coverage: AC1 को TS-01 और TS-04, AC2 को TS-01 और TS-05, AC3 को TS-01, TS-02 और TS-08, AC4 को TS-01 और TS-02 exercise करते हैं, यानी 4 में से 4। TS-03, TS-06 और TS-07 सिर्फ़ flow से trace होते हैं।

सवाल: Q1 क्या slot से ठीक 2 घंटे पहले बदलाव allowed है, और किस time zone में? Q2 कोई slot ख़ाली न हो तो customer क्या देखता है? Q3 चुनने और confirm करने के बीच slot भर जाए तो क्या होता है? Q4 Fee payment fail हो तो क्या पुराना slot बना रहता है? Q5 AC3 दूसरे बदलाव पर रुक जाता है: क्या तीसरा बदलाव allowed है, और उसकी fee कितनी है?

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

क्या test scenario और Gherkin scenario एक ही हैं?

पूरी तरह नहीं। Gherkin में Scenario keyword एक concrete example शुरू करता है जो specific data के साथ Given/When/Then steps में लिखा होता है। यह test case के करीब है और अक्सर automate किया जाता है। इस lesson के scenarios एक लाइन के statements हैं जो बताते हैं कि क्या टेस्ट करना है; उनमें से एक को कई Gherkin scenarios से समझाया जा सकता है।

एक user story को कितने scenarios चाहिए?

कोई तय संख्या नहीं है। हर acceptance criterion के लिए, और नतीजा बदलने वाले हर alternative या exception flow के लिए, कम से कम एक scenario रखें। छोटी story के लिए तीन काफ़ी हो सकते हैं; जो story पैसों से जुड़ी हो या states बदलती हो, उसे ज़्यादा चाहिए। अगर list बढ़ती ही जाए, तो जाँचें कि story को split करना चाहिए या नहीं।

हमारे test management tool में scenarios के लिए कोई field नहीं है। क्या फिर भी उनकी ज़रूरत है?

हाँ, किसी न किसी रूप में। Teams अक्सर scenario के लिए folder, parent item या group title इस्तेमाल करती हैं और उसके test cases उसके नीचे रखती हैं। ज़रूरी document नहीं, review है: एक छोटी list जिसे team detailed cases लिखने से पहले छूटी हुई स्थितियों के लिए जाँच सके।

क्या मैं test cases लिखे बिना scenario चला सकता हूँ?

हाँ। अनुभवी tester scenario को exploratory testing के guide की तरह इस्तेमाल कर सकता है और testing करते हुए data और results दर्ज कर सकता है। यह कम risk वाले areas और जल्दी feedback के लिए ठीक है। Regression, audits और high-risk rules के लिए test cases लिखें, ताकि हर run repeatable हो।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • Gherkin Reference — CucumberCucumberexecutable specifications के लिए Gherkin सिंटैक्स: Feature, Rule, Scenario, Given/When/Then steps, Background, Scenario Outline और Examples।
टूल्स

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

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

किसी फ़ीचर के लिए functional, negative, security, usability और compatibility पहलुओं को कवर करने वाले उच्च-स्तरीय टेस्ट सिनेरियो जनरेट करें।

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

Requirements → टेस्ट केस

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

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

User Story → टेस्ट केस

किसी user story (As a / I want / So that) को टेम्पलेट और heuristics की मदद से संरचित टेस्ट केस में बदलें।

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

और गहराई से

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

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