मॉड्यूल 11 · यूज़र एक्सेप्टेंस टेस्टिंग

UAT सिनेरियो

Mutqan Soft QA टीम द्वारा · · 20 मिनट · मध्यम

UAT scenario असली business काम के उस हिस्से का विवरण है जिसे कोई intended user नए system में करता है, ताकि वह तय कर सके कि system उसके काम को support करता है या नहीं: काम कौन करता है, किस business situation से शुरू होता है, business की भाषा में वह क्या करता है और business को कौन-सा outcome चाहिए। उदाहरण: accounts payable clerk purchase order से match होने वाला 18,400.00 SAR का supplier invoice register करती है, finance manager उसे approve करते हैं, और वह गुरुवार के payment run में दिखता है।

इसकी शुरुआत उसी test scenario से होती है जो आपने Test Scenarios वाले lesson में सीखा, यानी एक situation और वह outcome जो मायने रखता है, लेकिन UAT में यह शब्द आम तौर पर इससे ज़्यादा कहता है: scenario में realistic data और business actions के रूप में लिखे कुछ steps भी होते हैं, ताकि user उसे tester के बिना चला सके। इससे वह end-to-end test case के क़रीब पहुँच जाता है, और कुछ teams उसे UAT script कहती हैं। इसके अलावा तीन फ़र्क हैं: यह business users के लिए लिखा जाता है और वही इसे review करते हैं, यह किसी एक function की बजाय roles और screens के पार एक business process को follow करता है, और इसका expected result field value नहीं बल्कि business outcome होता है। UAT plan ने तय किया कि कौन, कहाँ और कब टेस्ट करेगा; scenarios तय करते हैं कि वे असल में क्या करेंगे।

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

Business users आम तौर पर अपने रोज़ के काम के साथ-साथ सीमित समय के लिए UAT में शामिल होते हैं। अगर scenarios tester की भाषा में, field names और click paths के साथ लिखे हों, तो users को या तो बगल में tester चाहिए, या वे अपने काम के बारे में सोचे बिना clicks follow करते हैं: screens चेक हो जाती हैं, process नहीं। अगर scenarios सिर्फ़ आम case cover करें, तो approval limits और price tolerances जैसे rules, जिन पर business चलता है, production तक पहुँच जाते हैं और उनके owners ने उन्हें एक बार भी लागू होते नहीं देखा होता।

Tester के लिए अच्छे scenarios UAT session को evidence में बदलते हैं। हर scenario किसी process step और उन rules से trace होता है जिन्हें वह दिखाता है, इसलिए उसके results "सब ठीक लगा" जैसी आम राय की बजाय acceptance decision का आधार बन सकते हैं।

Business processes से scenarios लिखना

शुरुआत business के काम करने के तरीके से करें, screens या requirements की list से नहीं। UAT scope की हर business process लें, जैसे procure to pay (सामान order करने से supplier को भुगतान तक) या hire to retire (employee की भर्ती से उसके जाने तक), और process owner या किसी key user के साथ उसे शुरू से आख़िर तक walk through करें; key user एक अनुभवी user होता है जो उसी role के अपने साथियों का प्रतिनिधित्व करता है। हर activity क्रम से लिखें: उसे कौन-सा role करता है, वह किससे शुरू होती है, क्या बनाती है और काम आगे कहाँ जाता है, दूसरी teams और systems को handoff समेत।

फिर ordinary path के लिए एक end-to-end main scenario लिखें: काम जैसा आम दिन में आम data के साथ होता है। यह दिखाता है कि process अलग-अलग roles के पार जुड़ा हुआ चलता है। इसके बाद उन दूसरी situations के लिए variant scenarios जोड़ें जिन्हें business को भी संभालना होता है। ISTQB का Acceptance Testing syllabus इसे business process-based testing कहता है: acceptance tests business processes और उनके rules के models से निकाले जाते हैं, और process से गुज़रने वाले paths व rules के decisions को cover करते हैं।

  • Roles: वही step कोई manager करे, छुट्टी कवर करने वाला deputy करे, या कम permissions वाला नया employee करे।
  • Business data: local और foreign supplier, नया और पुराना customer, छोटा और बड़ा order।
  • Business जिन exceptions को संभालता है: rejection, correction, cancellation, return, partial delivery।
  • Calendar events: month end, year end, सरकारी छुट्टी, किसी तय तारीख़ से लागू होने वाला price change।
  • यह सब कहाँ मिलेगा: process maps, work instructions, user stories और acceptance criteria, users जिन reports पर भरोसा करते हैं, और मौजूदा system के workarounds और complaints।

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

