تست پذیرش کاربر (UAT) چیست؟ مراحل، مثال و Sign-off

ممکن است سیستم همهٔ تست‌های فنی را پاس کند، اما کارشناس مالی نتواند پایان روز مبلغ تسویه را با گزارش حسابداری تطبیق دهد. این الزام شاید در یک API و یک صفحه جداگانه درست باشد، ولی فرایند واقعی کسب‌وکار هنوز پذیرفتنی نیست. تست پذیرش کاربر (UAT) برای همین فاصله طراحی می‌شود: آیا کاربران/نمایندگان کسب‌وکار می‌توانند کارهای واقعی را انجام دهند و آیا خروجی برای تصمیم استقرار قابل‌قبول است؟

UAT «آخرین باگ‌گیری QA» و تضمین موفقیت بازار نیست. این راهنما مرز UAT را با System Testing، Acceptance Criteria، Sprint Review و Usability روشن می‌کند؛ سپس برنامه، سناریو، محیط، نقش‌ها، Triage و قالب Sign-off را با مثال فروشگاه ایرانی می‌سازد.

تست پذیرش کاربر (UAT) چیست؟

User Acceptance Testing یکی از شکل‌های Acceptance Testing است که روی Validation نیازهای کسب‌وکار توسط کاربران موردنظر یا نمایندگان معتبر آن‌ها تمرکز دارد. پرسش UAT این نیست که «آیا کد مطابق طراحی کار می‌کند؟»؛ پرسش این است که «آیا این راه‌حل، در فرایند و قواعد واقعی کسب‌وکار، کار لازم را به نتیجهٔ قابل‌قبول می‌رساند؟»

ISTQB CTFL 4.0.1 Acceptance Testing را سطحی برای Validation و نشان‌دادن آمادگی استقرار تعریف می‌کند. بهتر است کاربران موردنظر در آن مشارکت کنند؛ اگر دسترسی مستقیم ممکن نیست، Subject Matter Expert یا نماینده‌ای با اختیار و شناخت واقعی انتخاب می‌شود.

UAT می‌تواند این موارد را اعتبارسنجی کند:

• جریان کامل کار و نتیجهٔ کسب‌وکار؛
• قواعد، نقش‌ها، سقف‌ها و استثناهای عملیاتی؛
• گزارش، تطبیق مالی، Audit و خروجی‌های بعدی؛
• قابلیت انجام کار با داده و حجم نماینده؛
• سازگاری با رویه، آموزش و مسئولیت‌های واقعی؛
• ریسک باقیمانده و آمادگی تصمیم‌گیر برای پذیرش.

UAT با Acceptance Testing یکسان نیست

Acceptance Testing خانواده‌ای از آزمون‌هاست. نوع مناسب را از هدف پذیرش انتخاب کنید:

نوع	پرسش اصلی	اجراکننده/مالک نمونه
User Acceptance Testing	آیا کاربر/کسب‌وکار می‌تواند نیاز و فرایند واقعی را انجام دهد؟	کاربر، SME، Product/Business owner
Operational Acceptance Testing	آیا عملیات، پشتیبانی، Backup، Monitoring و Recovery آماده‌اند؟	Operations/SRE/Support
Contractual Acceptance	آیا شروط قابل‌اندازه‌گیری قرارداد تحویل شده‌اند؟	مشتری، Vendor و مسئول قرارداد
Regulatory Acceptance	آیا الزام‌های قابل‌اعمال اثبات شده‌اند؟	Compliance/Legal/نهاد صلاحیت‌دار
Alpha/Beta	محصول در گروه کنترل‌شده یا زمینهٔ واقعی چگونه عمل می‌کند؟	کاربران داخلی/خارجی منتخب

یک پروژه ممکن است چند نوع را جداگانه نیاز داشته باشد. Sign-off کسب‌وکار، آمادگی عملیات یا انطباق قراردادی را خودکار اثبات نمی‌کند.

تفاوت UAT با System Testing، Usability و Sprint Review

UAT در برابر System Testing

