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

UAT एक्ज़िक्यूशन और साइन-ऑफ़

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

UAT execution user acceptance testing का वह हिस्सा है जिसमें intended users release candidate पर पहले से तैयार UAT scenarios चलाते हैं, और team हर result और users का उठाया हर issue record करती है। Sign-off उसके बाद दर्ज होने वाला फ़ैसला है: business owner sessions से मिले evidence के आधार पर system को accept करता है, शर्तों के साथ accept करता है, या reject करता है।

उदाहरण: UAT की योजना वाले lesson से अलग एक company में, दस employees, managers और finance staff तीन सुबह एक UAT environment पर expense claims submit, approve और pay करते हैं। उनके उठाए नौ issues में से दो defects हैं। एक UAT के दौरान fix और retest हो जाता है; दूसरे के लिए, जिसका workaround मौजूद है, finance director दो हफ़्ते में fix की शर्त के साथ conditional acceptance पर sign करता है।

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

अच्छी तरह plan किए गए scenarios भी खराब ढंग से चले sessions में बेकार हो जाते हैं: users अपना असली काम करने की बजाय tester के पीछे चलते हैं, issues खो जाते हैं या wishes में मिल जाते हैं, और फ़ैसला impressions पर होता है। फिर product ऐसी कमियों के साथ live होता है जिन्हें business ने जानबूझकर कभी accept नहीं किया।

Sign-off record सबकी रक्षा करता है। यह business को ठीक-ठीक बताता है कि उसने क्या accept किया और कौन-से risks बचे हैं, delivery team को UAT का साफ़ अंत देता है, और tester को तथ्यों वाला जवाब देता है जब बाद में कोई पूछे कि release को ready किसने माना।

UAT sessions चलाना

UAT session एक time-boxed हिस्सा है, अक्सर आधा दिन, जिसमें users का एक group scenarios का planned set execute करता है। पहले session से पहले UAT plan के entry criteria जाँचें: system testing अपने exit criteria पूरे कर चुकी है, और environment, accounts और data तैयार हैं। Unstable build UAT का सबसे दुर्लभ resource बर्बाद करता है: users का समय।

हर session एक ही लय में चलता है। छोटी briefing में दिन का scope, results record करने और issues उठाने का तरीका, और सवालों के जवाब कौन देगा, यह बताया जाता है। फिर users काम ख़ुद करते हैं और team observe करती और मदद करती है। आख़िर में debrief results confirm करता है, नए issues देखता है और अगला session plan करता है। अगर कोई blocking defect या environment failure ज़्यादातर scenarios रोक दे, तो users को इंतज़ार कराने की बजाय session suspend करें, और तय resumption criteria पूरे होने पर resume करें, जैसे fixed build जिसने smoke test pass कर लिया हो; दोनों तरह के criteria कैसे लिखें, यह entry और exit criteria वाला lesson बताता है।

  • Business users: scenarios execute करते हैं और तय करते हैं कि result उनके काम में मदद करता है या नहीं।
  • UAT coordinator, अक्सर test lead: schedule, results log और debrief चलाता है।
  • Facilitator के रूप में tester: observe करता है, users को जो दिखा उसे record करने में मदद करता है और issues reproduce करता है, keyboard अपने हाथ में लिए बिना।
  • Product owner या business analyst, और on call एक developer: intended behaviour के सवालों के जवाब देते हैं और environment की समस्याएँ जल्दी ठीक करते हैं।

Users जो पाते हैं उसे log और triage करना

हर observation को पहले user के शब्दों में issue के रूप में log करें, फिर तय करें कि वह क्या है। ISTQB expectation से हटी किसी भी condition को anomaly कहता है, और Foundation syllabus बताता है कि report हुई anomaly असली defect निकल सकती है या कुछ और, जैसे change request। Scenario, user, build, उसने क्या किया, क्या expect किया और क्या देखा, evidence (screenshot या record number) और उसके शब्दों में business impact लिखें। फिर tester हर confirmed defect को पूरी bug report में बदलता है।

