मॉड्यूल 3 · Testing fundamentals

एक्सेप्टेंस टेस्टिंग

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

Acceptance testing वह test level है जिसका फ़ोकस यह तय करना है कि system को accept किया जाए या नहीं। System testing पूछती है कि क्या पूरा system अपनी specification पूरी करता है; acceptance testing पूछती है कि क्या वह उसे इस्तेमाल करने वाले लोगों और organisation के लिए सही है, और deploy होने के लिए तैयार है। ISTQB Foundation syllabus (CTFL v4.0) इसे validation और deployment की readiness दिखाने पर केंद्रित बताता है, जिसे आदर्श रूप से intended users करें।

उदाहरण: एक school ने online gradebook बनवाया है। Vendor के system tests pass हो चुके हैं; अब teachers एक term के realistic grades डालते हैं, office report cards print करता है और IT team backup से data restore करती है। जब ये checks contract के criteria पूरे करते हैं, तब principal system को accept करते हैं।

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

कोई system हर system test pass करके भी गलत system हो सकता है: requirement गलत समझी गई, कोई business process कभी लिखा ही नहीं गया, या product test data के साथ चलता है लेकिन असली roles, volumes और operations के साथ नहीं। Acceptance testing वह आख़िरी planned check है जो customers, staff या regulators से पहले इन gaps को पकड़ती है, जब फ़ैसले का समय बचा होता है: release करें, known issues के साथ release करें, या रुकें।

Defects ढूँढना आम तौर पर इसका मुख्य लक्ष्य नहीं है: इस stage पर बहुत सारे गंभीर defects मिलना project के लिए बड़ा risk है, और अक्सर इसका मतलब होता है कि पहले के levels से कुछ छूट गया। Tester का role भी बदलता है: result को दूसरे लोग परखते हैं, और आपका काम उन्हें testable criteria, realistic environment और भरोसेमंद evidence देना है।

Acceptance testing के रूप

ISTQB syllabus पाँच मुख्य रूप बताता है: user acceptance testing, operational acceptance testing, contractual और regulatory acceptance testing (syllabus में एक रूप, practice में दो अलग checks), alpha testing और beta testing। ये इस बात में अलग हैं कि इन्हें कौन करता है और ये किस सवाल का जवाब देते हैं। एक customer के लिए बने custom software को आम तौर पर contractual acceptance और UAT चाहिए; market के लिए बने product में, जिसके सभी भावी customers से पहले से पूछा नहीं जा सकता, आम तौर पर alpha और beta testing जुड़ती है, जबकि उसके अपने staff और business partners फिर भी UAT कर सकते हैं।

  • User acceptance testing (UAT): intended users जाँचते हैं कि वे system से अपना असली काम कर सकते हैं, अपने processes और roles के साथ और realistic data पर, असली या simulated operational environment में।
  • Operational acceptance testing (OAT): operations या system administration staff जाँचते हैं कि वे इसे चालू रख सकते हैं: backup और restore, installation और upgrade, disaster recovery, user management और monitoring।
  • Contractual acceptance testing: custom-built software को contract के acceptance criteria के against जाँचती है, जो contract sign होते समय तय होने चाहिए।
  • Regulatory acceptance testing: system को उन laws और regulations के against जाँचती है जिनका पालन उसे करना है; कभी-कभी कोई regulator results को witness या audit करता है।
  • Alpha testing: potential या existing customers, operators या कोई independent test team, developers नहीं, developing organisation की site पर product इस्तेमाल करते हैं।
  • Beta testing: customers अपनी जगह पर और अपने devices पर product इस्तेमाल करते हैं, alpha के बाद या उसके बिना, और ऐसे defects पकड़ते हैं जो उन environments से जुड़े हैं जिन्हें reproduce करना team के लिए मुश्किल है।