تست سیستم رفتار و قابلیت کل سیستم/محصول را در برابر مشخصات و ریسک‌ها می‌سنجد؛ QA و تیم فنی معمولاً پوشش عمیق مثبت، منفی و غیرکارکردی می‌سازند. UAT با Test Basis کسب‌وکاری و کاربران/نمایندگان کسب‌وکار، روی Fitness for business use و آمادگی پذیرش متمرکز است. UAT نباید جای System Testing را بگیرد یا نخستین محل کشف Smoke failure باشد.

UAT در برابر Usability Testing

UAT می‌تواند مانع کاربردپذیری کشف کند، اما مطالعهٔ Usability نیست. Usability Testing با کاربران هدف، Task، Observation و معیارهایی مانند Completion/Error/Time تجربه را ارزیابی می‌کند؛ UAT تصمیم می‌گیرد فرایند کسب‌وکار برای Scope توافق‌شده پذیرفتنی هست یا نه.

UAT در برابر Sprint Review

در Scrum Guide رسمی، Sprint Review فرصتی است که Scrum Team و ذی‌نفعان نتیجه و تغییرات محیط را بررسی و دربارهٔ ادامهٔ کار سازگار شوند. راهنمای رسمی Scrum تصریح می‌کند Review نباید دروازهٔ انتشار تلقی شود. ممکن است سازمان جلسه‌ای را هم Review و هم بخشی از UAT کند، اما هدف، شرکت‌کننده، شاهد و اختیار تصمیم باید صریح باشند. راهنمای نقش QA در Scrum تفاوت Review، DoD و Release را کامل می‌کند.

UAT در برابر Acceptance Criteria و Definition of Done

Acceptance Criteria انتظارهای یک Story/Feature را روشن می‌کند؛ Definition of Done معیار کیفیت Increment را. UAT فرایندها و نتایج کسب‌وکار را در Scope پذیرش اعتبارسنجی می‌کند. معیارهای خوب، نیاز UAT را کوچک‌تر و هدفمندتر می‌کنند، اما لزوماً جای آن را نمی‌گیرند.

چه زمانی UAT انجام می‌شود؟

در مدل ترتیبی، یک دورهٔ رسمی UAT معمولاً پس از رسیدن Release Candidate به پایداری کافی انجام می‌شود. در مدل تکرارشونده، Validation کاربر می‌تواند از Prototype، Example mapping و Story acceptance شروع شود و UAT رسمی انتشار فقط جریان‌ها و ریسک‌های باقی‌مانده را پوشش دهد.

پس UAT نه همیشه «آخرین مرحله» است و نه باید تا پایان پروژه صبر کند. زمان آن از این عوامل می‌آید:

• ریسک تغییر و هزینهٔ بازخورد دیرهنگام؛
• دسترسی کاربران/SME و محیط؛
• نوع قرارداد یا Release governance؛
• پیچیدگی Migration و آموزش؛
• تعداد Incrementها و دفعات انتشار؛
• نیاز به Pilot، Beta یا پذیرش مرحله‌ای.

نقش‌ها و مسئولیت‌ها در UAT

نقش	مسئولیت	نباید به‌اشتباه
Business owner/Sponsor	تعریف نتیجه، اختیار Accept/Conditional/Reject و پذیرش ریسک	امضا را بدون دیدن شواهد به QA واگذار کند
Product owner/Business analyst	Test Basis، Rule، سناریو و ابهام کسب‌وکار	همهٔ کاربران را بدون SME واقعی نمایندگی کند
UAT lead	Plan، زمان‌بندی، ارتباط، Evidence و گزارش	تصمیم کسب‌وکار را یک‌نفره بگیرد
End user/SME	اجرای Task و قضاوت نتیجه در زمینهٔ واقعی	اسکریپت UI را بی‌فهم هدف فقط تیک بزند
QA/Test	تسهیل طراحی، Readiness، Traceability، Triage و Retest	UAT را به‌جای کاربران اجرا و Sign-off کند
Development	تشخیص/اصلاح، Build و Technical evidence	Observed را قبل از Triage «درخواست تغییر» بنامد
Operations/Support	محیط، Access، Monitoring، Runbook و آمادگی خدمت	OAT را با UAT یکی بداند
Security/Compliance	ریسک و الزام تخصصی قابل‌اعمال	Sign-off عمومی را جای تأیید تخصصی بگیرد