नए issues को कम से कम रोज़ product owner और business के एक प्रतिनिधि के साथ triage करें: UAT में severity और priority business impact से तय होती हैं, इसलिए business का शामिल होना ज़रूरी है। हर issue को एक classification मिलता है:

  • Defect: system किसी agreed acceptance criterion या requirement को पूरा नहीं करता; यह defect lifecycle में जाता है।
  • Change request: system agreed तरीके से काम करता है, पर users अब कुछ अलग चाहते हैं; यह backlog या change control में जाता है, और इसकी वजह से scenario failed नहीं माना जाता।
  • Training या documentation issue: system सही है, पर users कुछ ढूँढ या समझ नहीं पाए; यह user guide या training में जाता है।
  • Environment या test data problem: गलती UAT setup में है, product में नहीं; उसे ठीक करें और scenario फिर चलाएँ, जो failed नहीं, blocked था।
  • Duplicate या सवाल: उसे original से link करें या जवाब के साथ close करें, ताकि user देख सके कि उसके issue का क्या हुआ।

फ़ैसला: accepted, conditionally accepted या rejected

UAT एक फ़ैसले के साथ ख़त्म होता है, जो UAT plan में नामित business owner वहाँ तय exit criteria के आधार पर लेता है, जैसे: हर planned scenario execute हुआ, कोई Blocker या Critical defect open नहीं, और हर acceptance criterion पूरा हुआ या किसी agreed शर्त से cover है। Tester evidence और recommendation देता है; फ़ैसला business का है।

Conditional acceptance का मतलब है कि business अभी accept करता है, पर acceptance उन बातों पर निर्भर है जो अभी होनी हैं। यह उन open defects के लिए ठीक है जिनका workaround है और असर सीमित है। टूटा हुआ critical business rule, कोई legal requirement, data integrity या security आम तौर पर इसमें नहीं आते: इनका मतलब अक्सर fix होने तक rejection होता है।

UAT में आया release सिर्फ़ दर्ज फ़ैसले से बाहर निकलता है: accepted, हर शर्त verify होने तक conditionally accepted, या rejected और नए build के साथ UAT में वापस।
ट्रांज़िशन
#सेतकEvent या फ़ैसला
1UAT मेंशुरुआतAcceptedअंतपासफ़ैसला: हर acceptance criterion पूरा; बचे issues minor और record किए हुए
2UAT मेंशुरुआतConditionally acceptedसावधानीफ़ैसला: open defects का workaround है; हर शर्त का owner, due date और check तय
3UAT मेंशुरुआतRejectedफ़ेलफ़ैसला: कोई critical criterion fail, और कोई स्वीकार्य workaround नहीं
4Rejectedफ़ेलUAT मेंशुरुआतFixes वाला नया build: confirmation और regression testing, फिर failed scenarios दोबारावैकल्पिक पथ
5Conditionally acceptedसावधानीAcceptedअंतपासहर शर्त verify हुई और उसका closure record हुआ
6Conditionally acceptedसावधानीRejectedफ़ेलकोई शर्त छूट जाती है और business owner फिर फ़ैसला करके नई तारीख़ की जगह acceptance वापस लेता हैवैकल्पिक पथ
7UAT मेंशुरुआतSuspendedकोई blocking defect या environment failure ज़्यादातर scenarios रोक देता हैवैकल्पिक पथ
8SuspendedUAT मेंशुरुआतResumption criteria पूरे: fixed build या restored environmentवैकल्पिक पथ

हर फ़ैसला, rejection भी, build, open issues और decision maker के नाम के साथ record होता है।

  • Accepted: हर acceptance criterion पूरा है; बचे issues minor हैं, record और planned हैं।
  • Conditionally accepted: हर शर्त issue, तब तक का workaround, owner, due date या target release, और closure कौन और कैसे verify करेगा, यह बताती है।
  • Rejected: record बताता है कि कौन-से criteria पूरे नहीं हुए और UAT resume होने से पहले क्या होना चाहिए, आम तौर पर fixes वाला नया build, confirmation और regression testing, फिर failed scenarios दोबारा।
  • Conditional acceptance अपने-आप full acceptance नहीं बनता: सारी शर्तें verify होने पर उसे record करें, और कोई शर्त छूट जाए तो business owner फिर से फ़ैसला करता है: नई तारीख़ तय करना या acceptance वापस लेना।