Acceptance testing के छह रूप साथ-साथ: हर एक को कौन करता है, वह किस सवाल का जवाब देता है और acceptance का फ़ैसला कौन लेता है, जो business का फ़ैसला है, tester का नहीं।
रूपकौन करता हैकिस सवाल का जवाब देता हैफ़ैसला कौन लेता है
User acceptance (UAT)Intended users, असली या simulated operational environment मेंक्या हम इससे अपना असली काम कर सकते हैं?Process का business owner या product owner
Operational (OAT)Operations या system administration staffक्या हम इसे चला, backup, restore और support कर सकते हैं?Head of operations या service owner
ContractualUsers या independent testersक्या यह contract के acceptance criteria पूरे करता है?Contract में नामित customer representative
RegulatoryUsers या independent testers, कभी-कभी regulator की मौजूदगी मेंक्या यह लागू laws और regulations का पालन करता है?Compliance owner, और जहाँ ज़रूरी हो वहाँ regulator या auditor
AlphaCustomers, operators या independent test team, developer की site परक्या यह development team के बाहर के लोगों के लिए काम करता है?Product owner या product manager
BetaCustomers अपनी जगह पर, अपने devices परक्या यह उन असली environments में काम करता है जिन्हें reproduce करना team के लिए मुश्किल है?Product owner या product manager

ISTQB Foundation syllabus पर आधारित, जो contractual और regulatory acceptance को एक रूप गिनता है। Decision owners हर organisation में अलग होते हैं: उन्हें test plan या contract में तय करें।

Acceptance criteria ही test basis हैं

हर acceptance test को एक test basis चाहिए जो "acceptable" का मतलब तय करे। User story के लिए यह acceptance criteria हैं: वे conditions जो implementation को stakeholders द्वारा accept होने के लिए पूरी करनी हैं। UAT users के business processes पर भी आधारित होती है, contractual acceptance contract के criteria इस्तेमाल करती है, regulatory acceptance ख़ुद regulation, और OAT operational requirements, जैसे backup और recovery procedures।

अच्छे criteria काम बनने से पहले तय होते हैं, ताकि acceptance negotiation नहीं बल्कि check हो; और वे testable होते हैं: user, developer और tester उन्हें पढ़कर एक ही verdict तक पहुँचते हैं। उन्हें rules या Given/When/Then scenarios के रूप में लिखना roadmap में आगे एक अलग lesson का विषय है; यहाँ vague criterion पहचानना सीखें।

  • Vague: "Leave balances सही से update होते हैं।" Testable: "जब manager request approve करता है, तो annual-leave balance माँगे गए working days जितना घटता है, और half day 0.5 गिना जाता है।"
  • Vague: "Backups मौजूद हैं।" Testable: "पिछली रात का backup clean server पर restore होता है और उसमें employees और requests की संख्या उतनी ही होती है जितनी backup लेते समय production में थी।"

आज़माएँ: एक्सेप्टेंस क्राइटेरिया जनरेटर आज़माएँ: AI Acceptance Criteria रिव्यूअर

Acceptance का फ़ैसला कौन लेता है

Acceptance एक फ़ैसला है, और यह उन लोगों का है जो system इस्तेमाल करने का business risk उठाते हैं, उनका नहीं जिन्होंने इसे बनाया या test किया। Testing शुरू होने से पहले हर रूप का decision maker test plan या contract में लिखें।

Outcomes ये हैं: accept; शर्तों के साथ accept, जैसे known defects जिनका workaround या fix date तय है; या reject, जब तक defects fix और retest न हों। फ़ैसले को test किए गए version, open defects और शर्तों के साथ record करें; कई teams इस record को sign-off कहती हैं।

  • UAT: process का business owner या product owner।
  • OAT: head of operations या service owner।
  • Contractual: contract में नामित customer representative।
  • Regulatory: compliance owner, और जहाँ rules माँगें वहाँ regulator या auditor भी।
  • Alpha और beta: product owner या product manager, जो general release तय करता है।
  • Tester: evidence और recommendation देता है (results, severity के साथ open defects, यानी हर defect कितना नुकसान करता है, और बचा हुआ risk), लेकिन business की ओर से कभी accept नहीं करता।