جدایی نقش‌ها به معنای دیوار نیست. ISTQB Acceptance Testing روی همکاری Business analyst/Product owner و Tester تأکید دارد؛ کیفیت سناریو از فهم مشترک هدف، Rule و Oracle می‌آید.

Test Basis مناسب UAT چیست؟

• هدف و Outcome کسب‌وکار؛
• Process map، Use case و نقش‌ها؛
• Business rule، Decision table و سقف‌ها؛
• User story و Acceptance Criteria؛
• قرارداد، سیاست داخلی و الزام قابل‌اعمال؛
• گزارش، فرم، خروجی مالی و Audit trail؛
• روند فعلی و تغییر موردانتظار؛
• دادهٔ Migration و Exceptionهای شناخته‌شده؛
• Support/Training material و SOP؛
• ریسک و Incidentهای گذشته.

اگر Test Basis متناقض است، کاربر را مجبور به حدس نکنید. مورد می‌تواند Requirement gap یا Policy decision باشد، نه Defect نرم‌افزار. حل این ابهام بخشی از Readiness است.

فرایند گام‌به‌گام UAT

۱. Charter و اختیار تصمیم را بنویسید

پیش از Test case، مشخص کنید چه چیزی پذیرفته می‌شود، چه کسی اختیار دارد، تصمیم‌های ممکن چیست و Scope چه چیزهایی را عمداً شامل نمی‌شود. قالب کوتاه:

• Business objective و Release/Build؛
• In scope / Out of scope؛
• Participant و Decision authority؛
• Entry/Exit و Severity policy؛
• محیط، داده و Access؛
• Schedule، Support و Communication؛
• Evidence و Retention؛
• Accept / Conditional accept / Reject / Defer.

جزئیات تخمین، ریسک و معیارها را می‌توان در Test Plan نگه داشت؛ UAT charter باید برای کاربران کسب‌وکار خواندنی بماند.

۲. کاربران و نمایندگان معتبر را انتخاب کنید

نمونه فقط بر اساس «فرد آزاد در تقویم» نباشد. نقش، تجربه، شعبه/کانال، سطح دسترسی، زبان، فناوری کمکی و سناریوی کاری را پوشش دهید. اگر SME به‌جای End user شرکت می‌کند، محدودیت نمایندگی را در گزارش بنویسید.

۳. سناریوهای کسب‌وکار را طراحی کنید

سناریوی UAT باید Task و Outcome باشد، نه فهرست Click:

نقش: کارشناس مالی فروشگاه
هدف: بازگشت وجه بخشی از سفارش مرجوعی و تطبیق گزارش پایان روز
پیش‌شرط: سفارش پرداخت‌شده، یک قلم قابل‌مرجوعی، درگاه Sandbox
نتیجهٔ موردانتظار: مبلغ درست بازگردد، وضعیت سفارش/موجودی/دفتر تغییر کند، Audit و اعلان ساخته شود و گزارش پایان روز قابل‌تطبیق بماند.

جریان اصلی کافی نیست. استثناهای کسب‌وکار مانند سقف، تاریخ، نقش غیرمجاز، تکرار، دیررسیدن پاسخ و لغو را نیز اولویت‌بندی کنید. برای تبدیل سناریو به مورد قابل‌تکرار از راهنمای نوشتن تست‌کیس استفاده کنید.

۴. محیط و داده را آماده کنید

UAT باید به‌اندازهٔ لازم نماینده باشد، نه لزوماً Clone کامل Production. مشخص کنید کدام Integration واقعی، Sandbox یا Simulator است. نقش‌ها، Permission، Feature flag، Workflow، گزارش و Schedule job باید مطابق Scope باشند.