ऐसी भाषा जिसमें business users काम कर सकें

Business user को scenario चलाने से पहले उसे पढ़कर कह पाना चाहिए "हाँ, यह मेरा काम है"। Users की अपनी शब्दावली में लिखें, और अगर वे अरबी या हिंदी में काम करते हैं तो उनकी भाषा में। Session से पहले किसी key user से wording review कराएँ: जो scenario पढ़ने वाले को उलझाए, वह UAT का सबसे कीमती समय बर्बाद करता है।

  • Title में business goal लिखें: "Order से match होने वाले supplier invoice का भुगतान", न कि "TC_AP_014 save invoice"।
  • Clicks नहीं, intent लिखें: "फ़ैसल invoice approve करते हैं", न कि "दाएँ panel में btnApprove पर click करें"। Click paths business सवाल को छिपा देते हैं और screen बदलते ही टूट जाते हैं। अगर users system में नए हैं, तो उन्हें अलग से छोटी how-to guide दें।
  • Business के terms इस्तेमाल करें: supplier, goods receipt, payment run, न कि vendor_id या "GRN record", जब तक users ख़ुद ऐसे न बोलते हों।
  • ऐसा realistic data दें जिसे users पहचानें: नाम वाला supplier, amounts, dates, और कौन-सा role व test account इस्तेमाल करना है।
  • वह expected business outcome लिखें जिसे user check कर सके: उसे क्या दिखता है, process में अगले व्यक्ति तक क्या पहुँचता है, कौन-सा document या amount बनता है।
  • हर scenario में एक business goal और कुछ ही steps रखें, और user के फ़ैसले व comments के लिए जगह छोड़ें।

Business rules को cover करना

Main scenario दिखाता है कि process एक आम case में काम करता है। लेकिन acceptance की कई समस्याएँ steps से जुड़े business rules में होती हैं: approval limits, tolerances, deadlines, eligibility, calculations और कौन क्या कर सकता है। Business rules वाले lesson में आपने देखा कि decision tables से उनके combinations कैसे cover होते हैं, और यह काम आम तौर पर system testing का होता है। UAT का मकसद अलग है: rules के owners पुष्टि करते हैं कि ये सही rules हैं और जानी-पहचानी situations में सही outcome देते हैं।

Requirements, policies और process owner से हर process step के rules इकट्ठा करें। जहाँ कोई rule outcome बदल सकता है, वहाँ बदलने वाले पक्ष पर limit के पास के realistic values के साथ एक variant scenario जोड़ें। जिस rule का एक ही outcome हो, उसे main scenario दिखा सकता है। फिर rule-to-scenario map रखें: हर rule कम से कम एक scenario में दिखे, और हर scenario उन rules के नाम लिखे जिन्हें वह दिखाता है। जिस rule का कोई scenario नहीं, वह या तो भरने लायक gap है या process owner के लिए सवाल।

  • वे situations चुनें जिनका users को सच में सामना होता है और जिनका business impact सबसे ज़्यादा है; सारे combinations आम तौर पर system testing में cover होते हैं।
  • जो rule काम रोकता या मोड़ता है, उसके दोनों पक्ष दिखाएँ: वह case जिसे वह आगे जाने देता है और वह case जिसे वह रोकता है।

आज़माएँ: डिसीज़न टेबल जनरेटर आज़माएँ: Requirements → टेस्ट केस

Worked example: supplier invoice का भुगतान

एक company नए finance system का UAT कर रही है। Procure to pay process के जिस हिस्से को यहाँ cover किया गया है, उसके चार steps हैं: accounts payable clerk supplier invoice register करती है, system उसे purchase order और goods receipt (सामान पहुँचने का record) से match करता है, finance manager उसे approve करते हैं, और weekly payment run में उसका भुगतान होता है। Process owner ने चार rules confirm किए।