Worked example: HR leave module का acceptance

एक vendor ने एक company के HR portal के लिए leave-management module बनाया है। Contract में छह acceptance criteria हैं और HR director को accept करने वाले व्यक्ति के रूप में नामित किया गया है। यहाँ alpha या beta नहीं है: module एक customer के लिए बना है। छहों criteria contract से आते हैं, लेकिन हर criterion उस रूप में जाँचा जाता है जो उस पर फ़िट बैठता है, उन लोगों द्वारा जो उसे परखने के लिए सबसे सही हैं। तीन दिन बाद company का QA lead नीचे का record सौंपता है; उसकी decision वाली line HR director की है।

  • AC-1, AC-2 (UAT): चार HR staff और तीन line managers तीन दिन तक staging copy पर anonymised data के साथ requests submit, approve, reject और cancel करते हैं।
  • AC-3 (contractual): company की QA team, जो vendor से independent है, known balances वाले employees तैयार करती है और approval के बाद हर balance जाँचती है, half days समेत।
  • AC-4, AC-5 (OAT): IT operations पिछली रात का backup clean server पर restore करती है और payroll के nightly export को source से मिलाती है।
  • AC-6 (regulatory): HR compliance officer leave types और records को company पर लागू labour-law requirements के against जाँचता है।
Acceptance record: leave module 1.0, build 1.0.4, staging

ID     Form         Result   Evidence
AC-1   UAT          Passed   UAT-01..UAT-06
AC-2   UAT          Passed   UAT-07..UAT-10
AC-3   Contractual  Failed   DEF-112 (Major)
AC-4   OAT          Passed   OPS-01 restore log
AC-5   OAT          Passed   OPS-02 payroll export totals
AC-6   Regulatory   Passed   COMP-01 compliance checklist

Open defect: DEF-112 (Major): half-day leave 0.5 की जगह 1 दिन काटी जाती है
QA recommendation: DEF-112 का confirmation testing pass होने के बाद accept करें
Decision (HR director): conditional acceptance, fix के बाद go-live

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

आम गलतियाँ

  • Acceptance को system testing का दूसरा round मानना, users को अपने processes जाँचने देने के बजाय scripted test cases दोबारा चलाना।
  • तय और testable acceptance criteria के बिना शुरू करना, जिससे project इस बहस पर ख़त्म होता है कि वादा क्या था।
  • OAT भूल जाना: users संतुष्ट हैं, लेकिन किसी ने backup, restore, monitoring या upgrade नहीं जाँचा।
  • Unstable build या unrealistic data पर UAT शुरू करना, जिससे users का सीमित समय उन defects पर बर्बाद होता है जो system testing को पकड़ने चाहिए थे।

QA का नज़रिया

Acceptance पर tester का काम जल्दी शुरू होता है: story refinement या contract review में जाँचें कि हर criterion testable है और project को जिस भी रूप की ज़रूरत है उसका decision maker तय है। UAT से पहले environment, realistic data और user accounts तैयार करें, users की भाषा में छोटे scenarios लिखें, और पक्का करें कि build system testing pass कर चुका है।

Acceptance के दौरान lead नहीं, support करें: users को results record करने और defects report करने में मदद करें, उनके findings को product owner के साथ triage करें (defect, change request या training issue), और traceable record रखें कि कौन-सा criterion किस evidence के साथ pass हुआ। अंत में summary और साफ़ recommendation दें, और फ़ैसला test किए गए version के साथ record करें।

अभ्यास

Scheduled food orders के लिए acceptance plan करें

आपका काम

एक food-delivery company अपने app में scheduled orders जोड़ रही है: customer सात दिन आगे तक का delivery time चुनता है, restaurants orders अपने tablet app में पाते हैं और company की operations team servers चलाती है। मान लें कि एक consumer-protection rule के अनुसार payment से पहले delivery fee समेत पूरी price दिखाना ज़रूरी है। Acceptance testing plan करें।