• Build/Config و Migration نسخه‌پذیر؛
• حساب‌های نقش‌محور و مستقل؛
• دادهٔ Synthetic/Masked با Ruleهای واقعی؛
• OTP/Email/SMS sink و پرداخت Sandbox؛
• Reset و Cleanup بدون اثر بر تیم دیگر؛
• Log/Trace/Audit قابل دسترس و Sanitized؛
• محدودیت محیط در گزارش تصمیم.

راهنمای محیط تست Readiness فنی و مدیریت داده تست حریم خصوصی و قابلیت بازتولید را پوشش می‌دهند. «واقعی‌بودن» دلیل استفاده از دادهٔ مشتری نیست.

۵. Dry run و آموزش کوتاه برگزار کنید

UAT lead یا QA پیش از ورود کاربران، Login، داده، Integration، Evidence و مسیر Support را Smoke می‌کند. Briefing باید هدف و نحوهٔ ثبت نتیجه را توضیح دهد، نه اینکه کاربر را به Expected answer هدایت کند.

• تفاوت Pass، Fail، Blocked و Observation؛
• روش ثبت Screenshot/Trace بدون دادهٔ حساس؛
• کانال کمک و SLA پاسخ؛
• چه چیزی Defect، Change request یا سؤال Policy است؛
• زمان و Scope هر Session.

۶. اجرا و Evidence را کنترل کنید

کاربر با نقش و دادهٔ خودش Task را انجام می‌دهد. UAT lead نتیجه، Build، Environment، Actual، Evidence و Comment را ثبت می‌کند. اگر کاربر خارج اسکریپت مانعی معنادار یافت، آن را Observation دور نریزید؛ Triage کنید.

اجرای Remote در ایران باید اتصال، VPN سازمانی، Time slot، دستگاه، OTP sink، فونت/Locale و مسیر جایگزین Evidence را از قبل آزمایش کند. اختلال زیرساخت را Fail محصول ننامید؛ Blocked با علت و مالک ثبت کنید.

۷. Triage را روزانه و چندنقشی انجام دهید

هر مورد را به یکی از دسته‌های عملی ببرید:

نوع	مثال	تصمیم
Defect	Refund مبلغ اشتباه می‌سازد	Severity، Fix، Retest، Regression
Requirement gap	Rule مالی تعریف نشده	مالک کسب‌وکار تصمیم/معیار را روشن کند
Change request	قابلیت جدید خارج از Scope توافق‌شده	Impact و Backlog/Release decision
Data/environment	حساب نقش درست ندارد	اصلاح Setup و اجرای معتبر مجدد
Training/documentation	روند درست است ولی راهنما غلط است	اصلاح SOP/Help و بازاعتبارسنجی
Policy/risk decision	استثنای فرایندی اختلاف دارد	تصمیم مرجع صلاحیت‌دار

این دسته‌بندی برای حل است، نه کاهش مصنوعی تعداد Defect. گزارش هر نقص باید اثر کسب‌وکار و دادهٔ UAT را داشته باشد؛ قالب گزارش باگ حرفه‌ای نقطهٔ شروع است.

۸. Retest، Regression و تصمیم پذیرش

Fix باید با همان نقش/داده Retest شود و ناحیهٔ اثر Regression بگیرد. سپس Business owner بر اساس Exit criteria و ریسک باقیمانده یکی از تصمیم‌ها را ثبت می‌کند:

• Accepted: معیارها برآورده و ریسک باقیمانده پذیرفتنی است.
• Conditionally accepted: موارد مشخص با مالک، Deadline، Workaround و Risk treatment باقی می‌مانند.
• Rejected: مانع/ریسک با Scope پذیرفته‌شده سازگار نیست.
• Deferred: تصمیم به دلیل Blocker بیرونی یا شاهد ناکافی عقب می‌افتد.

زمان تمام‌شده به معنای Pass نیست. اگر Coverage ناقص است، تصمیم باید «شاهد ناکافی/ریسک پذیرفته‌شده» را شفاف بگوید.