नीचे पूरा लिखा main scenario UAT-01 चारों steps एक ऐसे invoice के साथ चलाता है जो हर rule पास करता है। जो rule outcome बदल सकता है, वह बदलने वाले पक्ष पर एक variant scenario जोड़ता है:

  • BR-1: invoice सिर्फ़ उसी supplier के open purchase order के against register हो सकता है। Variant UAT-02: closed order का हवाला देने वाला invoice register नहीं होता, और clerk को कारण दिखता है।
  • BR-2: purchase order से 2% से ज़्यादा वाला invoice तब तक hold पर रहता है जब तक buyer उसे resolve न करे। Variant UAT-03: 18,400.00 SAR के order के against 18,952.00 SAR का invoice, यानी 3% ज़्यादा।
  • BR-3: finance manager 50,000.00 SAR तक के invoices approve करते हैं; उससे ऊपर CFO भी approve करता है। Variant UAT-04: 50,400.00 SAR का invoice।
  • BR-4: approved invoices का भुगतान अगले गुरुवार के payment run में होता है। इसका एक ही outcome है, इसलिए variant की ज़रूरत नहीं: UAT-01 इसे दिखाता है।
Supplier invoice process: UAT-01 चारों steps एक आम invoice के साथ चलाता है, और outcome बदल सकने वाला हर rule एक variant जोड़ता है: closed order, order से 3% ज़्यादा, 50,400 SAR।
  1. Process step और role:
    1Invoice register करनाAccounts payable clerk

    आगे जाता है: BR-1: सिर्फ़ उसी supplier के open purchase order के against

    Rule का variant scenario:
    UAT-02: invoice में closed orderRegister नहीं होता; clerk को कारण दिखता है
  2. Process step और role:
    2Order और goods receipt से matchSystem; clerk result देखती है

    आगे जाता है: BR-2: order से 2% से ज़्यादा होने पर hold

    Rule का variant scenario:
    UAT-03: 18,400.00 SAR के order के against 18,952.00 SAR3% ज़्यादा: buyer के resolve करने तक hold
  3. Process step और role:
    3Approve करनाFinance manager; 50,000.00 SAR से ऊपर CFO भी

    आगे जाता है: BR-3: 50,000.00 SAR की approval limit

    Rule का variant scenario:
    UAT-04: 50,400.00 SAR का invoiceFinance manager और CFO दोनों approve करते हैं
  4. Process step और role:
    4भुगतानWeekly payment run

    आगे जाता है: BR-4: अगले गुरुवार के run में भुगतान

    Rule का variant scenario:
    कोई variant नहीं: एक ही outcomeUAT-01 इसे दिखाता है

चरण 1–4 के दौरान UAT-01, main scenario: order से match होने वाला 18,400.00 SAR का invoice हर rule के आम पक्ष पर हर step पास करता है

UAT-01  Purchase order से match होने वाले supplier invoice का भुगतान
Process: procure to pay, steps 1 से 4    दिखाए गए rules: BR-1, BR-2, BR-3, BR-4
कौन:     हुदा, accounts payable clerk; फ़ैसल, finance manager
शुरुआत:  Al-Noor Supplies को purchase order PO-5521: 40 office chairs,
         18,400.00 SAR, open; सभी 40 chairs receive हो चुकी हैं

Steps
1. हुदा, Al-Noor का invoice INV-7730 (18,400.00 SAR) PO-5521 के against register करती है।
2. हुदा invoice के लिए दिखाया गया matching result देखती है।
3. फ़ैसल approval का इंतज़ार कर रहे invoices की अपनी list से invoice approve करते हैं।
4. हुदा अगले गुरुवार का payment run खोलती है।

Expected business outcome
- Invoice order और goods receipt से match है, कोई hold नहीं।
- फ़ैसल का approval काफ़ी है: invoice CFO के पास नहीं जाता।
- Payment run में Al-Noor Supplies को INV-7730 के लिए 18,400.00 SAR का भुगतान है।

Business user का फ़ैसला: हमारे काम जैसा चलता है / remarks के साथ चलता है / नहीं चलता
Comments:

आम गलतियाँ

  • System test cases को UAT में copy करना: field-level checks और click paths जिन्हें business users परख नहीं सकते, और जिन्हें system testing पहले ही cover कर चुकी है।
  • Business process की बजाय screens या menus से scenarios लिखना, जिससे roles और systems के बीच के handoffs कभी टेस्ट नहीं होते।
  • सिर्फ़ आम दिन cover करना, जिससे approval limits, tolerances और deadlines के owners अपने rules को कभी लागू होते नहीं देखते।
  • "सही काम करता है" या "सफलतापूर्वक save हुआ" जैसे expected results लिखना, उस business outcome की बजाय जिसे user check कर सके।
  • "Test Supplier 1" और round amounts जैसा placeholder data जिसे users नहीं पहचानते, जिससे वे गलतियाँ छिप जाती हैं जो realistic data में वे तुरंत पकड़ लेते।
  • Session से पहले key user से scenarios review न कराना, और फिर पूरा session इस बहस में निकाल देना कि scenario का मतलब क्या है।

QA का नज़रिया

असली team में अक्सर tester या business analyst scenarios का draft बनाता है, और ownership business की होती है। Process walk-through से draft बनाएँ, फिर process owner और एक-दो key users के साथ छोटा review करें: क्या हर scenario उनके काम करने के तरीके से मेल खाता है, क्या rules सही हैं, क्या कोई ऐसा काम छूट गया है जो वे हर महीने करते हैं? उनके corrections अक्सर UAT तैयारी का सबसे कीमती नतीजा होते हैं, क्योंकि वे ऐसी requirements सामने लाते हैं जिन्हें किसी ने लिखा ही नहीं था।

हर scenario के लिए process step और उसके दिखाए rules, role और test account, और ज़रूरी test data record करें। Session से पहले जो data मौजूद होना चाहिए, उसे जल्दी माँगें: open purchase orders, suppliers, production जैसी set की गई approval limits। Rule-to-scenario map को UAT plan के साथ रखें, ताकि execution और sign-off के दौरान सब देख सकें कि कौन-से rules दिखाए गए और कौन-से नहीं।

अभ्यास

Expense claims के लिए UAT scenarios लिखें

आपका काम

एक company expense claims की नई process का UAT कर रही है। Employee receipts के साथ claim submit करता है, line manager उसे approve करता है, finance उसे check करता है, और salary के साथ उसका भुगतान होता है। Finance department ने नीचे दिए rules confirm किए हैं।

Main scenario पूरा, business की भाषा में लिखें। फिर variant scenarios की list बनाएँ, हर एक का title, situation और expected business outcome, और आख़िर में rule-to-scenario map दें।

सामग्री
Expense claims: finance department द्वारा confirm किए गए rules

EC-1  100.00 SAR या उससे ज़्यादा के हर item के लिए receipt ज़रूरी है।
EC-2  Line manager 3,000.00 SAR तक के claims approve करता है;
      उससे ऊपर finance director भी approve करता है।
EC-3  60 दिन से पुराने items reject होते हैं।
EC-4  कोई अपना claim ख़ुद approve नहीं करता: manager का claim उसके manager के पास जाता है।
EC-5  Approved claims का भुगतान अगली monthly salary के साथ होता है।
चरण
  1. Process steps और हर step के पीछे का role लिखें।
  2. Main scenario लिखें: title, कौन, शुरुआती situation, steps और expected business outcome।
  3. Outcome बदल सकने वाले हर rule के लिए limit के पास के realistic data के साथ एक variant जोड़ें।
  4. Rule-to-scenario map बनाएँ, जाँचें कि हर rule मौजूद है, और finance के लिए सवाल नोट करें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Process: employee receipts के साथ claim submit करता है; line manager approve करता है; finance check करता है; payroll अगली salary के साथ भुगतान करता है।

Main scenario, UAT-10 "Client lunch और taxi fare का claim"। कौन: सारा, sales executive; उमर, उसके line manager; लीना, finance officer। शुरुआत: पिछले हफ़्ते सारा ने 240.00 SAR का client lunch चुकाया, जिसकी receipt उसके पास है, और 45.00 SAR का taxi fare, जिसकी receipt नहीं है। Steps: 1. सारा दोनों items और lunch की receipt के साथ एक ही claim submit करती है। 2. उमर approval का इंतज़ार कर रहे claims की अपनी list से उसे approve करते हैं। 3. लीना उसे check करती है। 4. सारा अपनी अगली payslip खोलती है। Expected: उमर को दोनों items और receipt दिखते हैं; उनके approval के बाद claim finance director के पास गए बिना finance तक पहुँचता है; लीना उसे पूरा पाकर भुगतान के लिए आगे भेजती है; सारा की अगली payslip में 285.00 SAR expenses शामिल हैं। यह EC-1 (सिर्फ़ 240.00 वाले item की receipt), EC-2 (3,000.00 से कम, सिर्फ़ उमर), EC-3 (हाल के items) और EC-5 दिखाता है।