चरण
  1. लिखें कि acceptance testing के कौन-से रूप लागू होते हैं और कौन-से नहीं, कारण के साथ।
  2. लागू होने वाले हर रूप के लिए बताएँ कि उसे कौन करता है और फ़ैसला कौन लेता है।
  3. "Scheduled orders समय पर पहुँचते हैं" को testable criterion के रूप में दोबारा लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

UAT, क्योंकि restaurant staff और support agents intended users हैं जिनका अपना काम है: restaurant staff अपने असली workflow में scheduled orders accept और तैयार करते हैं, और support agents कोई scheduled order ढूँढकर बदलते हैं। फ़ैसला feature का product owner लेता है।

OAT: operations उस job को जाँचती है जो orders restaurants को भेजता है, उसके alerts, server restart के बाद waiting orders, और rollback plan। फ़ैसला head of operations लेता है।

Regulatory: compliance या legal team जाँचती है कि payment तक जाने वाले हर रास्ते पर payment से पहले पूरी price दिखती है, और वही फ़ैसला लेती है। Contractual तभी लागू है जब restaurants या किसी partner के साथ कोई contract इस feature के criteria तय करे।

Alpha और beta, क्योंकि app market के लिए है: development team के बाहर के staff customers की तरह company की site पर order करते हैं, फिर एक शहर के customers का छोटा group इसे अपने phones पर आज़माता है। Release का फ़ैसला product owner लेता है।

Testable: "Order चुने गए delivery time से 45 मिनट पहले, एक मिनट आगे-पीछे, restaurant के tablet app में दिखता है, और customer चुना गया time confirmation screen और order history में देखता है।" यह वही जाँचता है जो system के control में है, यानी order कब भेजा जाता है, delivery rider का सफ़र नहीं। Numbers product owner चुनता है; ज़रूरी यह है कि numbers हों।

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

क्या UAT और acceptance testing एक ही हैं?

नहीं। UAT acceptance testing का एक रूप है, जिसे intended users करते हैं। Acceptance testing में operational, contractual और regulatory acceptance, और alpha व beta testing भी शामिल हैं। रोज़ की बातचीत में कई teams पूरे acceptance phase को "UAT" कहती हैं; जब फ़र्क़ मायने रखे, तो पूछें कि असल में कौन-से रूप planned हैं।

क्या testers acceptance testing करते हैं?

कभी-कभी। Contractual और regulatory acceptance testing अक्सर users या independent testers करते हैं, और alpha testing कोई independent test team चला सकती है। UAT में testers आम तौर पर तैयारी और support करते हैं, जबकि tests users चलाते हैं। हर हाल में accept करने का फ़ैसला business side का होता है।

क्या acceptance testing सिर्फ़ आख़िर में होती है?

नहीं। Iterative और agile development में stories हर iteration के दौरान अपने criteria के against accept होती हैं, और alpha या beta testing general release से पहले चल सकती है। Traditional project में go-live से पहले एक formal acceptance phase भी हो सकता है। ख़रीदे गए off-the-shelf product की acceptance testing उसके install या integrate होने पर हो सकती है।

Acceptance summary में क्या होना चाहिए?

हर acceptance criterion के results उनके evidence के साथ, open defects उनकी severity और उनसे बचे risk के साथ, और शर्तों के साथ recommendation, जैसे "एक Major defect के confirmation testing के बाद release करें"। Decision maker इसी आधार पर sign करता है; फिर fixed defects को confirmation testing और regression testing चाहिए।

संदर्भ

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

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

AI Acceptance Criteria रिव्यूअर

acceptance criteria की testability, पूर्णता और अस्पष्टता की समीक्षा करें और Mutqan AI से बेहतर लिखे गए सुझाव पाएँ।

आवश्यकता विश्लेषण AI

Requirements → टेस्ट केस

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

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

और गहराई से

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

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

इस topic से पहले