معیار ورود و خروج UAT

نمونهٔ Entry criteria

• Scope، Charter، Decision authority و Participant تأیید شده‌اند.
• Release Candidate و Configuration دقیق مستقرند.
• System Testing/Regression مرتبط وضعیت قابل‌قبول و Known issues دارد.
• Blocker شناخته‌شده برای Taskهای UAT وجود ندارد یا تصمیمش ثبت است.
• محیط، Integration، نقش، داده، Reset و Evidence آماده‌اند.
• سناریوها به Business objective/Requirement قابل‌ردیابی‌اند.
• Support، Triage، Severity و Communication آماده‌اند.

نمونهٔ Exit criteria

• سناریوهای حیاتی اجرا و نتیجهٔ معتبر دارند.
• Business processها و Ruleهای Scope پوشش قابل‌ردیابی دارند.
• Defectهای باز بر اساس اثر کسب‌وکار و Workaround ارزیابی شده‌اند.
• Blocked/Not runها و اثرشان بر تصمیم روشن‌اند.
• Fixهای لازم Retest و Regression مرتبط اجرا شده‌اند.
• محدودیت محیط، داده و نمایندگی کاربران مستند است.
• ریسک باقیمانده، Owner و تصمیم Accepted/Conditional/Rejected/Deferred ثبت شده‌اند.

درصد Pass یک ورودی است، نه تصمیم. ۹۵٪ Pass ممکن است تنها سناریوی پرداخت را Fail داشته باشد؛ ۸۰٪ Pass ممکن است موارد کم‌اولویت با تصمیم روشن باشند.

قالب UAT Test Case

ID	UAT-REFUND-03
Business objective	بازگشت وجه صحیح و تطبیق پایان روز
Role/persona	کارشناس مالی با سقف مجاز
Business risk	زیان مالی، اختلاف دفتر و شکایت مشتری
Preconditions	سفارش Paid، قلم قابل‌مرجوعی، Sandbox آماده
Data	Dataset و شناسه‌های آزمایشی نسخه‌دار
Task	مرجوعی یک قلم و تطبیق گزارش
Expected outcome	مبلغ/State/Inventory/Ledger/Audit/Notification سازگار
Evidence	Transaction ID ساختگی، Report و Trace Sanitized
Result	Pass/Fail/Blocked + Comment
Tester/date	نام نقش، تاریخ و Build

Script نباید کاربر را به مسیر UI خاص زندانی کند مگر آن مسیر خودش الزام باشد. Taskمحور بنویسید تا تفاوت میان «رسیدن به نتیجه» و «تقلید کلیک‌های نویسنده» روشن بماند.

مثال UAT فروشگاه چندفروشنده‌ای

Release شامل تغییر فرایند بازگشت وجه، تسویهٔ فروشنده و گزارش مالی است. Scope UAT:

کاربران/نقش‌ها

• کارشناس پشتیبانی برای ثبت مرجوعی؛
• انبار برای تأیید دریافت؛
• مالی برای Refund و تطبیق؛
• فروشنده برای دیدن اثر تسویه؛
• Business owner برای تصمیم پذیرش.

فرایندهای حیاتی

• مرجوعی کامل و بخشی؛
• قلم متعلق به دو فروشنده؛
• کوپن و سهم تخفیف در Refund؛
• پاسخ موفق، ناموفق، دیرهنگام و تکراری Sandbox؛
• عبور از سقف اختیار و تأیید دوم؛
• اصلاح موجودی و قابلیت فروش مجدد؛
• Ledger، Settlement و گزارش پایان روز؛
• اعلان مشتری و Audit trail.

Oracle پذیرش

«پیام موفقیت آمد» کافی نیست. باید مبلغ، وضعیت سفارش، موجودی، بدهی/بستانکاری، سهم فروشنده، Audit و گزارش با Rule مصوب هم‌خوان باشند. اگر Sandbox تأیید بانکی واقعی نمی‌دهد، این محدودیت در Sign-off نوشته و System Integration/Operational check جداگانه مالک‌دار می‌شود.