Variants: UAT-11, बिना receipt का 100.00 SAR का parking item: receipt attach होने तक claim submit नहीं होता (EC-1)। UAT-12, 3,200.00 SAR की conference fee: उमर के साथ finance director को भी approve करना होता है (EC-2)। UAT-13, 61 दिन पहले की तारीख़ वाला item: वह item reject होता है और कारण दिखता है (EC-3)। UAT-14, उमर अपना claim submit करते हैं: वह उनके manager के पास जाता है, कभी उनके ख़ुद के पास नहीं (EC-4)।

Rule-to-scenario map: EC-1 → UAT-10, UAT-11; EC-2 → UAT-10, UAT-12; EC-3 → UAT-10, UAT-13; EC-4 → UAT-14; EC-5 → UAT-10। हर rule कम से कम एक बार आता है।

Finance के लिए सवाल: क्या receipt न होने पर claim submit करते समय ही रुक जाना चाहिए, जैसा UAT-11 मानता है, या finance उसे बाद में लौटाए? 60 दिन submission की तारीख़ तक गिने जाते हैं या approval की तारीख़ तक? एक item reject होने पर क्या बाक़ी claim आगे बढ़ता है? Finance director की ग़ैरमौजूदगी में कौन approve करता है?

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

क्या UAT scenarios Given/When/Then में लिखे जाने चाहिए?

लिखे जा सकते हैं, अगर business users acceptance criteria से Gherkin पढ़ने के आदी हैं; उन्हीं criteria को दोबारा इस्तेमाल करने से source of truth एक ही रहता है। लेकिन कई business users को numbered steps वाला छोटा, कहानी जैसा विवरण ज़्यादा आसान लगता है। वह format चुनें जिसे आपके users बिना मदद के पढ़ सकें; syntax से ज़्यादा content मायने रखता है: role, situation, steps, business outcome और दिखाए गए rules।

UAT scenarios कौन लिखता है: testers या business users?

कोई भी, लेकिन ownership business की होनी चाहिए। अक्सर tester या business analyst process walk-through से draft बनाता है और key users उसे review करके पूरा करते हैं; कुछ organisations में users tester की मदद से ख़ुद लिखते हैं। ज़रूरी यह है कि जो लोग system accept करेंगे, वे मानें कि scenarios उनके काम को दर्शाते हैं।

मुझे कितने UAT scenarios चाहिए?

कोई तय संख्या नहीं है। Scope की हर process के लिए एक main scenario चाहिए, और उन rules व exceptions के लिए variants जो outcome बदलते हैं, business users के पास उपलब्ध समय की सीमा में। Rule-to-scenario map बताता है कि set पूरा है या नहीं; UAT plan बताता है कि वह schedule में आता है या नहीं।

क्या मैं system test cases को UAT के लिए दोबारा इस्तेमाल कर सकता हूँ?

उन्हें source की तरह इस्तेमाल करें, scenarios की तरह नहीं। वे बताते हैं कि कौन-से rules और data मौजूद हैं, लेकिन वे testers के लिए लिखे गए हैं और functions के हिसाब से बँटे हैं। ज़रूरी cases को ऐसे business scenarios के रूप में दोबारा लिखें जो process को follow करें और business outcome पर ख़त्म हों।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • Certified Tester Acceptance Testing (CT-AcT)ISTQB · 2019acceptance testing पर ISTQB का specialist पाठ्यक्रम: user, contractual और regulatory acceptance testing, alpha व beta testing, और टेस्टर product owners व business analysts के साथ कैसे काम करते हैं।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
टूल्स

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

Requirements → टेस्ट केस

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

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

डिसीज़न टेबल जनरेटर

conditions और actions से decision table बनाएँ, सभी rule संयोजन जनरेट करें और असंभव संयोजनों को समेट दें।

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

और गहराई से

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

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

इस topic से पहले