Sign-off evidence: record में क्या होता है

Sign-off record, चाहे document हो या किसी tool में approval, फ़ैसला और उसके पीछे के तथ्य सुरक्षित रखता है। इसमें वे मुख्य items आते हैं जो ISTQB Foundation syllabus test completion report के लिए बताता है (summary, exit criteria के आधार पर evaluation, plan से deviations, unfixed defects और बचे risks), और साथ में फ़ैसला भी। इसे ऐसे लिखें कि जो मौजूद नहीं था वह भी महीनों बाद समझ सके कि क्या accept हुआ और क्यों।

  • Identification: system, release, accept हुआ exact build, हर result किस build से आया, environment और तारीख़ें।
  • Coverage: planned, executed, passed, failed और blocked scenarios, acceptance criteria से traced, और जो test नहीं हुआ वह कारण के साथ।
  • Participants: scenarios execute करने वाले users के नाम और roles।
  • Issues: severity, priority और workaround के साथ open defects, और change requests व training items कहाँ गए।
  • Decision: outcome, हर शर्त पूरी, decision maker का नाम और role, तारीख़ और approval ख़ुद।
  • Evidence: session logs, screenshots और issue log के links, share करने से पहले personal data redact करके।

आज़माएँ: Requirements → टेस्ट केस आज़माएँ: इमेज को PDF में बदलें आज़माएँ: PDF रिडैक्ट करें

Worked example: expense-claims module का sign-off

यह example UAT की योजना वाले lesson के plan से अलग एक company और release का है। इसके finance system का release 2.3 expense claims जोड़ता है, और company के अपने UAT plan में छह acceptance criteria, 18 scenarios और तीन morning sessions (S1 से S3) हैं, जिनमें पाँच employees, दो line managers, एक finance manager और दो finance clerks शामिल हैं। फ़ैसला उसके finance director का है।

S1 में UAT-07 और UAT-08 blocked रहते हैं: managers के UAT accounts में approval rights नहीं हैं (ISS-03, test data problem)। Accounts ठीक होने पर दोनों S2 में चलते हैं, जहाँ UAT-08 को ISS-06 मिलता है, एक Critical defect: 5,000 SAR से ज़्यादा के claims finance manager का approval छोड़ देते हैं। Build rc3 इसे fix करता है; S3 में scenario confirmation testing pass करता है, और approval और payment scenarios, जिन पर fix का असर पड़ सकता है, rc3 पर, जो build live जाएगा, regression के रूप में फिर pass होते हैं।

कुल नौ issues: दो defects, एक change request, दो training items, एक data problem, दो duplicates और एक जवाब दिया गया सवाल। ISS-07 open रहता है: 5 MB से बड़ी receipt photos reject होती हैं, जबकि AC-2 10 MB तक की अनुमति देता है। Users photo compress कर सकते हैं, इसलिए QA lead conditional acceptance की recommendation देता है। Record को PDF में बदला जाता है और finance director उस पर sign करता है।

UAT sign-off record (अंश): expense claims 2.3
Builds: S1-S2 2.3.0-rc2 पर; S3 2.3.0-rc3 पर (retest और regression)
Go-live build: 2.3.0-rc3, UAT environment
Participants: 5 employees, 2 line managers, 1 finance manager, 2 finance clerks
Scenarios: 18 planned, 18 executed, 17 passed, 1 failed, 0 blocked

AC    Scenarios       Result   Evidence
AC-1  UAT-01..UAT-03  Met      session log S1
AC-2  UAT-04..UAT-06  Not met  UAT-06 failed, ISS-07 (Major)
AC-3  UAT-07..UAT-10  Met      ISS-06 (Critical) fixed in rc3, retest S3
AC-4  UAT-11..UAT-13  Met      session log S2
AC-5  UAT-14..UAT-16  Met      bank file totals checked, S2; regression S3
AC-6  UAT-17..UAT-18  Met      report exports, S3

