UAT की योजना
UAT planning का मतलब है user acceptance testing शुरू होने से पहले यह तय करना कि users कौन-सी business processes जाँचेंगे, कौन हिस्सा लेगा, शुरू करने से पहले क्या सच होना चाहिए, वे कौन-सा environment और data इस्तेमाल करेंगे, और कब। इसका नतीजा एक UAT plan है: acceptance test level के लिए एक छोटा test plan, जिस पर business और IT दोनों सहमत होते हैं।
उदाहरण: नए expense claims module का UAT plan accept की जाने वाली चार processes (submit, approve, pay, export), छह working days में उन्हें टेस्ट करने वाले सात users, शुरू करने की शर्त, environment और data, और फ़ैसला करने वाले finance director के नाम लिखता है।
यह क्यों ज़रूरी है
UAT में सबसे दुर्लभ चीज़ users का समय है: accountants, nurses या branch staff, जिन्हें full-time नौकरी से कुछ ही दिनों के लिए छोड़ा जाता है। Plan के बिना ये दिन missing accounts, बेमतलब data, unstable build या सवालों का जवाब देने वाले किसी व्यक्ति के न होने में बर्बाद हो जाते हैं; users आना बंद कर देते हैं, और acceptance का फ़ैसला कमज़ोर evidence पर होता है।
Tester के लिए UAT का ज़्यादातर काम planning ही है: business नतीजे को judge करता है, और QA side यह judge करना संभव बनाती है। Planning में मिली कमी की कीमत एक meeting है; UAT की पहली सुबह मिले तो हर participant का पूरा एक दिन।
Scope: business processes, screens नहीं
Scope को accept की जाने वाली business processes और उन्हें करने वाले roles के रूप में लिखें, हर process को उसके acceptance criteria से जोड़कर। "Claims screen टेस्ट करो" scope नहीं है; "employee claim submit करता है, line manager उसे approve करता है और finance pay करता है" scope है। बाद में हर process UAT scenarios बनती है, जो अगले lesson का विषय है।
UAT system testing का दूसरा round नहीं है: field validation और boundary values system level पर जाँचे जा चुके हैं। समय कम हो तो product risk से चुनें: सबसे ज़्यादा business impact वाली या सबसे ज़्यादा बदली processes पहले।
- Out of scope, साफ़ लिखा हुआ: जैसे performance, बिना बदलाव वाली reports या अगली release के features।
- कहीं और planned: operational acceptance (backup, restore, monitoring) का अपना owner है; UAT plan सिर्फ़ उसका हवाला देता है।
आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर आज़माएँ: Requirements → टेस्ट केस
Participants: business roles और QA roles
Scope के हर role के लिए participants के नाम तय करें: वे लोग जो रोज़ यह काम करते हैं, अनुभवी और नए दोनों, सिर्फ़ managers या super-users नहीं जो workarounds पहले से जानते हैं। फ़ैसला करने वाले business process owner को जोड़ें, और हर participant के manager से पक्का करें कि उसका समय मिलेगा।
ISTQB Foundation syllabus कहता है कि acceptance testing आदर्श रूप से intended users करते हैं। QA side तैयारी और support करती है, लेकिन business की तरफ़ से कभी accept नहीं करती; अगर users के पास समय न होने से testers scenarios चलाएँ, तो वह testers की ही एक और testing है, user acceptance नहीं।
- Business process owner, अक्सर product owner: scope और priorities approve करता है और acceptance का फ़ैसला करता है।
- Business users: अपने असली role में scenarios चलाते हैं और judge करते हैं कि system उनके काम में मदद करता है या नहीं।
- UAT coordinator, अक्सर QA lead (कुछ teams में business analyst): plan लिखता है, schedule और daily triage चलाता है।
- Testers: users के साथ scenarios तैयार करते हैं, environment, data और accounts तैयार करते हैं, users को support करते हैं और users के retest से पहले fixes confirm करते हैं।
- Developers और operations: defects fix करते हैं और तय builds deploy करते हैं।
Schedule: go-live से पीछे की ओर गिनें
Schedule go-live से पीछे की ओर बनाएँ, क्योंकि वह आम तौर पर तय होता है, और dates तय होते ही users का समय book करें। Business के busy periods से बचें, जैसे finance team के लिए month-end closing। अगर entry check पास न हो, तो start आगे बढ़ाएँ या scope घटाएँ; users का समय चुपचाप कम न करें।
- Preparation: environment, data, accounts और scenarios, scope तय होने के दिन से।
- Entry check: start से कुछ दिन पहले, जब तक react करने का समय बचा हो।
- पहली सुबह briefing: scope, results और defects कैसे दर्ज करें, किसे call करें।
- Daily triage के साथ execution, फिर fixes, testers का confirmation testing और users का retest।
- Sign-off, फिर release की तैयारी।
Environment, data, entry और exit criteria
UAT environment production जैसा होना चाहिए, जितना project afford कर सके: वही configuration, roles, permissions और integrations, या तय किए गए simulators। इसे system testing से अलग रखें और नए builds सिर्फ़ तय समय पर deploy करें, ताकि day 2 पर pass हुआ scenario day 3 पर चुपचाप बेकार न हो जाए।
Data users को समझ में आना चाहिए: असली जैसे employees और approval limits, और records पहले से उन states में जिनकी scenarios को ज़रूरत है, जैसे approval का इंतज़ार कर रहा claim। Masked production data को भी test data वाले lesson में बताई गई personal data protection चाहिए; synthetic data ज़्यादा सुरक्षित है, और users उसे असली जैसा बनाने में मदद कर सकते हैं। हर participant को उसका अपना account दें, shared account कभी नहीं, ताकि हर result दिखाए कि किसने किया।
Entry criteria इस तैयारी को gate बना देते हैं। ISTQB syllabus typical entry criteria को तीन groups में रखता है, जो नीचे के पहले तीन items हैं: resources की उपलब्धता, testware की उपलब्धता और test object का शुरुआती quality level। Plan में वे exit criteria भी लिखे जाते हैं जिनके आधार पर business owner UAT के अंत में फ़ैसला करेगा, और यह भी कि sessions कब suspend और कब resume होंगे:
- Initial quality: system testing के exit criteria पूरे, scope में कोई Blocker या Critical defect खुला नहीं, UAT build पर smoke test pass।
- Resources: environment और data तैयार, हर account जाँचा हुआ, participants का समय पक्का।
- Testware: acceptance criteria पर सहमति, business द्वारा reviewed scenarios, defect reporting तैयार।
- Exit criteria: हर planned scenario execute हुआ, कोई Blocker या Critical defect खुला नहीं, और हर acceptance criterion पूरा हुआ या किसी agreed शर्त से cover है।
- Suspension और resumption: कोई blocking defect या environment failure ज़्यादातर scenarios रोक दे तो session suspend करें; fixed build smoke test pass कर ले तो resume करें।
- Business पक्ष:1Scope पर सहमतिAccept होने वाली processes, roles और उनकी priority
आगे जाता है: Processes और acceptance criteria
QA पक्ष:Trace करें, सीमा तय करेंहर process उसके criteria से; out of scope लिखा हुआ - Business पक्ष:2लोगों के नाम तय करेंहर role के users और फ़ैसला करने वाला; उनका समय तय
आगे जाता है: नाम और उपलब्ध दिन
QA पक्ष:Support की योजनाCoordinator, मौजूद testers, on-call developers - Business पक्ष:3Dates तय करेंGo-live और बचने वाले busy हफ़्ते
आगे जाता है: Go-live की date
QA पक्ष:Go-live से पीछे गिनेंSign-off, fix और retest, execution, briefing, entry check - Business पक्ष:4असली काम बताएँहर process को कौन-सा data और records की कौन-सी states चाहिए
आगे जाता है: Data की ज़रूरतें और roles
QA पक्ष:Environment और data तैयार करेंProduction जैसा, stable build, protected या synthetic data, हर एक का अपना account - Business पक्ष:5तैयारी की पुष्टिScenarios reviewed, users पूरी अवधि के लिए उपलब्ध
आगे जाता है: हर entry criterion का evidence
QA पक्ष:Entry check करेंSystem testing के exit criteria पूरे, smoke test pass, accounts जाँचे हुएGateवापस जाता है: पूरा नहीं: start आगे बढ़ाएँ या scope घटाएँ
इसके बाद:UAT execution तभी शुरू होता है जब हर entry criterion पूरा हो
उदाहरण के तौर पर बँटवारा: कुछ teams में business analyst coordinate करता है, और steps समय में एक-दूसरे से मिल जाते हैं।
Worked example: expense claims का UAT plan
Expense claims module के लिए QA lead, finance director और product owner के साथ plan तैयार करता है। Days, plan approve होने के दिन से गिने गए working days हैं; go-live day 22 को है।
- Scope: receipts के साथ submit, approve या reject, pay, और accounting में nightly export। Out of scope: mileage claims (अगली release), backup और restore (operational acceptance)।
- People: तीन employees, दो line managers, दो finance officers; finance director फ़ैसला करता है; QA lead coordinate करता है।
- Environment और data: accounting system के test instance से जुड़ा; managers और approval limits के साथ 60 synthetic employees; हर status में claims; सात personal accounts।
- Entry: ऊपर के तीनों groups के criteria, day 8 को evidence के साथ जाँचे जाएँगे।
- Exit: हर planned scenario execute हुआ, कोई Blocker या Critical defect खुला नहीं, और हर acceptance criterion पूरा हुआ या finance director की मानी हुई शर्त से cover है; कोई blocking defect ज़्यादातर scenarios रोक दे तो session suspend होता है, और smoke test pass कर चुके fixed build पर resume होता है।
- Schedule: preparation days 1–10, briefing और execution days 11–16, fixes और retests 17–19, sign-off day 20, release की तैयारी day 21, सब month-end closing से दूर।
- Risk: एक finance officer days 15–16 को छुट्टी पर है, इसलिए एक नामित substitute को भी brief किया जाता है और उसे आठवाँ account दिया जाता है।
आम गलतियाँ
- Business processes और roles की जगह scope को screens के रूप में लिखना या system test suite दोहराना।
- सिर्फ़ managers या super-users को बुलाना, जिससे रोज़ काम करने वाले लोग system कभी आज़माते ही नहीं।
- ऐसा shared, unstable environment इस्तेमाल करना जहाँ नए builds कभी भी आ जाते हैं।
- Data और accounts को पहली सुबह पर छोड़ देना, या personal data की सुरक्षा के बिना production data copy करना।
- Fixes और retests के लिए समय न रखना, जिससे date सिर्फ़ scenarios छोड़कर ही पूरी होती है।
QA का नज़रिया
UAT planning तब शुरू होती है जब release date तय होती है, system testing ख़त्म होने पर नहीं। आम तौर पर QA lead plan तैयार करता है; business process owner scope, participants और dates approve करता है। जल्दी पूछें: कौन-सी processes सबसे अहम हैं, फ़ैसला कौन करेगा, कौन-से हफ़्ते business के लिए असंभव हैं, और क्या कोई production data इस्तेमाल हो सकता है।
सिर्फ़ roles नहीं, नाम और dates लिखें। Entry criteria को ऐसी checklist की तरह track करें जिसके हर item का एक owner हो, और entry check को असली फ़ैसला मानें: अगर build या data तैयार नहीं है, तो evidence के साथ बताएँ और नई start date सुझाएँ।
अभ्यास
Clinic appointment booking के UAT की योजना बनाएँ
एक clinic group online appointment booking release कर रहा है: patients website पर appointment book, change और cancel करते हैं, receptionists bookings confirm करते हैं और arrival दर्ज करते हैं, और doctors अपनी daily list देखते हैं। Go-live आज से working day 25 पर तय है; system testing day 12 को ख़त्म होनी चाहिए। Reception हर हफ़्ते के पहले working day पर सबसे busy होता है, और call-centre staff patients की भूमिका निभा सकते हैं। एक page का UAT plan लिखें।
- Scope को processes और roles के रूप में लिखें, कम से कम एक out-of-scope item के साथ।
- Participants, फ़ैसला करने वाले व्यक्ति और QA side के कामों के नाम लिखें।
- Environment और data की ज़रूरतें और entry criteria लिखें।
- Day 25 से पीछे की ओर schedule बनाएँ।
मॉडल उत्तर दिखाएँ
Scope: patients appointment book, change और cancel करते हैं; reception bookings confirm करता है और arrival दर्ज करता है; doctors दिन की list देखते हैं। Out of scope: online payment (बाद की release) और server failover (operational acceptance)।
Participants: दो branches से तीन receptionists, दो doctors, और patients बनकर दो call-centre staff। Clinic operations head फ़ैसला करता है; QA lead coordinate करता है; एक tester हर दिन users को support करता है; एक developer on call है।
Environment और data: clinic system के test instance से जुड़ा, messages सिर्फ़ test phones पर; free और full slots वाले synthetic patients और doctors के schedules; हर participant का अपना account। असली patient records health data हैं, जिसे PDPL sensitive data मानता है, और वे UAT से बाहर रहते हैं।
Entry criteria: system testing के exit criteria पूरे, booking में कोई Blocker या Critical defect खुला नहीं, smoke test pass, accounts और test phones जाँचे हुए, scenarios operations head द्वारा reviewed।
Schedule: preparation day 1 से, system testing के साथ-साथ; environment, data और accounts का readiness review day 10 को; final entry check day 13 को, system testing ख़त्म होने के बाद; briefing और execution days 14–18, receptionists के sessions हफ़्ते के पहले working day से दूर; fixes और retests 19–22; sign-off day 23; release की तैयारी day 24। System testing देर से ख़त्म हो तो scope घटाएँ या go-live आगे बढ़ाएँ, users के दिन नहीं।
अक्सर पूछे जाने वाले सवाल
UAT plan कौन लिखता है: QA या business?
आम तौर पर QA lead, test manager या business analyst इसे तैयार करता है, क्योंकि वे जानते हैं कि कौन-सी तैयारी चाहिए। Business process owner इसे approve करता है, क्योंकि scope, लोग और dates business की commitments हैं। जिस plan पर business सहमत नहीं, वह सिर्फ़ इच्छाओं की list है।
क्या UAT plan, test plan से अलग document होता है?
दोनों हो सकते हैं। बड़े project में यह अक्सर इस test level का अलग test plan होता है; छोटी या agile team में यह main test plan का एक section या team wiki का एक page हो सकता है। मायने content के हैं: scope, participants और roles, entry और exit criteria, environment, data, schedule और defects कैसे handle होंगे।
क्या UAT उसी staging environment में चल सकता है जो system testing में इस्तेमाल होता है?
हो सकता है, अगर environment production जैसा है और team UAT की अवधि के लिए उसे freeze करने पर सहमत है। Risk sharing का है: system testers किसी user के scenario के बीच fixes deploy कर दें या data reset कर दें। अगर share करें, तो rules plan में लिखें: कौन deploy करेगा, कब, और data कौन reset करेगा।
अगर users planned दिन न दे सकें तो?
इसे project risk मानें और जल्दी business process owner के सामने रखें। विकल्प हैं: scope में कम processes, छोटे sessions के साथ ज़्यादा participants, या बाद की date। Users की जगह testers लगाना इनमें नहीं है, क्योंकि UAT का मक़सद ही users का judgement है।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- Certified Tester Acceptance Testing (CT-AcT)acceptance testing पर ISTQB का specialist पाठ्यक्रम: user, contractual और regulatory acceptance testing, alpha व beta testing, और टेस्टर product owners व business analysts के साथ कैसे काम करते हैं।
- ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationटेस्ट दस्तावेज़ों के टेम्पलेट और सामग्री — test policy, strategy, plan, status व completion रिपोर्ट, incident रिपोर्ट।
- Personal Data Protection Law (English translation)व्यक्तिगत डेटा पर सऊदी कानून — टेस्ट वातावरण में असली ग्राहक रिकॉर्ड की प्रतियों के बजाय सिंथेटिक डेटा क्यों इस्तेमाल करना चाहिए।
Mutqan tools से अभ्यास करें
फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।
क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।
फ़ेक एम्प्लॉई रिकॉर्ड जनरेट करें: एम्प्लॉई id, विभाग, पद, वेतन, joining तारीख़ और manager।
सिंथेटिक टेस्ट डेटा की एक ही जगह पर फ़ैक्टरी: users, customers, companies, पते, संख्याएँ, तारीख़ें और स्ट्रिंग — JSON, CSV, SQL या XML में।
किसी तारीख़ में दिन, सप्ताह, महीने, वर्ष, घंटे और मिनट जोड़ें या घटाएँ।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।