قالب Sign-off قابل‌استفاده

Release/Build: …
Scope: …
UAT period/environment: …
Participants and represented roles: …
Executed: Critical …/…؛ High …/…؛ Blocked …
Open items: ID، اثر، Workaround، Owner، Due date
Limitations: داده/Integration/دستگاه/نمونهٔ کاربر
Residual risk: …
Decision: Accepted / Conditionally accepted / Rejected / Deferred
Conditions: …
Decision authority/date: …

Sign-off نباید یک ایمیل «UAT OK» بدون Build و Scope باشد. گزارش نهایی، Known issues، Evidence و Risk decision را می‌توان با الگوی بسته‌شدن چرخه تست آرشیو کرد.

UAT در Agile و DevOps

بازخورد پذیرش را Shift left کنید:

• Three Amigos/Example mapping برای هدف و Rule پیش از توسعه؛
• Acceptance Criteria قابل‌آزمون و مثال‌های واقعی در Refinement؛
• بازبینی Prototype و Workflow با کاربران؛
• Story acceptance در Incrementهای کوچک؛
• اتوماسیون قواعد پایدار در سطح مناسب؛
• UAT رسمی سبک‌تر برای Journey، Migration و ریسک Release؛
• Pilot/Rollout و Feedback برای فرض‌هایی که پیش از انتشار کامل آزمون‌پذیر نیستند.

Continuous delivery به معنای حذف Acceptance نیست؛ زمان و شکل Evidence را تغییر می‌دهد. Release خودکار بدون Decision policy شفاف، ریسک را فقط پنهان می‌کند.

متریک‌های مفید UAT

متریک	پرسش تصمیم	هشدار
پوشش Business process/risk	کدام نتیجهٔ حیاتی شاهد ندارد؟	تعداد Test Case معادل پوشش نیست.
نتیجه به Criticality	سناریوهای حیاتی چه وضعی دارند؟	Pass rate کل اولویت را مخلوط می‌کند.
Blocked age/reason	چه مانعی شاهد را به تأخیر انداخته؟	Blocked را Fail یا Pass نکنید.
Open risk by owner	چه کسی تا چه زمان مسئول است؟	تعداد خام نقص اثر را نشان نمی‌دهد.
Triage/repair turnaround	بازخورد UAT چقدر سریع قابل‌اقدام می‌شود؟	سرعت بدون کیفیت Fix کافی نیست.
Representation coverage	کدام نقش/کانال/شعبه نماینده ندارد؟	تعداد شرکت‌کننده به‌تنهایی کفایت نیست.
Recurrence after accept	کدام Gap از UAT عبور کرده؟	هدف سرزنش کاربر/QA نیست؛ بهبود Test Basis است.

اشتباه‌های رایج UAT

• UAT به‌عنوان آخرین QA cycle: کاربران به Bug hunter تبدیل و Validation گم می‌شود.
• تضمین موفقیت محصول: UAT Scope محدود دارد و بازار/Adoption را پیش‌بینی نمی‌کند.
• انتخاب شرکت‌کنندهٔ بی‌اختیار: نتیجه Sign-off معتبر ندارد.
• اسکریپت Click-by-click: Outcome و فهم واقعی کاربر پنهان می‌شود.
• شروع روی Build ناپایدار: وقت SME صرف Smoke و Setup می‌شود.
• دادهٔ Production: حریم خصوصی و قابلیت Reset به خطر می‌افتند.
• همه‌چیز Defect: Requirement gap، Change و Training قابل‌مدیریت نمی‌شوند.
• Sprint Review مساوی UAT: هدف Empirical review با پذیرش رسمی قاطی می‌شود.
• Sign-off بر اساس درصد Pass: Critical failure و Not run پنهان می‌مانند.
• Conditional accept بدون شرط: Risk owner و Deadline وجود ندارد.
• نادیده‌گرفتن Retest: بسته‌شدن Ticket شاهد پذیرش نیست.