Open: ISS-07 (Major) 5 MB से बड़ी receipt photos reject; workaround: photo compress करें
बाक़ी issues: 1 change request backlog में, 2 training items quick guide में
Decision: 2026-05-07 को, S3 के अंत में, conditionally accepted
Signed: ख़ालिद अल-हरबी, finance director
Condition: ISS-07 का fix 2.3.1 में, go-live के 2 हफ़्ते के अंदर (owner: dev lead);
           finance clerk UAT-06 फिर चलाकर verify करे; finance director closure
           confirm करे

आज़माएँ: Markdown को PDF में बदलें आज़माएँ: PDF साइन करें

आम गलतियाँ

  • UAT की जगह demo चलाना: tester scenarios चलाता है और users देखते रहते हैं, तो users का अपना judgement कभी test नहीं होता।
  • User की हर बात को defect के रूप में log करना, या जो defect नहीं है उसे चुपचाप छोड़ देना; change requests और training issues का अपना रास्ता है, और users को दिखना चाहिए कि उनके issue का क्या हुआ।
  • "बाद में fix करेंगे" जैसी अस्पष्ट शर्तें लिखना: owner, date और verification step के बिना कोई शर्त कभी close नहीं होती।
  • उस build के अलावा किसी और build का sign-off करना जो live जाएगा, या sign-off के बाद affected scenarios दोबारा चलाए बिना build बदलना।
  • "Looks fine" वाले casual email को sign-off मान लेना, या tester को business की ओर से sign करने देना; record में decision maker, build, scope और open issues साफ़ लिखे होने चाहिए।

QA का नज़रिया

UAT के दौरान tester facilitator और record का रखवाला होता है। हर session में results log और issue log current रखें, लिखें कि हर result किस build से आया, users के notes से उसी दिन पूरी bug reports लिखें, और हर नया issue product owner और business के साथ daily triage में लाएँ। Users के समय की रक्षा करें: हर session से पहले environment और data जाँचें, और कोई रुकावट आए तो जल्दी suspend करें।

अंत में sign-off record और तथ्यों पर आधारित recommendation तैयार करें: क्या cover हुआ, क्या fail हुआ, क्या अब भी open है और business के लिए उसका क्या मतलब है। Sign करने से पहले पक्का करें कि decision maker हर बचा risk समझता है, फिर हर शर्त को closure तक track और verify करें, और record को उसके evidence के साथ वहाँ रखें जहाँ auditor या team का नया सदस्य उसे ढूँढ सके।

अभ्यास

UAT issue log triage करें और फ़ैसला सुझाएँ

आपका काम

एक clinic अपने appointment-booking system का release 1.4 accept कर रहा है; फ़ैसला clinic operations manager का है। दूसरे UAT session के बाद लिखा गया नीचे का issue log इस्तेमाल करें, और मान लें कि UAT ख़त्म होने पर ISS-01 और ISS-05 अब भी open हैं।

सामग्री
Clinic booking 1.4, build 1.4.0-rc2, session S2 के बाद का UAT issue log
AC-1 booking, AC-2 cancel, AC-3 reschedule, AC-4 SMS reminder

ISS-01  UAT-03  receptionist: लौटकर आए patient की booking से दूसरा record बनता है
ISS-02  UAT-05  doctor: day view में नाम के पास patient की age चाहिए
ISS-03  UAT-02  receptionist: Cancel नहीं मिला; वह More menu के अंदर है
ISS-04  UAT-07  receptionist: SMS reminder नहीं आया; UAT patients के numbers invalid हैं
ISS-05  UAT-06  receptionist: reschedule के बाद पुराना slot blocked रहता है
ISS-06  UAT-04  receptionist: फिर दूसरा record बना, किसी और patient के लिए
चरण
  1. हर issue को classify करें: defect, change request, training या documentation issue, environment या data problem, या duplicate।
  2. हर defect के लिए severity सुझाएँ और बताएँ कि वह किस acceptance criterion को प्रभावित करता है।
  3. UAT के अंत के लिए अपने कारणों के साथ फ़ैसला recommend करें।
  4. मान लें कि बाद में ISS-01 fix और retest हो गया; ISS-05 open रहते हुए acceptance की शर्तें लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

ISS-01: defect, Critical, AC-1: लौटकर आए patient का दूसरा record बनता है, जिससे medical history बँट जाती है, और कोई भरोसेमंद workaround नहीं है। ISS-06: ISS-01 का duplicate; उसे link करें, क्योंकि दूसरे patient के साथ दिखना साबित करता है कि defect किसी एक record तक सीमित नहीं। ISS-05: defect, Major, AC-3: हर reschedule एक bookable slot गँवाता है, पर reception उसे हाथ से free कर सकता है।

ISS-02: change request (day view में age कभी required नहीं थी), backlog में जाता है। ISS-03: quick guide के लिए training item, और product owner के लिए usability note। ISS-04: test data problem; team के नियंत्रण वाले test numbers load करें और UAT-07 फिर चलाएँ, जो failed नहीं, blocked था।

फ़ैसला: जब तक ISS-01 open है, rejection, क्योंकि AC-1 patient records की integrity पर fail है और कोई workaround नहीं। Fix के बाद: UAT-03 और UAT-04 की confirmation testing, booking scenarios का regression और UAT-07 दोबारा।

ISS-05 की शर्तें: manual workaround quick guide में है और go-live से पहले reception staff को brief किया गया है; development lead fix को 1.4.1 में तय तारीख़ तक ship करता है; एक receptionist 1.4.1 पर UAT-06 फिर चलाता है; operations manager sign-off record में closure confirm करता है।

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

UAT का sign-off कौन करता है: tester या business?

UAT plan या contract में नामित business owner। Tester या QA lead record तैयार करता है और फ़ैसला recommend करता है, और कुछ organisations में यह भी confirm करता है कि record पूरा है, लेकिन business की ओर से system को कभी accept नहीं करता।

क्या conditional acceptance और known defects के साथ accept करना एक ही बात है?

पूरी तरह नहीं। System को known minor defects के साथ पूरी तरह accept किया जा सकता है, अगर वे record और planned हों। Conditional acceptance का मतलब है कि acceptance ख़ुद किसी ऐसी बात पर निर्भर है जो अभी होनी है, जैसे किसी तारीख़ तक fix, और acceptance final होने से पहले हर शर्त track और verify होती है।

क्या sign-off के लिए हाथ से किया signature ज़रूरी है?

कोई एक format ज़रूरी नहीं: signed document, test management या workflow tool में approval, या सुरक्षित रखा गया email approval, सब चल सकते हैं। ज़रूरी यह है कि उसमें decision maker, फ़ैसला, build और scope पहचाने जा सकें, और वह बाद में मिल सके। Contracts और regulated environments कोई form तय कर सकते हैं; उसका पालन करें।

अगर sign-off के बाद build बदल जाए तो?

Sign-off उसी build को cover करता है जो test हुआ। बाद के किसी भी बदलाव का impact assess करें, affected UAT scenarios और regression tests फिर चलाएँ, और उस build के live जाने से पहले result और फ़ैसले की पुष्टि record में जोड़ें।

संदर्भ

  • 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टेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • 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 रिपोर्ट।
टूल्स

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

Requirements → टेस्ट केस

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

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

इमेज को PDF में बदलें

किसी भी फ़ॉर्मेट की फ़ोटो, स्कैन और स्क्रीनशॉट एक PDF में जोड़ें, हर पेज पर एक इमेज, पूरी तरह ऑफ़लाइन।

PDF रूपांतरण

PDF रिडैक्ट करें

PDF से टेक्स्ट और इमेज स्थायी रूप से हटाएँ — काले बॉक्स खींचें और रिडैक्ट किए पेज नीचे के कंटेंट के बिना फिर से रेंडर होते हैं।

PDF सुरक्षा और गोपनीयता

Markdown को PDF में बदलें

Markdown (.md) फ़ाइलों को ब्राउज़र में PDF में बदलें: शीर्षक, सूचियाँ, तालिकाएँ, कोड ब्लॉक, उद्धरण, लिंक और चित्र एम्बेडेड फ़ॉन्ट से टाइपसेट।

PDF रूपांतरण

PDF साइन करें

अपना हस्ताक्षर बनाकर, नाम टाइप करके या इमेज अपलोड करके PDF साइन करें, फिर उसे पेज पर रखें और आकार बदलें।

PDF संपादन और एनोटेशन

और गहराई से

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

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

इस मॉड्यूल के दूसरे topics