چک‌لیست نهایی UAT

• Business objective، Scope و Decision authority روشن‌اند.
• UAT از OAT/Contractual/Regulatory/Alpha/Beta تفکیک شده است.
• کاربران/SMEها نقش‌ها و کانال‌های مهم را نمایندگی می‌کنند.
• Entry/Exit، Severity و تصمیم‌های ممکن مصوب‌اند.
• سناریوها Taskمحور و به Process/Rule/Risk قابل‌ردیابی‌اند.
• Release Candidate، محیط، Integration، داده و Access آماده‌اند.
• Dry run، Briefing، Support و Daily triage انجام می‌شوند.
• Defect، Gap، Change، Environment و Training جدا می‌شوند.
• Fixها Retest و Regression مرتبط دارند.
• Blocked/Not run و محدودیت نمایندگی گزارش شده‌اند.
• Sign-off شامل Build، Scope، Evidence، Open item و Residual risk است.
• Decision توسط مالک مجاز Accepted/Conditional/Rejected/Deferred ثبت می‌شود.

سوالات متداول تست پذیرش کاربر

UAT به زبان ساده چیست؟

اعتبارسنجی راه‌حل توسط کاربران موردنظر یا نمایندگان معتبر کسب‌وکار است تا مشخص شود فرایندها و نتایج موردنیاز برای Scope توافق‌شده قابل‌قبول و آمادهٔ تصمیم استقرار هستند.

آیا UAT آخرین مرحله تست است؟

در مدل ترتیبی ممکن است دورهٔ رسمی نزدیک Release باشد، اما Validation پذیرش بهتر است از نیازمندی و Incrementها شروع شود. UAT رسمی نیز لزوماً آخرین فعالیت نیست؛ OAT، Regulatory check، Pilot یا Retest ممکن است باقی بماند.

چه کسی باید UAT را اجرا و Sign-off کند؟

کاربران هدف، SMEها یا نمایندگان معتبر سناریوها را اجرا می‌کنند. QA تسهیل و Evidence را منظم می‌کند. Business owner/Sponsor دارای اختیار، تصمیم پذیرش و ریسک باقیمانده را امضا می‌کند؛ نقش دقیق را Governance پروژه تعیین می‌کند.

UAT و System Testing چه تفاوتی دارند؟

System Testing رفتار و قابلیت کل سیستم را در برابر مشخصات و ریسک فنی/محصول می‌سنجد. UAT Fitness for business use و نتیجهٔ فرایند واقعی را از دید کاربر/کسب‌وکار اعتبارسنجی می‌کند. یکی جای دیگری نیست.

اگر UAT Fail شود چه می‌شود؟

ابتدا Triage کنید: Defect، Gap، Change، Data/Environment یا Training. سپس بر اساس اثر، Fix/تصمیم، Retest و Regression انجام شود. Business owner می‌تواند Release را رد، به تعویق، یا مشروط به کنترل‌های روشن بپذیرد.

منابع و یادداشت بازبینی

مرز UAT و شکل‌های Acceptance با ISTQB CTFL ۴.۰.۱ و برنامهٔ رسمی ISTQB Acceptance Testing، و مرز Sprint Review/Release با Scrum Guide جاری تطبیق داده شده است. آخرین بازبینی محتوایی: ۱۵ مرداد ۱۴۰۵. قرارداد، صنعت و Governance هر سازمان ممکن است نقش، شاهد و اختیار دیگری لازم کند.

جمع‌بندی: UAT جلسه‌ای برای تیک‌زدن چند Script نیست. Outcome و اختیار تصمیم را از ابتدا روشن کنید، کاربران معتبر را با سناریوی Taskمحور و دادهٔ امن وارد کنید، نتیجه را درست Triage کنید و Sign-off را به Build، Scope و ریسک باقیمانده وصل کنید. آن‌وقت پذیرش از یک ایمیل مبهم به تصمیمی قابل‌دفاع تبدیل می‌شود.