UAT چیست؟ راهنمای کامل تست پذیرش کاربر در تست نرم افزار

ممکن است یک نرم‌افزار تمام تست‌های عملکردی و فنی موردنیاز را با موفقیت پشت سر گذاشته باشد، اما هنوز برای استفاده واقعی کسب‌وکار آماده نباشد. دلیل این موضوع این است که درست کار کردن قابلیت‌های نرم‌افزار، لزوماً به معنای برآورده شدن نیازهای واقعی کاربران و کسب‌وکار نیست.

اینجاست که UAT یا User Acceptance Testing اهمیت پیدا می‌کند. تست پذیرش کاربر یکی از فعالیت‌های مهم ارزیابی نرم‌افزار است که در آن بررسی می‌شود محصول تا چه اندازه نیازمندی‌های کسب‌وکار و انتظارات کاربران را برآورده می‌کند و آیا برای پذیرش و استفاده واقعی آماده است یا خیر.

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

در این مقاله، UAT را از دید تست نرم‌افزار بررسی می‌کنیم و با مفهوم تست پذیرش کاربر، تفاوت آن با سایر انواع تست، نقش تستر نرم‌افزار، مراحل اجرای UAT، Acceptance Criteria، سناریوها و Test Caseهای UAT، مدیریت باگ‌ها و UAT Sign-off آشنا می‌شویم. اگر می‌خواهید مفاهیم تست نرم‌افزار را به‌صورت ساختاریافته یاد بگیرید، می‌توانید مسیر آموزش تست نرم افزار را نیز دنبال کنید.

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

UAT مخفف User Acceptance Testing و به معنای تست پذیرش کاربر است.

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

تمرکز اصلی UAT روی این سؤال است:

آیا نرم‌افزاری که ساخته‌ایم همان چیزی است که کسب‌وکار و کاربر واقعاً به آن نیاز دارند؟

در تست‌های مختلف نرم‌افزار، هر مرحله ممکن است هدف متفاوتی داشته باشد. برای مثال، Functional Testing بررسی می‌کند که یک قابلیت مطابق مشخصات تعریف‌شده کار می‌کند یا خیر. اما در UAT نگاه گسترده‌تری وجود دارد و تمرکز روی فرایندهای واقعی کسب‌وکار و قابل‌پذیرش بودن محصول برای استفاده واقعی است.

UAT مخفف چیست؟

UAT کوتاه‌شده عبارت User Acceptance Testing است:

• User: کاربر
• Acceptance: پذیرش
• Testing: تست یا آزمون

به همین دلیل، UAT در فارسی معمولاً با عباراتی مانند تست پذیرش کاربر یا آزمون پذیرش کاربر شناخته می‌شود.

هدف اصلی تست UAT چیست؟

هدف اصلی UAT این است که مشخص شود نرم‌افزار از دید کسب‌وکار و کاربران موردنظر، شرایط لازم برای پذیرش را دارد یا خیر.

برخی از اهداف مهم UAT عبارت‌اند از:

• بررسی برآورده شدن نیازمندی‌های کسب‌وکار
• بررسی سناریوهای واقعی استفاده از نرم‌افزار
• شناسایی مشکلاتی که ممکن است در استفاده واقعی ایجاد شوند
• کاهش ریسک انتشار محصول نامناسب
• اطمینان از آماده بودن محصول برای پذیرش
• فراهم کردن مبنایی برای تصمیم‌گیری درباره انتشار یا پذیرش محصول

بنابراین، UAT را نباید صرفاً یک مرحله دیگر برای پیدا کردن باگ‌های فنی در نظر گرفت. هدف اصلی آن بررسی قابل‌پذیرش بودن محصول از منظر کسب‌وکار و کاربر است.

یک مثال ساده از UAT

فرض کنید یک شرکت قصد دارد یک سامانه فروش آنلاین راه‌اندازی کند.

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

مشتری باید بتواند محصول را انتخاب کند، سفارش خود را ثبت کند و هزینه آن را به صورت آنلاین پرداخت کند.

تیم توسعه قابلیت موردنظر را پیاده‌سازی کرده و تیم QA نیز تست‌های مختلفی روی آن انجام داده است.

در مرحله UAT، یک سناریوی واقعی می‌تواند شامل این مراحل باشد:

1. ورود کاربر به حساب کاربری
2. انتخاب محصول
3. افزودن محصول به سبد خرید
4. ثبت اطلاعات ارسال
5. انتخاب روش پرداخت
6. پرداخت آنلاین
7. مشاهده تأیید ثبت سفارش

در اینجا فقط بررسی نمی‌کنیم که هر دکمه یا هر API درست کار می‌کند؛ بلکه بررسی می‌کنیم کل فرایند ثبت سفارش با چیزی که کسب‌وکار انتظار دارد مطابقت دارد یا خیر.

اگر تمام مراحل طبق Acceptance Criteria مورد انتظار انجام شوند، سناریو می‌تواند با موفقیت تأیید شود. در غیر این صورت، مشکل باید بررسی و در صورت نیاز اصلاح و مجدداً تست شود.

این مثال نشان می‌دهد که UAT بیشتر از آنکه صرفاً روی یک قابلیت منفرد تمرکز داشته باشد، می‌تواند یک جریان واقعی و انتهابه‌انتها از کسب‌وکار را بررسی کند.

چرا تست UAT در توسعه نرم‌افزار اهمیت دارد؟

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

ممکن است یک قابلیت دقیقاً مطابق مستندات فنی پیاده‌سازی شده باشد، اما نیاز واقعی کاربر یا فرایند کسب‌وکار را به‌درستی پوشش ندهد. UAT با قرار دادن نرم‌افزار در سناریوهای نزدیک به استفاده واقعی، به سازمان کمک می‌کند قبل از انتشار یا پذیرش محصول، این موارد را شناسایی کند.

بررسی نیازهای واقعی کسب‌وکار

یکی از مهم‌ترین اهداف UAT این است که مشخص شود محصول ساخته‌شده با نیازمندی‌های واقعی کسب‌وکار مطابقت دارد.

برای مثال، فرض کنید در یک سیستم فروشگاهی، نیازمندی این است که پس از پرداخت موفق، سفارش مشتری ثبت شود و وضعیت آن در سیستم به‌درستی نمایش داده شود.

ممکن است تست‌های فنی نشان دهند که:

• پرداخت با موفقیت انجام می‌شود.
• API پرداخت پاسخ صحیح دریافت می‌کند.
• سفارش در پایگاه داده ذخیره می‌شود.
• صفحه نتیجه پرداخت بدون خطا نمایش داده می‌شود.

اما در UAT ممکن است مشخص شود که فرایند واقعی کسب‌وکار نیاز دارد پس از پرداخت، یک مرحله دیگر مانند تأیید سفارش یا ارسال اعلان برای واحد فروش نیز انجام شود.

در چنین شرایطی، ممکن است سیستم از نظر فنی درست کار کند، اما هنوز نیاز کسب‌وکار را به‌طور کامل برآورده نکرده باشد.

کاهش ریسک قبل از انتشار نرم‌افزار

یکی از مهم‌ترین مزایای UAT، کاهش ریسک انتشار محصولی است که پس از ورود به محیط واقعی با مشکلات جدی مواجه شود.

هرچه یک مشکل دیرتر در چرخه تولید نرم‌افزار شناسایی شود، معمولاً اصلاح و مدیریت پیامدهای آن می‌تواند دشوارتر باشد. UAT فرصتی فراهم می‌کند تا کاربران یا نمایندگان کسب‌وکار قبل از انتشار نهایی، محصول را در سناریوهای واقعی بررسی کنند.

این موضوع به‌خصوص در سیستم‌هایی که فرایندهای مهم کسب‌وکار را مدیریت می‌کنند اهمیت بیشتری دارد؛ مانند:

• سیستم‌های بانکی
• فروشگاه‌های اینترنتی
• سامانه‌های منابع انسانی
• سیستم‌های مدیریت سفارش
• نرم‌افزارهای مالی
• سامانه‌های خدمات مشتریان

اطمینان از آماده بودن محصول برای استفاده واقعی

یکی دیگر از دلایل اهمیت UAT این است که محصول فقط از منظر تیم توسعه و QA بررسی نمی‌شود.

کاربران واقعی یا نمایندگان کسب‌وکار می‌توانند نرم‌افزار را بر اساس فرایندهای کاری واقعی ارزیابی کنند.

برای مثال، ممکن است تیم QA یک قابلیت را به‌صورت موفق تست کرده باشد، اما کاربر کسب‌وکار هنگام انجام یک فرایند کامل متوجه شود که ترتیب مراحل، اطلاعات موردنیاز یا خروجی سیستم با روش کاری سازمان مطابقت ندارد.

UAT می‌تواند چنین فاصله‌ای را بین «سیستم طبق مشخصات کار می‌کند» و «سیستم برای استفاده واقعی مناسب است» مشخص کند.

کمک به تصمیم‌گیری برای پذیرش محصول

تست پذیرش کاربر(UAT) می‌تواند اطلاعات لازم برای تصمیم‌گیری درباره پذیرش محصول را در اختیار ذی‌نفعان قرار دهد.

بر اساس نتایج UAT، ممکن است یکی از این وضعیت‌ها ایجاد شود:

• محصول برای پذیرش آماده است.
• برخی مشکلات باید قبل از انتشار برطرف شوند.
• پذیرش محصول مشروط به رفع موارد مشخص است.
• محصول هنوز معیارهای پذیرش را برآورده نکرده است.

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

UAT چه تفاوتی با تست‌های فنی دارد؟

برای درک بهتر تفاوت، فرض کنیم یک قابلیت در سیستم با موفقیت پیاده‌سازی و تست شده است.

تیم QA ممکن است بررسی کند:

«آیا سیستم هنگام انجام این عملیات، نتیجه مورد انتظار را تولید می‌کند؟»

اما در UAT سؤال می‌تواند این باشد:

«آیا این عملیات همان چیزی است که کاربر برای انجام فرایند واقعی کسب‌وکار به آن نیاز دارد؟»

این تفاوت، یکی از مهم‌ترین دلایل وجود UAT در فرایند توسعه نرم‌افزار است.

در نتیجه، UAT جایگزین تست‌های QA نیست. بلکه فعالیتی با هدف متفاوت است که به تیم کمک می‌کند نرم‌افزار را از زاویه‌ای نزدیک‌تر به نیاز واقعی کسب‌وکار و کاربر ارزیابی کند.

UAT در کجای فرایند تست نرم‌افزار انجام می‌شود؟

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

به‌صورت ساده می‌توان فرایند را این‌گونه تصور کرد:

Requirements → Development → QA Testing → UAT → Release

البته این ترتیب یک الگوی کلی است و در پروژه‌های مختلف، بر اساس روش توسعه، ساختار تیم و نوع محصول ممکن است تفاوت داشته باشد.

UAT قبل از انتشار محصول

یکی از مهم‌ترین ویژگی‌های UAT این است که معمولاً قبل از انتشار نهایی محصول برای کاربران واقعی انجام می‌شود.

هدف این است که سازمان قبل از قرار گرفتن نرم‌افزار در اختیار کاربران گسترده، فرصتی برای بررسی آن از دید کسب‌وکار داشته باشد.

برای مثال، فرض کنید نسخه جدید یک سامانه فروشگاهی آماده انتشار است. تیم QA تست‌های لازم را انجام داده و مشکلات مهم برطرف شده‌اند.

در این مرحله، کاربران یا نمایندگان کسب‌وکار می‌توانند فرایندهای اصلی مانند:

• ثبت سفارش
• پرداخت
• لغو سفارش
• بازگشت کالا
• مشاهده وضعیت سفارش

را بررسی کنند.

اگر این فرایندها مطابق نیازهای کسب‌وکار عمل کنند، محصول می‌تواند به مرحله پذیرش نزدیک شود.

آیا UAT همیشه بعد از تست‌های QA انجام می‌شود؟

در بسیاری از پروژه‌ها UAT پس از تکمیل بخش اصلی تست‌های QA انجام می‌شود، اما نباید تصور کرد که UAT کاملاً از سایر فعالیت‌های تست جداست.

در پروژه‌های Agile، برای مثال، تیم می‌تواند Acceptance Criteria را از مراحل ابتدایی توسعه مشخص کند و سناریوهای پذیرش را نیز زودتر آماده کند.

بنابراین بهتر است بین این دو مفهوم تفاوت قائل شویم:

• آماده‌سازی UAT می‌تواند از مراحل ابتدایی پروژه شروع شود.
• اجرای UAT معمولاً زمانی انجام می‌شود که محصول یا قابلیت موردنظر به سطح مناسبی از آمادگی رسیده باشد.

پیش‌نیازهای اجرای UAT

برای اینکه UAT نتیجه قابل اعتمادی داشته باشد، بهتر است چند مورد از قبل آماده باشند:

• نیازمندی‌های کسب‌وکار مشخص باشند.
• Acceptance Criteria تعریف شده باشد.
• قابلیت‌های موردنظر پیاده‌سازی شده باشند.
• تست‌های ضروری QA انجام شده باشند.
• مشکلات مهم شناسایی و برطرف شده باشند.
• محیط UAT آماده باشد.
• داده‌های موردنیاز برای تست در دسترس باشند.
• کاربران یا نمایندگان کسب‌وکار مشخص شده باشند.
• سناریوهای UAT آماده باشند.

اگر این پیش‌نیازها فراهم نباشند، ممکن است UAT به جای بررسی پذیرش محصول، به مرحله‌ای برای پیدا کردن مشکلات ابتدایی نرم‌افزار تبدیل شود.

جایگاه UAT در یک مثال واقعی

فرض کنیم تیمی در حال توسعه یک فروشگاه اینترنتی است.

فرایند کلی می‌تواند به این شکل باشد:

نیازمندی کسب‌وکار

کاربر باید بتواند محصول را خریداری و هزینه آن را آنلاین پرداخت کند.

توسعه

قابلیت‌های مربوط به سبد خرید، سفارش و پرداخت پیاده‌سازی می‌شوند.

QA Testing

تیم تست عملکرد قابلیت‌ها، اعتبارسنجی‌ها، خطاها و جریان‌های مختلف را بررسی می‌کند.

UAT

نمایندگان کسب‌وکار فرایند واقعی خرید را بررسی می‌کنند و مطمئن می‌شوند که سیستم مطابق فرایند مورد انتظار سازمان عمل می‌کند.

Release

پس از برآورده شدن معیارهای پذیرش و دریافت تأیید لازم، محصول می‌تواند وارد مرحله انتشار شود.

این مثال نشان می‌دهد که UAT در واقع پلی میان تست محصول و پذیرش محصول توسط کسب‌وکار ایجاد می‌کند.

نکته مهم برای تسترهای نرم‌افزار

تستر نباید UAT را صرفاً به‌عنوان «آخرین مرحله تست» در نظر بگیرد.

نقش تستر می‌تواند از مراحل قبل شروع شود؛ برای مثال با بررسی Requirements و Acceptance Criteria، طراحی سناریوهای پذیرش، آماده‌سازی داده‌ها و محیط تست و سپس پشتیبانی از اجرای UAT.

به همین دلیل، آشنایی با UAT برای تستر نرم‌افزار فقط به معنای شناخت یک نوع تست نیست؛ بلکه به درک بهتر ارتباط بین نیازمندی، تست و نیاز واقعی کسب‌وکار کمک می‌کند.

تفاوت UAT با سایر انواع تست نرم‌افزار

UAT یکی از فعالیت‌های مهم در فرایند تست و پذیرش نرم‌افزار است، اما هدف و زاویه نگاه آن با بسیاری از تست‌های دیگر تفاوت دارد.

برای درک بهتر این موضوع، باید ببینیم هر نوع تست دقیقاً چه سؤالی را پاسخ می‌دهد.

به‌طور کلی:

• Unit Testing: آیا یک واحد کوچک از کد درست کار می‌کند؟
• Integration Testing: آیا اجزای مختلف سیستم به‌درستی با یکدیگر تعامل دارند؟
• Functional Testing: آیا قابلیت‌های سیستم مطابق نیازمندی‌های مشخص‌شده کار می‌کنند؟
• System Testing: آیا کل سیستم به‌عنوان یک مجموعه درست عمل می‌کند؟
• UAT: آیا محصول از دید کاربر و کسب‌وکار برای پذیرش و استفاده واقعی مناسب است؟

بنابراین، تفاوت اصلی UAT با بسیاری از تست‌های دیگر، هدف و دیدگاه ارزیابی است.

مقایسه UAT با سایر تست‌ها

نوع تست	تمرکز اصلی	معمولاً توسط چه کسی انجام می‌شود؟
Unit Testing	بررسی واحدهای کوچک کد	توسعه‌دهنده
Integration Testing	بررسی تعامل بین اجزای سیستم	توسعه‌دهنده / تستر
Functional Testing	بررسی عملکرد قابلیت‌ها	تستر / QA
System Testing	بررسی رفتار سیستم به‌صورت یکپارچه	تستر / QA
UAT	بررسی پذیرش محصول از دید کسب‌وکار و کاربر	کاربر / نماینده کسب‌وکار / ذی‌نفع

این تقسیم‌بندی مطلق نیست و در پروژه‌های مختلف ممکن است مسئولیت‌ها متفاوت باشند، اما برای درک تفاوت اهداف تست‌ها مناسب است.

تفاوت UAT و Functional Testing

یکی از رایج‌ترین ابهام‌ها، تفاوت بین UAT و Functional Testing است.

در Functional Testing، تمرکز اصلی روی این است که آیا یک قابلیت مطابق نیازمندی‌ها و مشخصات تعریف‌شده عمل می‌کند یا خیر.

برای مثال، در یک فروشگاه اینترنتی ممکن است تستر بررسی کند:

وقتی کاربر روی گزینه «افزودن به سبد خرید» کلیک می‌کند، آیا محصول به سبد اضافه می‌شود؟

یا:

آیا مبلغ کل سفارش بعد از اضافه شدن محصول به‌درستی محاسبه می‌شود؟

اما در UAT، نگاه می‌تواند گسترده‌تر باشد:

آیا کاربر می‌تواند فرایند خرید موردنظر کسب‌وکار را از ابتدا تا انتها با موفقیت انجام دهد؟

بنابراین Functional Testing ممکن است یک قابلیت مشخص را بررسی کند، در حالی که UAT می‌تواند یک سناریوی واقعی کسب‌وکار را ارزیابی کند.

مثال

فرض کنیم قابلیت پرداخت آنلاین در یک فروشگاه اینترنتی توسعه داده شده است.

در Functional Testing ممکن است موارد زیر بررسی شوند:

• نمایش درگاه پرداخت
• وارد کردن اطلاعات پرداخت
• پرداخت موفق
• پرداخت ناموفق
• نمایش پیام خطا
• ثبت نتیجه تراکنش

اما در UAT ممکن است سناریو به شکل زیر باشد:

انتخاب محصول → ثبت سفارش → وارد کردن اطلاعات مشتری → پرداخت → ایجاد سفارش → نمایش تأیید سفارش

در اینجا هدف فقط بررسی عملکرد درگاه پرداخت نیست؛ بلکه بررسی می‌شود که فرایند خرید مورد انتظار کسب‌وکار به‌صورت کامل قابل انجام است یا خیر.

تفاوت UAT و System Testing

System Testing معمولاً سیستم را به‌عنوان یک مجموعه یکپارچه بررسی می‌کند تا مشخص شود رفتار آن مطابق نیازمندی‌های تعریف‌شده است.

برای مثال، در یک سامانه فروشگاهی، تستر ممکن است کل جریان زیر را بررسی کند:

Login → Product Search → Cart → Checkout → Payment

در UAT نیز ممکن است همین جریان بررسی شود، اما تفاوت در هدف و زاویه ارزیابی است.

در System Testing سؤال اصلی می‌تواند این باشد:

آیا سیستم مطابق مشخصات و نیازمندی‌های تعریف‌شده عمل می‌کند؟

در UAT سؤال بیشتر به این سمت می‌رود:

آیا این فرایند برای کاربر و کسب‌وکار قابل قبول و مناسب استفاده واقعی است؟

به همین دلیل، یک سناریو ممکن است از نظر System Testing موفق باشد، اما در UAT به دلیل برآورده نکردن یک نیاز کسب‌وکار یا معیار پذیرش، پذیرفته نشود.

تفاوت UAT و Integration Testing

در Integration Testing تمرکز روی تعامل صحیح بین اجزای مختلف نرم‌افزار است.

برای مثال:

فروشگاه → سرویس پرداخت → سرویس ثبت سفارش

تستر یا توسعه‌دهنده بررسی می‌کند که این اجزا بتوانند اطلاعات را به‌درستی منتقل و پردازش کنند.

اما در UAT تمرکز روی این نیست که صرفاً ارتباط سرویس‌ها درست برقرار می‌شود؛ بلکه بررسی می‌شود که این ارتباط در یک فرایند واقعی کسب‌وکار نتیجه مورد انتظار را ایجاد می‌کند یا خیر.

برای مثال:

آیا مشتری پس از پرداخت موفق، سفارش خود را به‌درستی در سیستم مشاهده می‌کند؟

تفاوت UAT و QA Testing

یکی دیگر از اشتباهات رایج، یکی دانستن UAT و QA Testing است.

QA یک حوزه گسترده‌تر برای اطمینان از کیفیت محصول و فرایند توسعه است و فعالیت‌های مختلفی را شامل می‌شود.

در مقابل، UAT یک فعالیت مشخص با هدف بررسی پذیرش محصول است.

بنابراین:

UAT و QA Testing یک مفهوم یکسان نیستند.

تیم QA می‌تواند نقش مهمی در برنامه‌ریزی، آماده‌سازی، طراحی سناریوها، پشتیبانی از اجرا و مدیریت مشکلات UAT داشته باشد، اما تصمیم نهایی درباره پذیرش محصول معمولاً در اختیار ذی‌نفع مسئول کسب‌وکار یا مشتری است.

آیا UAT جایگزین Functional Testing است؟

خیر.

این یکی از مهم‌ترین نکاتی است که باید به خاطر داشت.

UAT نباید برای جبران تست‌های ناقص QA یا Functional Testing استفاده شود.

اگر یک قابلیت هنوز مشکلات اساسی دارد، منطقی نیست که کاربران کسب‌وکار را وارد فرایند UAT کنیم و انتظار داشته باشیم آنها مشکلات پایه‌ای نرم‌افزار را پیدا کنند.

هدف این است که قبل از شروع UAT، محصول به سطح مناسبی از کیفیت و آمادگی رسیده باشد تا کاربران بتوانند تمرکز خود را روی پذیرش محصول و سناریوهای واقعی کسب‌وکار قرار دهند.

در نتیجه می‌توان گفت:

Functional Testing بیشتر می‌پرسد: «آیا قابلیت درست کار می‌کند؟»

در حالی که:

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

هر دو سؤال مهم هستند، اما پاسخ آنها از یک زاویه به دست نمی‌آید.

چه کسی تست UAT را انجام می‌دهد؟

یکی از پرسش‌های رایج درباره UAT این است که چه کسی مسئول اجرای آن است. پاسخ به ساختار پروژه و سازمان بستگی دارد، اما در حالت کلی، UAT باید از دید کاربر، مشتری یا نماینده کسب‌وکار انجام شود؛ زیرا هدف آن بررسی قابل‌پذیرش بودن محصول برای استفاده واقعی است.

تیم QA و تسترهای نرم‌افزار نیز می‌توانند نقش مهمی در برنامه‌ریزی، آماده‌سازی و پشتیبانی از UAT داشته باشند.

نقش کاربر نهایی در UAT

کاربر نهایی کسی است که قرار است در محیط واقعی با نرم‌افزار کار کند. به همین دلیل، بازخورد او می‌تواند اطلاعات ارزشمندی درباره میزان تناسب محصول با نیازهای واقعی ارائه کند.

برای مثال، در یک سیستم مدیریت منابع انسانی، کاربران نهایی ممکن است کارکنان واحد منابع انسانی باشند. آنها بهتر از یک تستر فنی می‌دانند که فرایند ثبت مرخصی، تأیید درخواست و گزارش‌گیری باید چگونه با فرایند کاری سازمان هماهنگ باشد.

کاربر در UAT معمولاً روی مواردی مانند این تمرکز می‌کند:

• آیا انجام فرایندهای کاری ساده و قابل فهم است؟
• آیا سیستم نیازهای کاری او را پوشش می‌دهد؟
• آیا خروجی‌های سیستم برای استفاده واقعی مناسب هستند؟
• آیا فرایندهای اصلی مطابق روش کاری سازمان انجام می‌شوند؟

نقش مشتری یا نماینده کسب‌وکار

در بسیاری از پروژه‌ها، فردی که UAT را انجام می‌دهد الزاماً کاربر نهایی نیست؛ بلکه ممکن است نماینده مشتری یا کسب‌وکار باشد.

این فرد باید شناخت مناسبی از نیازمندی‌های کسب‌وکار داشته باشد و بتواند تشخیص دهد که محصول تا چه اندازه معیارهای پذیرش را برآورده کرده است.

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

نقش Product Owner در UAT

در تیم‌های Agile، Product Owner نیز ممکن است در فرایند UAT نقش داشته باشد.

Product Owner معمولاً ارتباط نزدیکی با نیازهای کسب‌وکار و Product Backlog دارد و می‌تواند در بررسی Acceptance Criteria و ارزیابی اینکه قابلیت توسعه‌یافته نیاز موردنظر را برآورده کرده است یا خیر، مشارکت کند.

با این حال، مسئولیت دقیق Product Owner در UAT به ساختار سازمان و فرایند پروژه بستگی دارد.

نقش تستر نرم‌افزار در UAT چیست؟

اگرچه UAT از دید کسب‌وکار و کاربر انجام می‌شود، تستر نرم‌افزار می‌تواند نقش بسیار مهمی در موفقیت آن داشته باشد.

نقش تستر در UAT فقط اجرای Test Case نیست. یک تستر می‌تواند از مرحله بررسی نیازمندی‌ها تا پشتیبانی از اجرای تست و بررسی مجدد مشکلات درگیر باشد.

بررسی Business Requirements

یکی از نقش‌های مهم تستر، درک درست نیازمندی‌های کسب‌وکار است.

تستر باید بداند:

• کاربر چه کاری قرار است انجام دهد؟
• هدف کسب‌وکار از این قابلیت چیست؟
• خروجی مورد انتظار چیست؟
• چه شرایطی باعث پذیرش یا رد قابلیت می‌شود؟

این شناخت به تستر کمک می‌کند سناریوهایی طراحی کند که فقط رفتار فنی سیستم را بررسی نکنند، بلکه به فرایند واقعی کسب‌وکار مرتبط باشند.

بررسی Acceptance Criteria

تستر می‌تواند Acceptance Criteria را بررسی کند و مطمئن شود که معیارهای پذیرش برای طراحی سناریوهای تست قابل استفاده هستند.

برای مثال:

Requirement:

کاربر باید بتواند سفارش خود را آنلاین پرداخت کند.

Acceptance Criteria:

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

تستر می‌تواند بر اساس این معیار، سناریوهای مناسب UAT را طراحی و بررسی کند.

طراحی سناریوهای UAT

یکی دیگر از وظایف مهم تستر می‌تواند طراحی یا آماده‌سازی سناریوهای UAT باشد.

تمرکز سناریوها بهتر است روی فرایندهای واقعی کسب‌وکار باشد.

برای مثال، به جای اینکه فقط بنویسیم:

بررسی دکمه پرداخت

می‌توان یک سناریوی کامل تعریف کرد:

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

این نوع سناریو دید بهتری نسبت به رفتار واقعی سیستم ارائه می‌دهد.

آماده‌سازی Test Data

داده‌های تست نیز می‌توانند تأثیر زیادی بر کیفیت UAT داشته باشند.

تستر می‌تواند داده‌هایی را آماده کند که برای اجرای سناریوهای واقعی موردنیاز هستند؛ برای مثال:

• کاربران تست
• محصولات
• سفارش‌ها
• اطلاعات مشتری
• داده‌های مالی
• وضعیت‌های مختلف سفارش

البته در محیط UAT باید الزامات امنیتی و سیاست‌های سازمان درباره داده‌های واقعی نیز رعایت شود.

آماده‌سازی محیط UAT

تستر یا تیم QA می‌تواند در آماده‌سازی و بررسی محیط UAT نیز نقش داشته باشد.

محیط باید تا حد امکان شرایطی نزدیک به محیط واقعی داشته باشد و سرویس‌ها و وابستگی‌های موردنیاز برای اجرای سناریوها در دسترس باشند.

قبل از شروع UAT نیز بهتر است یک بررسی اولیه یا Smoke Test انجام شود تا مشخص شود محیط برای اجرای سناریوهای پذیرش آماده است.

پشتیبانی از کاربران UAT

کاربران کسب‌وکار ممکن است با جزئیات فنی نرم‌افزار آشنا نباشند. تستر می‌تواند در زمان اجرای UAT به آنها کمک کند:

• نحوه اجرای سناریوها را توضیح دهد.
• اطلاعات لازم برای تست را فراهم کند.
• مشکلات مشاهده‌شده را بررسی کند.
• اطلاعات موردنیاز برای ثبت Defect را جمع‌آوری کند.

با این حال، تستر نباید نتیجه UAT را به جای کاربر یا کسب‌وکار تعیین کند.

ثبت و مدیریت Defectها

اگر در زمان UAT مشکلی پیدا شود، تستر می‌تواند در ثبت و مدیریت آن نقش داشته باشد.

اطلاعاتی مانند موارد زیر باید به‌صورت واضح ثبت شوند:

• شرح مشکل
• مراحل بازتولید
• نتیجه مورد انتظار
• نتیجه واقعی
• داده‌های مورد استفاده
• محیط تست
• شواهدی مانند Screenshot یا Log در صورت نیاز

بعد از رفع مشکل، تستر می‌تواند Retest را انجام دهد و بررسی کند که مشکل برطرف شده است.

پشتیبانی از گزارش نتایج UAT

در پایان، تستر یا مسئول UAT می‌تواند اطلاعات لازم برای گزارش نتایج اجرای تست را تهیه کند.

این اطلاعات می‌تواند شامل مواردی مانند:

• تعداد سناریوهای اجراشده
• تعداد سناریوهای موفق
• تعداد سناریوهای ناموفق
• Defectهای شناسایی‌شده
• وضعیت Defectها
• موارد باقی‌مانده
• محدودیت‌ها و ریسک‌های شناخته‌شده

این اطلاعات به ذی‌نفعان کمک می‌کند درباره پذیرش یا عدم پذیرش محصول تصمیم بگیرند.

آیا تستر مسئول تأیید نهایی UAT است؟

لزوماً خیر.

این نکته اهمیت زیادی دارد.

تستر می‌تواند UAT را آماده، مدیریت و پشتیبانی کند، اما تصمیم نهایی درباره پذیرش محصول معمولاً بر عهده فرد یا گروهی از ذی‌نفعان کسب‌وکار، مشتری یا صاحب محصول است.

به بیان ساده:

Tester ممکن است مسئول اجرای فرایند تست باشد، اما لزوماً مسئول تصمیم نهایی درباره پذیرش محصول نیست.

این تفاوت بین Test Result و Business Acceptance یکی از نکات مهمی است که باید در هنگام برنامه‌ریزی UAT در نظر گرفته شود.

مراحل انجام تست UAT

اجرای UAT فقط به اجرای چند Test Case محدود نمی‌شود. برای اینکه نتیجه UAT قابل اعتماد باشد، باید از قبل محدوده، معیارهای پذیرش، کاربران، محیط و سناریوهای تست مشخص شوند.

به‌طور کلی، فرایند UAT را می‌توان در مراحل زیر خلاصه کرد:

تعیین محدوده → بررسی نیازمندی‌ها → تعریف Acceptance Criteria → طراحی سناریوها → آماده‌سازی محیط و داده → اجرای تست → ثبت Defect → Retest → ارزیابی نتایج → Sign-off

در ادامه هر مرحله را بررسی می‌کنیم.

1. تعیین هدف و محدوده UAT

در اولین مرحله باید مشخص شود UAT دقیقاً قرار است چه چیزی را بررسی کند.

برای مثال، اگر نسخه جدید یک فروشگاه اینترنتی آماده شده باشد، ممکن است محدوده UAT شامل این فرایندها باشد:

• ورود کاربر
• جستجوی محصول
• افزودن محصول به سبد خرید
• ثبت سفارش
• پرداخت
• مشاهده وضعیت سفارش

در مقابل، ممکن است برخی قابلیت‌ها مانند تنظیمات داخلی سیستم یا قابلیت‌هایی که در این Release قرار نیست ارائه شوند، خارج از محدوده UAT باشند.

مشخص بودن Scope از ابتدا کمک می‌کند تیم بداند چه چیزی باید تست شود و چه چیزی خارج از محدوده است.

2. بررسی Business Requirements

در مرحله بعد، نیازمندی‌های کسب‌وکار بررسی می‌شوند.

هدف این است که مشخص شود نرم‌افزار دقیقاً قرار است چه مسئله‌ای را برای کسب‌وکار یا کاربران حل کند.

برای مثال:

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

تستر و سایر افراد درگیر UAT باید مطمئن شوند که سناریوهای پذیرش با این نیازمندی‌ها ارتباط مستقیم دارند.

3. تعریف Acceptance Criteria

پس از مشخص شدن نیازمندی‌ها، باید معیارهای پذیرش مشخص باشند.

Acceptance Criteria تعیین می‌کند یک قابلیت یا فرایند تحت چه شرایطی قابل قبول محسوب می‌شود.

برای مثال:

Requirement:

کاربر باید بتواند سفارش خود را آنلاین پرداخت کند.

Acceptance Criteria:

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

این معیارها بعداً مبنایی برای طراحی سناریوها و ارزیابی نتیجه UAT خواهند بود.

4. طراحی سناریوهای UAT

در این مرحله، سناریوهای واقعی کسب‌وکار طراحی می‌شوند.

سناریوهای UAT بهتر است به جای تمرکز روی یک جزء کوچک سیستم، فرایندهای واقعی و مهم کسب‌وکار را پوشش دهند.

برای مثال:

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

سناریو باید به‌اندازه‌ای واضح باشد که کاربر یا نماینده کسب‌وکار بتواند آن را اجرا و نتیجه را ارزیابی کند.

5. آماده‌سازی Test Data

برای اجرای سناریوها به داده‌های مناسب نیاز داریم.

برای مثال در فروشگاه اینترنتی ممکن است به این داده‌ها نیاز باشد:

• حساب کاربری تست
• محصول فعال
• موجودی محصول
• آدرس ارسال
• روش پرداخت فعال
• اطلاعات سفارش

داده‌ها باید به شکلی آماده شوند که شرایط واقعی موردنیاز سناریو را شبیه‌سازی کنند.

6. آماده‌سازی محیط UAT

محیط UAT باید برای اجرای سناریوها آماده باشد.

موارد زیر باید بررسی شوند:

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

قبل از شروع رسمی UAT می‌توان یک Smoke Test انجام داد تا مشخص شود محیط از نظر پایه‌ای قابل استفاده است.

7. اجرای سناریوهای UAT

در این مرحله کاربران یا نمایندگان کسب‌وکار سناریوهای تعیین‌شده را اجرا می‌کنند.

برای مثال:

Scenario: ثبت موفق سفارش

1. ورود به حساب کاربری
2. انتخاب محصول
3. افزودن محصول به سبد
4. ثبت آدرس
5. پرداخت
6. بررسی نتیجه سفارش

در هر مرحله، نتیجه واقعی با نتیجه مورد انتظار مقایسه می‌شود.

8. ثبت و مدیریت Defectها

اگر نتیجه واقعی با نتیجه مورد انتظار مطابقت نداشته باشد، موضوع باید بررسی شود.

برای مثال:

Expected Result:

پس از پرداخت موفق، سفارش باید ثبت شود.

Actual Result:

پرداخت موفق انجام می‌شود، اما سفارش در سیستم ایجاد نمی‌شود.

این مورد می‌تواند به‌عنوان یک Defect ثبت شود. با این حال، در UAT هر اختلافی باید ابتدا از نظر نیازمندی و معیار پذیرش بررسی شود تا مشخص شود مشکل واقعاً یک نقص نرم‌افزاری است یا ناشی از ابهام در نیازمندی، داده یا فرایند کسب‌وکار است.

تستر می‌تواند در این مرحله اطلاعات لازم برای بازتولید و بررسی مشکل را ثبت کند و سپس وضعیت آن را تا زمان رفع پیگیری کند.

9. رفع مشکل و Retest

پس از اینکه تیم توسعه مشکل را برطرف کرد، باید سناریوی مربوطه دوباره اجرا شود.

این مرحله Retest نام دارد.

مثلاً اگر مشکل ثبت نشدن سفارش بعد از پرداخت برطرف شده باشد، همان سناریو دوباره اجرا می‌شود تا مشخص شود:

آیا سفارش اکنون پس از پرداخت موفق ایجاد می‌شود؟

اگر نتیجه مورد انتظار حاصل شود، تست می‌تواند Pass شود.

در برخی موارد، علاوه بر Retest، لازم است سناریوهای مرتبط نیز دوباره بررسی شوند تا مشخص شود اصلاح انجام‌شده باعث ایجاد مشکل جدید نشده است.

10. بررسی نتایج و معیارهای پذیرش

بعد از اجرای سناریوها، نتایج باید بررسی شوند.

• سناریوهای موفق
• سناریوهای ناموفق
• Defectهای باز
• Defectهای بسته‌شده
• ریسک‌های باقی‌مانده
• Acceptance Criteria برآورده‌شده
• Acceptance Criteria برآورده‌نشده

هدف این است که مشخص شود آیا محصول معیارهای تعیین‌شده برای پذیرش را برآورده کرده است یا خیر.

11. دریافت UAT Sign-off

در آخرین مرحله، در صورتی که معیارهای پذیرش برآورده شده باشند، ذی‌نفع مسئول می‌تواند پذیرش محصول را تأیید کند.

این تأیید معمولاً با عنوان UAT Sign-off شناخته می‌شود.

Sign-off نشان می‌دهد که فرد یا گروه مسئول، بر اساس نتایج و معیارهای تعیین‌شده، محصول را برای پذیرش تأیید کرده است.

البته دریافت Sign-off به معنای آن نیست که نرم‌افزار هیچ نقصی ندارد. ممکن است برخی مشکلات کم‌اهمیت یا ریسک‌های پذیرفته‌شده همچنان وجود داشته باشند. آنچه اهمیت دارد این است که وضعیت محصول نسبت به معیارهای پذیرش و تصمیم کسب‌وکار مشخص باشد.

خلاصه مراحل UAT

اگر بخواهیم کل فرایند را در یک مسیر ساده خلاصه کنیم:

Business Requirements
↓
Acceptance Criteria
↓
UAT Scenarios
↓
Test Data & Environment
↓
UAT Execution
↓
Defect Reporting
↓
Fix & Retest
↓
Result Evaluation
↓
UAT Sign-off

این فرایند نشان می‌دهد که UAT یک فعالیت منفرد نیست، بلکه مجموعه‌ای از فعالیت‌های برنامه‌ریزی، اجرا، ارزیابی و تصمیم‌گیری برای پذیرش محصول است.

Acceptance Criteria چیست و چه نقشی در UAT دارد؟

برای اینکه بتوانیم مشخص کنیم یک قابلیت در UAT پذیرفته شده یا خیر، باید بدانیم معیار پذیرش آن چیست. این معیارها همان Acceptance Criteria هستند.

Acceptance Criteria مجموعه‌ای از شرایط و الزامات مشخص است که تعیین می‌کند یک قابلیت یا محصول چه زمانی از دید کسب‌وکار یا ذی‌نفعان قابل قبول محسوب می‌شود.

به زبان ساده:

Acceptance Criteria مشخص می‌کند برای اینکه یک قابلیت را بپذیریم، چه شرایطی باید برقرار باشد.

این معیارها نقش مهمی در UAT دارند، زیرا نتیجه تست نباید صرفاً بر اساس برداشت شخصی کاربر تعیین شود؛ بلکه باید با معیارهای مشخص و قابل بررسی مقایسه شود.

تفاوت Requirement و Acceptance Criteria

Requirement مشخص می‌کند چه چیزی موردنیاز است، در حالی که Acceptance Criteria مشخص می‌کند چه شرایطی باید برقرار باشد تا آن نیازمندی قابل قبول تلقی شود.

برای مثال:

Business Requirement:

مشتری باید بتواند از طریق وب‌سایت سفارش خود را ثبت کند.

این Requirement هدف کلی را مشخص می‌کند، اما برای ارزیابی دقیق آن به معیارهای مشخص‌تری نیاز داریم.

Acceptance Criteria:

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

حالا تیم UAT می‌تواند بر اساس این معیارها بررسی کند که آیا قابلیت موردنظر شرایط لازم برای پذیرش را دارد یا خیر.

ارتباط Acceptance Criteria با UAT

می‌توان ارتباط این مفاهیم را به شکل زیر در نظر گرفت:

Business Requirement
می‌گوید کسب‌وکار چه چیزی می‌خواهد.

↓

Acceptance Criteria
مشخص می‌کند چه شرایطی باید برای پذیرش برقرار باشد.

↓

UAT Scenario
مشخص می‌کند این شرایط را چگونه در یک فرایند واقعی بررسی کنیم.

↓

UAT Test Case
مراحل دقیق اجرای سناریو و بررسی نتیجه مورد انتظار را مشخص می‌کند.

برای مثال:

Requirement:

کاربر باید بتواند سفارش خود را پرداخت کند.

Acceptance Criteria:

پس از پرداخت موفق، سفارش ایجاد شود و شماره سفارش نمایش داده شود.

UAT Scenario:

ثبت یک سفارش و پرداخت موفق آن.

UAT Test Case:

1. ورود به حساب کاربری
2. انتخاب محصول
3. افزودن محصول به سبد
4. ثبت اطلاعات ارسال
5. انتخاب روش پرداخت
6. انجام پرداخت
7. بررسی ایجاد سفارش
8. بررسی نمایش شماره سفارش

در این حالت، Acceptance Criteria به ما می‌گوید چه چیزی باید اتفاق بیفتد و Test Case مشخص می‌کند چگونه آن را بررسی کنیم.

ویژگی‌های یک Acceptance Criteria مناسب

Acceptance Criteria بهتر است ویژگی‌هایی داشته باشد که آن را به یک معیار روشن و قابل ارزیابی تبدیل کند.

واضح باشد

معیار نباید چند برداشت مختلف ایجاد کند.

مثلاً:

سیستم باید سریع باشد.

این معیار مناسبی نیست، زیرا مشخص نیست «سریع» دقیقاً به چه معناست.

اما:

صفحه نتیجه سفارش باید حداکثر ظرف ۳ ثانیه نمایش داده شود.

معیار قابل بررسی‌تری است.

قابل تست باشد

هر Acceptance Criteria باید بتواند به یک یا چند تست تبدیل شود.

برای مثال:

کاربر باید بتواند سفارش را لغو کند.

این معیار قابل تست است، زیرا می‌توان سناریویی برای اجرای آن طراحی کرد.

قابل اندازه‌گیری باشد

هرجا ممکن است، معیار باید نتیجه مشخص و قابل ارزیابی داشته باشد.

مثلاً:

پس از پرداخت موفق، وضعیت سفارش باید به «پرداخت‌شده» تغییر کند.

این معیار را می‌توان به‌صورت مشخص بررسی کرد و نتیجه آن قابل ارزیابی است.

با نیاز کسب‌وکار مرتبط باشد

Acceptance Criteria نباید صرفاً جزئیات فنی را توصیف کند؛ بلکه باید به نتیجه مورد انتظار از قابلیت ارتباط داشته باشد.

برای مثال:

پس از پرداخت موفق، سفارش مشتری باید در سیستم ثبت شود.

این معیار از دید کسب‌وکار معنادارتر از این است که صرفاً بگوییم:

API باید پاسخ ۲۰۰ برگرداند.

ممکن است پاسخ API از نظر فنی صحیح باشد، اما در نهایت مهم است که فرایند موردنیاز کسب‌وکار به نتیجه مورد انتظار برسد.

نقش تستر در بررسی Acceptance Criteria

تستر نرم‌افزار می‌تواند Acceptance Criteria را قبل از شروع تست بررسی کند.

در این بررسی می‌توان پرسید:

• آیا معیار واضح است؟
• آیا قابل تست است؟
• آیا نتیجه مورد انتظار مشخص است؟
• آیا شرایط مرزی موردنیاز مشخص شده‌اند؟
• آیا معیار با Requirement مطابقت دارد؟
• آیا برای هر معیار می‌توان Test Case طراحی کرد؟

اگر Acceptance Criteria مبهم باشد، بهتر است قبل از شروع UAT درباره آن با Product Owner، Business Analyst یا ذی‌نفع مربوطه صحبت شود.

تبدیل Acceptance Criteria به سناریوی UAT

یکی از مهارت‌های مهم تستر این است که بتواند معیارهای پذیرش را به سناریوهای قابل اجرا تبدیل کند.

برای مثال:

Acceptance Criteria:

پس از پرداخت موفق، سفارش باید ثبت شود.

از این معیار می‌توان یک سناریوی UAT ساخت:

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

سپس Test Case مربوط به این سناریو طراحی می‌شود.

به این ترتیب، یک مسیر مشخص از نیازمندی تا تست ایجاد می‌شود:

Requirement → Acceptance Criteria → UAT Scenario → Test Case

این ارتباط باعث می‌شود تست‌ها مستقیماً به نیازهای واقعی کسب‌وکار متصل باشند.

آیا Acceptance Criteria فقط برای UAT استفاده می‌شود؟

خیر.

Acceptance Criteria می‌تواند در مراحل مختلف توسعه و تست نرم‌افزار مورد استفاده قرار گیرد و در تیم‌های Agile نیز نقش مهمی در تعریف شرایط پذیرش User Story داشته باشد.

با این حال، در UAT اهمیت ویژه‌ای پیدا می‌کند، زیرا تصمیم‌گیری درباره پذیرش محصول باید بر اساس معیارهای مشخص انجام شود.

بنابراین می‌توان گفت:

Acceptance Criteria یکی از مهم‌ترین پل‌های ارتباطی بین نیازمندی کسب‌وکار و تست پذیرش کاربر است.

سناریوی UAT چیست؟

UAT Scenario یا سناریوی تست پذیرش کاربر، یک موقعیت یا فرایند واقعی کسب‌وکار است که برای بررسی پذیرش نرم‌افزار طراحی می‌شود.

سناریوی UAT معمولاً به جای تمرکز روی یک قابلیت کوچک، یک فرایند واقعی و معنادار برای کاربر یا کسب‌وکار را بررسی می‌کند.

برای مثال، در یک فروشگاه اینترنتی، این عبارت:

بررسی عملکرد دکمه پرداخت

یک سناریوی کامل UAT محسوب نمی‌شود.

اما:

مشتری بتواند محصول را انتخاب کند، سفارش خود را ثبت کند، هزینه آن را پرداخت کند و تأییدیه سفارش را دریافت کند.

یک سناریوی مناسب‌تر برای UAT است؛ زیرا یک فرایند واقعی کسب‌وکار را پوشش می‌دهد.

هدف از طراحی UAT Scenario چیست؟

هدف اصلی سناریوی UAT این است که مشخص کند چه فرایند کسب‌وکاری باید برای پذیرش محصول بررسی شود.

یک سناریوی مناسب می‌تواند به سؤالات زیر پاسخ دهد:

• کاربر چه کاری انجام می‌دهد؟
• این فرایند چه هدفی دارد؟
• چه قابلیت‌هایی در این فرایند درگیر هستند؟
• نتیجه مورد انتظار چیست؟
• آیا فرایند مطابق نیاز کسب‌وکار انجام می‌شود؟

تمرکز روی این موارد باعث می‌شود UAT از یک مجموعه تست فنی به یک ارزیابی واقعی‌تر از محصول تبدیل شود.

تفاوت UAT Scenario و UAT Test Case چیست؟

این دو مفهوم به یکدیگر مرتبط هستند، اما یکسان نیستند.

UAT Scenario معمولاً سطح بالاتری دارد و توضیح می‌دهد چه فرایندی باید بررسی شود.

در مقابل، UAT Test Case جزئیات بیشتری دارد و مشخص می‌کند چگونه آن سناریو را اجرا و نتیجه را ارزیابی کنیم.

برای مثال:

UAT Scenario:

ثبت موفق سفارش توسط مشتری

سپس می‌توان برای آن یک Test Case طراحی کرد:

مرحله	اقدام	نتیجه مورد انتظار
1	ورود به حساب کاربری	کاربر با موفقیت وارد شود.
2	انتخاب محصول	صفحه محصول نمایش داده شود.
3	افزودن محصول به سبد	محصول در سبد قرار گیرد.
4	ثبت اطلاعات ارسال	اطلاعات با موفقیت ذخیره شود.
5	پرداخت	پرداخت با موفقیت انجام شود.
6	مشاهده سفارش	سفارش ایجاد و شماره سفارش نمایش داده شود.

بنابراین:

Scenario می‌گوید چه چیزی را بررسی کنیم؛ Test Case توضیح می‌دهد چگونه آن را بررسی کنیم.

البته نحوه استفاده از این اصطلاحات ممکن است بین تیم‌ها و ابزارهای مدیریت تست متفاوت باشد و در بعضی پروژه‌ها مرز بین آن‌ها کاملاً یکسان تعریف نشود.

چگونه یک سناریوی مناسب برای UAT طراحی کنیم؟

برای طراحی سناریوهای UAT بهتر است از نیازمندی‌های واقعی کسب‌وکار شروع کنیم.

1. فرایندهای مهم کسب‌وکار را شناسایی کنید

ابتدا مشخص کنید کدام فرایندها برای کسب‌وکار اهمیت بیشتری دارند.

در یک فروشگاه اینترنتی، برای مثال:

• ثبت سفارش
• پرداخت
• لغو سفارش
• بازگشت کالا
• پیگیری سفارش

می‌توانند فرایندهای مهم باشند.

2. سناریو را از دید کاربر تعریف کنید

سناریو باید نشان دهد کاربر در دنیای واقعی چه کاری انجام می‌دهد.

مثلاً:

مشتری می‌خواهد یک محصول را خریداری کند و پس از پرداخت، وضعیت سفارش خود را مشاهده کند.

این نوع بیان معمولاً برای UAT مناسب‌تر از توصیف‌های کاملاً فنی است.

3. سناریو را به یک هدف مشخص مرتبط کنید

هر سناریو بهتر است هدف مشخصی داشته باشد.

مثلاً:

هدف: بررسی امکان ثبت موفق سفارش پس از پرداخت آنلاین.

این هدف به تیم کمک می‌کند مشخص کند نتیجه نهایی سناریو چه چیزی باید باشد.

4. Acceptance Criteria را در نظر بگیرید

سناریو باید با معیارهای پذیرش ارتباط داشته باشد.

اگر Acceptance Criteria می‌گوید:

پس از پرداخت موفق، سفارش باید ایجاد شود.

سناریوی UAT می‌تواند این باشد:

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

در این حالت ارتباط بین Requirement، Acceptance Criteria و Scenario مشخص است.

5. مسیرهای مهم و واقعی را پوشش دهید

سناریوهای UAT نباید فقط Happy Path را پوشش دهند.

بسته به نیاز کسب‌وکار می‌توان سناریوهایی برای شرایط مختلف نیز تعریف کرد.

مثلاً در فروشگاه اینترنتی:

Happy Path:

پرداخت موفق و ثبت سفارش.

Alternative Path:

پرداخت ناموفق و بازگشت کاربر به صفحه پرداخت.

Business Exception:

موجودی محصول پس از ثبت سفارش کافی نیست.

هدف این نیست که UAT تمام حالات فنی ممکن را پوشش دهد؛ بلکه باید سناریوهای مهم از دید کسب‌وکار را پوشش دهد.

مثال کامل از طراحی سناریوی UAT

فرض کنیم Requirement سیستم این است:

مشتری باید بتواند محصول موردنظر خود را خریداری کند.

Acceptance Criteria

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

UAT Scenario

عنوان: ثبت موفق سفارش توسط مشتری

هدف: بررسی اینکه مشتری بتواند فرایند خرید را از انتخاب محصول تا ثبت نهایی سفارش با موفقیت انجام دهد.

UAT Test Case

مرحله	اقدام	نتیجه مورد انتظار
1	ورود به سایت	صفحه اصلی نمایش داده شود.
2	انتخاب محصول	صفحه محصول نمایش داده شود.
3	افزودن محصول به سبد	محصول به سبد اضافه شود.
4	ادامه فرایند خرید	صفحه Checkout نمایش داده شود.
5	وارد کردن اطلاعات ارسال	اطلاعات با موفقیت ثبت شود.
6	پرداخت سفارش	پرداخت با موفقیت انجام شود.
7	بررسی نتیجه	سفارش ایجاد شود.
8	بررسی شماره سفارش	شماره سفارش نمایش داده شود.

در این مثال، مسیر به‌صورت واضح از نیازمندی تا اجرای تست مشخص است:

Requirement
↓
Acceptance Criteria
↓
UAT Scenario
↓
UAT Test Case
↓
Execution
↓
Result

این زنجیره برای یک تستر نرم‌افزار اهمیت زیادی دارد، زیرا کمک می‌کند تست‌ها مستقیماً به نیازهای واقعی محصول و کسب‌وکار متصل باشند.

چند نکته برای طراحی بهتر UAT Scenario

برای سناریوهای UAT بهتر است:

• روی فرایندهای مهم کسب‌وکار تمرکز کنید.
• سناریو را از دید کاربر یا کسب‌وکار بنویسید.
• هدف سناریو مشخص باشد.
• Acceptance Criteria را در نظر بگیرید.
• از سناریوهای بیش از حد فنی پرهیز کنید.
• مسیرهای مهم و استثناهای کسب‌وکار را پوشش دهید.
• سناریوها را قابل اجرا و قابل ارزیابی نگه دارید.

در نهایت، یک سناریوی خوب UAT باید بتواند یک سؤال ساده را پاسخ دهد:

آیا کاربر می‌تواند فرایند مهم موردنظر کسب‌وکار را با محصول، به شکلی که انتظار می‌رود، با موفقیت انجام دهد؟

چگونه برای UAT تست کیس بنویسیم؟

بعد از مشخص شدن Business Requirement، Acceptance Criteria و سناریوهای UAT، مرحله بعد طراحی UAT Test Case است.

UAT Test Case مجموعه‌ای از اطلاعات و مراحل مشخص است که به کاربر یا تستر کمک می‌کند یک سناریوی پذیرش را اجرا کند و نتیجه واقعی را با نتیجه مورد انتظار مقایسه کند.

در UAT، Test Caseها بهتر است تا حد امکان روی فرایندهای واقعی کسب‌وکار تمرکز داشته باشند و فقط به بررسی جزئیات فنی سیستم محدود نشوند.

اجزای اصلی UAT Test Case

قالب Test Case می‌تواند بر اساس ابزار و فرایند هر سازمان متفاوت باشد، اما معمولاً موارد زیر در آن قرار می‌گیرند:

فیلد	توضیح
Test Case ID	شناسه یکتای Test Case
Scenario	سناریویی که تست به آن مربوط است
Preconditions	شرایط لازم قبل از شروع تست
Test Data	داده‌های موردنیاز برای اجرای تست
Test Steps	مراحل اجرای تست
Expected Result	نتیجه مورد انتظار
Actual Result	نتیجه واقعی
Status	وضعیت تست مانند Pass، Fail یا Blocked
Comments	توضیحات و نکات اضافی

Test Case ID

هر Test Case بهتر است یک شناسه مشخص داشته باشد.

برای مثال:

UAT-001

این شناسه باعث می‌شود بتوان Test Case را در گزارش‌ها، ابزار مدیریت تست و Defectها به‌سادگی دنبال کرد.

Preconditions

Precondition شرایطی است که قبل از شروع تست باید برقرار باشد.

مثلاً برای تست ثبت سفارش:

• کاربر حساب کاربری فعال داشته باشد.
• کاربر وارد سیستم شده باشد.
• محصول موردنظر موجود باشد.
• روش پرداخت فعال باشد.

Test Data

Test Data اطلاعاتی است که برای اجرای سناریو استفاده می‌شود.

مثلاً:

• Username: کاربر تست
• Product: محصول موجود
• Quantity: 1
• Address: آدرس تست
• Payment Method: پرداخت آنلاین

در محیط‌های واقعی باید سیاست‌های سازمان درباره استفاده از داده‌های واقعی و اطلاعات حساس نیز رعایت شود.

Test Steps

در این بخش مراحل اجرای Test Case نوشته می‌شوند.

1. ورود به حساب کاربری
2. جستجوی محصول
3. افزودن محصول به سبد
4. رفتن به صفحه Checkout
5. ثبت آدرس
6. پرداخت سفارش
7. بررسی نتیجه

مراحل باید به‌اندازه‌ای واضح باشند که کاربر یا تستر بتواند بدون ابهام آنها را اجرا کند.

Expected Result

Expected Result مشخص می‌کند بعد از اجرای هر مرحله یا در پایان Test Case چه نتیجه‌ای باید مشاهده شود.

برای مثال:

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

این بخش اهمیت زیادی دارد، زیرا بدون Expected Result نمی‌توان نتیجه واقعی را به‌صورت دقیق ارزیابی کرد.

Actual Result

بعد از اجرای تست، نتیجه واقعی در این قسمت ثبت می‌شود.

مثلاً:

پرداخت با موفقیت انجام شد و شماره سفارش 12548 نمایش داده شد.

یا در حالت Fail:

پرداخت موفق بود، اما سفارش ایجاد نشد.

Status

در ساده‌ترین حالت می‌توان وضعیت Test Case را به شکل زیر مشخص کرد:

• Pass: نتیجه واقعی مطابق نتیجه مورد انتظار است.
• Fail: نتیجه واقعی با نتیجه مورد انتظار مطابقت ندارد.
• Blocked: اجرای تست به دلیل یک مشکل یا وابستگی امکان‌پذیر نیست.
• Not Run: تست هنوز اجرا نشده است.

نمونه کامل UAT Test Case

فرض کنیم سناریوی ما این باشد:

مشتری بتواند با پرداخت موفق، سفارش خود را ثبت کند.

Test Case می‌تواند به این شکل باشد:

فیلد	مقدار
Test Case ID	UAT-001
Scenario	ثبت موفق سفارش
Preconditions	کاربر وارد سیستم شده و محصول موجود است.
Test Data	محصول تست، آدرس تست، حساب کاربری
Test Steps	انتخاب محصول، افزودن به سبد، ثبت آدرس و پرداخت
Expected Result	سفارش ایجاد و شماره سفارش نمایش داده شود.
Actual Result	سفارش ایجاد و شماره سفارش نمایش داده شد.
Status	Pass

اما برای اینکه Test Case واقعاً قابل اجرا باشد، بهتر است مراحل را با جزئیات بیشتری ثبت کنیم:

Step	Action	Expected Result
1	ورود به حساب کاربری	کاربر وارد حساب شود.
2	انتخاب محصول	صفحه محصول نمایش داده شود.
3	افزودن محصول به سبد	محصول به سبد اضافه شود.
4	ورود به Checkout	خلاصه سفارش نمایش داده شود.
5	ثبت اطلاعات ارسال	اطلاعات با موفقیت ذخیره شود.
6	انتخاب پرداخت آنلاین	گزینه پرداخت فعال شود.
7	انجام پرداخت	پرداخت با موفقیت انجام شود.
8	مشاهده نتیجه	سفارش ایجاد و شماره سفارش نمایش داده شود.

نمونه UAT Test Case ناموفق

حالا فرض کنیم همین Test Case را اجرا می‌کنیم، اما بعد از پرداخت موفق، سفارش ایجاد نمی‌شود.

Expected Result:

پس از پرداخت موفق، سفارش ایجاد شود و شماره سفارش نمایش داده شود.

Actual Result:

پرداخت موفق انجام شد، اما سفارش ایجاد نشد.

Status: Fail

در این شرایط باید یک Defect ثبت شود تا مشکل بررسی و برطرف شود.

پس جریان کار می‌تواند به شکل زیر ادامه پیدا کند:

Test Case → Fail → Defect → Fix → Retest → Pass

این چرخه یکی از بخش‌های مهم فرایند UAT است.

آیا UAT Test Case باید خیلی جزئی باشد؟

میزان جزئیات Test Case به نوع پروژه، کاربران UAT و فرایند سازمان بستگی دارد.

اگر کاربران UAT افراد کسب‌وکار باشند، Test Case باید به‌اندازه‌ای واضح باشد که اجرای آن برایشان دشوار نباشد.

اما نباید Test Case را آن‌قدر فنی و پیچیده بنویسیم که کاربر کسب‌وکار مجبور شود با جزئیات پیاده‌سازی نرم‌افزار درگیر شود.

برای مثال، در UAT معمولاً بهتر است بنویسیم:

«کاربر یک سفارش ایجاد کرده و پرداخت آنلاین را انجام می‌دهد.»

تا اینکه مراحل را با جزئیات داخلی API، Queryهای پایگاه داده یا ساختار سرویس‌ها توصیف کنیم؛ مگر اینکه چنین جزئیاتی برای هدف تست ضروری باشند.

تفاوت UAT Test Case با Test Caseهای معمول QA

UAT Test Case از نظر ساختار می‌تواند بسیار شبیه Test Caseهای معمول QA باشد، اما تمرکز آن متفاوت است.

در تست‌های QA ممکن است Test Caseهایی برای بررسی موارد بسیار جزئی نوشته شوند:

• اعتبارسنجی یک فیلد
• پیام خطای یک ورودی
• محدودیت طول یک مقدار
• رفتار یک دکمه
• پاسخ یک سرویس

اما در UAT معمولاً تمرکز بیشتر روی سناریوهای مهم و واقعی کسب‌وکار است.

برای مثال:

QA Test Case:

بررسی اینکه با وارد کردن رمز عبور اشتباه، پیام خطای مناسب نمایش داده شود.

UAT Test Case:

بررسی اینکه کاربر بتواند با اطلاعات معتبر وارد سیستم شده و فرایند موردنیاز خود را انجام دهد.

البته این به معنای آن نیست که UAT نباید شرایط منفی یا جزئیات خاص را بررسی کند؛ بلکه انتخاب Test Case باید بر اساس هدف و معیارهای پذیرش انجام شود.

نکات مهم هنگام نوشتن UAT Test Case

برای نوشتن Test Caseهای بهتر، این نکات را در نظر بگیرید:

1. هر Test Case باید هدف مشخصی داشته باشد.
2. Test Case باید به یک Requirement یا Acceptance Criteria مرتبط باشد.
3. مراحل اجرا باید واضح و قابل تکرار باشند.
4. Expected Result باید مشخص و قابل ارزیابی باشد.
5. داده‌های لازم قبل از اجرای تست مشخص شوند.
6. سناریوهای اصلی کسب‌وکار در اولویت قرار گیرند.
7. شرایط مهم و استثناهای کسب‌وکار نیز در صورت نیاز پوشش داده شوند.
8. نتیجه واقعی بعد از اجرای تست ثبت شود.
9. وضعیت Test Case به‌صورت شفاف مشخص شود.
10. در صورت Fail شدن تست، ارتباط آن با Defect حفظ شود.

در نهایت، یک UAT Test Case خوب باید به تستر یا کاربر کمک کند تا بدون ابهام به یک سؤال پاسخ دهد:

آیا محصول در این سناریوی واقعی، همان نتیجه‌ای را ارائه می‌دهد که کسب‌وکار انتظار دارد؟

مثال کامل تست UAT؛ از Requirement تا Sign-off

برای اینکه فرایند UAT را بهتر درک کنیم، فرض کنید یک فروشگاه اینترنتی در حال آماده‌سازی نسخه جدید سیستم خود است.

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

در این مثال، یک قابلیت را از مرحله تعریف نیازمندی تا اجرای تست، ثبت Defect، Retest و در نهایت UAT Sign-off دنبال می‌کنیم.

مرحله اول: Business Requirement

ابتدا نیاز کسب‌وکار مشخص می‌شود:

مشتری باید بتواند محصولات موردنظر خود را انتخاب کند، سفارش خود را ثبت کند و هزینه آن را به‌صورت آنلاین پرداخت کند.

این Requirement هدف کلی قابلیت را مشخص می‌کند، اما برای اجرای UAT به معیارهای دقیق‌تری نیاز داریم.

مرحله دوم: Acceptance Criteria

برای این قابلیت، معیارهای پذیرش می‌توانند به شکل زیر تعریف شوند:

1. مشتری بتواند محصول را به سبد خرید اضافه کند.
2. مبلغ نهایی سفارش به‌درستی محاسبه شود.
3. مشتری بتواند اطلاعات ارسال را وارد کند.
4. مشتری بتواند پرداخت آنلاین را انجام دهد.
5. پس از پرداخت موفق، سفارش ایجاد شود.
6. شماره سفارش به مشتری نمایش داده شود.
7. وضعیت سفارش به‌درستی ثبت شود.

اکنون مشخص است که برای پذیرش این قابلیت چه شرایطی باید برقرار باشند.

مرحله سوم: طراحی UAT Scenario

بر اساس Requirement و Acceptance Criteria، یک سناریوی UAT طراحی می‌کنیم:

UAT Scenario:

مشتری یک محصول را انتخاب کرده، سفارش خود را ثبت و هزینه آن را آنلاین پرداخت می‌کند و در نهایت تأییدیه ثبت سفارش را دریافت می‌کند.

هدف این سناریو بررسی کل فرایند خرید از دید مشتری است.

مرحله چهارم: آماده‌سازی Test Data

برای اجرای سناریو به داده‌های زیر نیاز داریم:

داده	مقدار نمونه
کاربر	Customer01
محصول	Laptop
موجودی	5 عدد
تعداد خرید	1
روش پرداخت	Online Payment
آدرس	Test Address

داده‌ها باید برای محیط UAT آماده باشند و کاربر موردنظر نیز دسترسی لازم را داشته باشد.

مرحله پنجم: اجرای UAT Test Case

حالا Test Case را اجرا می‌کنیم:

Step	Action	Expected Result	Actual Result	Status
1	ورود به حساب کاربری	ورود موفق باشد	ورود موفق بود	Pass
2	انتخاب محصول	صفحه محصول نمایش داده شود	محصول نمایش داده شد	Pass
3	افزودن محصول به سبد	محصول به سبد اضافه شود	محصول اضافه شد	Pass
4	رفتن به Checkout	خلاصه سفارش نمایش داده شود	خلاصه سفارش نمایش داده شد	Pass
5	ثبت اطلاعات ارسال	اطلاعات ذخیره شود	اطلاعات ذخیره شد	Pass
6	انجام پرداخت	پرداخت موفق انجام شود	پرداخت موفق بود	Pass
7	بررسی ثبت سفارش	سفارش ایجاد شود	سفارش ایجاد نشد	Fail

در اینجا تست با شکست مواجه شده است و باید علت اختلاف بین نتیجه مورد انتظار و نتیجه واقعی بررسی شود.

مرحله ششم: ثبت Defect

بعد از مشاهده Fail، مشکل باید به‌صورت واضح ثبت شود.

• Title: سفارش پس از پرداخت موفق ایجاد نمی‌شود
• Environment: UAT
• Precondition: کاربر دارای حساب فعال و محصول موجود است.
• Steps to Reproduce: ورود به حساب کاربری، انتخاب محصول، افزودن محصول به سبد، تکمیل اطلاعات سفارش، پرداخت آنلاین و بازگشت به صفحه نتیجه
• Expected Result: پس از پرداخت موفق، سفارش ایجاد شده و شماره سفارش نمایش داده شود.
• Actual Result: پرداخت موفق است، اما سفارش ایجاد نمی‌شود.
• Status: Open

این اطلاعات به تیم توسعه کمک می‌کند مشکل را بررسی و اصلاح کند.

مرحله هفتم: رفع Defect

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

پس از اصلاح مشکل، نسخه جدید در محیط UAT Deploy می‌شود.

اما فرایند هنوز تمام نشده است و باید اصلاح انجام‌شده دوباره بررسی شود.

مرحله هشتم: Retest

تستر همان Test Case را دوباره اجرا می‌کند.

Expected Result:

پس از پرداخت موفق، سفارش ایجاد شود و شماره سفارش نمایش داده شود.

Actual Result:

سفارش ایجاد شد و شماره سفارش 12548 نمایش داده شد.

Status: Pass

Defect نیز می‌تواند بر اساس Workflow سازمان به وضعیت‌هایی مانند Resolved یا Closed منتقل شود.

مرحله نهم: بررسی Acceptance Criteria

حالا نتایج اجرای UAT را با Acceptance Criteria مقایسه می‌کنیم:

Acceptance Criteria	Result
افزودن محصول به سبد	Pass
محاسبه صحیح مبلغ	Pass
ثبت اطلاعات ارسال	Pass
پرداخت آنلاین	Pass
ایجاد سفارش پس از پرداخت	Pass
نمایش شماره سفارش	Pass
ثبت صحیح وضعیت سفارش	Pass

در این مثال، تمام معیارهای پذیرش با موفقیت برآورده شده‌اند.

مرحله دهم: UAT Sign-off

بعد از بررسی نتایج، نماینده کسب‌وکار یا فرد مسئول پذیرش می‌تواند نتیجه UAT را بررسی کند.

اگر شرایط پذیرش مطابق توافق پروژه برقرار باشد، پذیرش محصول تأیید می‌شود. این تأیید می‌تواند به شکل زیر ثبت شود:

UAT Status: Accepted

در سازمان‌هایی که فرایند رسمی Sign-off دارند، سند یا رکورد مربوط به پذیرش نیز در این مرحله تکمیل می‌شود.

جریان کامل این مثال

کل فرایند را می‌توان در یک مسیر خلاصه کرد:

Business Requirement → Acceptance Criteria → UAT Scenario → Test Data → UAT Test Case → Execution → Fail → Defect → Fix → Retest → Pass → UAT Sign-off

این مثال نشان می‌دهد که UAT فقط اجرای چند تست نیست؛ بلکه یک فرایند کامل برای بررسی و تصمیم‌گیری درباره پذیرش محصول از دید کسب‌وکار است.

نکته مهم برای تسترها

در این فرایند، تستر می‌تواند در بسیاری از مراحل حضور داشته باشد:

Requirement Review → Test Design → Environment Preparation → Test Execution → Defect Management → Retest → Reporting

اما تصمیم نهایی درباره اینکه محصول از دید کسب‌وکار پذیرفته شده است یا خیر، لزوماً بر عهده تستر نیست.

تستر شواهد و نتایج تست را فراهم می‌کند؛ ذی‌نفع کسب‌وکار بر اساس معیارهای پذیرش و ریسک‌های موجود درباره پذیرش محصول تصمیم می‌گیرد.

چک‌لیست تست UAT؛ قبل، حین و بعد از اجرای تست

داشتن یک چک‌لیست مشخص کمک می‌کند موارد مهم در فرایند UAT فراموش نشوند. این چک‌لیست را می‌توان در سه مرحله اصلی بررسی کرد:

قبل از UAT → هنگام اجرای UAT → بعد از UAT

چک‌لیست قبل از شروع UAT

قبل از شروع اجرای UAT، بهتر است مطمئن شویم محصول، محیط، داده‌ها و افراد موردنیاز برای اجرای تست آماده هستند.

نیازمندی‌ها و محدوده

• Business Requirements مشخص شده‌اند.
• Scope مربوط به UAT مشخص است.
• قابلیت‌های موردنظر برای تست مشخص شده‌اند.
• موارد خارج از Scope مشخص شده‌اند.
• Acceptance Criteria تعریف شده‌اند.
• ذی‌نفعان و افراد مسئول UAT مشخص شده‌اند.

آمادگی نرم‌افزار

• نسخه مناسب نرم‌افزار در محیط UAT Deploy شده است.
• تست‌های ضروری QA انجام شده‌اند.
• مشکلات Critical و Blocker برطرف شده‌اند یا وضعیت آن‌ها مشخص است.
• Smoke Test محیط با موفقیت انجام شده است.
• سرویس‌ها و وابستگی‌های موردنیاز در دسترس هستند.

محیط و داده‌های تست

• محیط UAT آماده است.
• کاربران موردنیاز ایجاد شده‌اند.
• دسترسی‌های لازم تنظیم شده‌اند.
• Test Data آماده است.
• داده‌های موردنیاز سناریوها در دسترس هستند.
• محدودیت‌ها و الزامات مربوط به داده‌های واقعی بررسی شده‌اند.

سناریو و Test Case

• UAT Scenarioها طراحی شده‌اند.
• Test Caseها آماده هستند.
• Test Caseها با Acceptance Criteria ارتباط دارند.
• Expected Resultها مشخص هستند.
• شرایط لازم برای اجرای هر Test Case مشخص شده است.
• سناریوهای اصلی کسب‌وکار پوشش داده شده‌اند.

چک‌لیست هنگام اجرای UAT

در زمان اجرای تست نیز بهتر است اجرای سناریوها و ثبت نتایج به‌صورت منظم کنترل شود:

• هر Test Case با شناسه مشخص اجرا می‌شود.
• نتیجه واقعی ثبت می‌شود.
• وضعیت هر Test Case مشخص می‌شود.
• در صورت Fail شدن تست، Defect ثبت می‌شود.
• اطلاعات کافی برای بازتولید Defect ثبت شده است.
• Screenshot یا Log موردنیاز ضمیمه شده است.
• ارتباط بین Defect و Test Case حفظ شده است.
• مشکلات Blocker به‌سرعت اطلاع‌رسانی می‌شوند.
• تغییرات نسخه نرم‌افزار در طول UAT ثبت می‌شوند.
• در صورت تغییر نسخه، تست‌های لازم مجدداً اجرا می‌شوند.

چک‌لیست بعد از اجرای UAT

پس از پایان اجرای سناریوها، نتایج تست و وضعیت محصول باید بررسی شوند:

• Test Caseهای برنامه‌ریزی‌شده اجرا شده‌اند.
• Test Caseهای Pass و Fail مشخص هستند.
• Test Caseهای Blocked مشخص هستند.
• Defectهای باز بررسی شده‌اند.
• Defectهای Critical و High تعیین تکلیف شده‌اند.
• Retestهای موردنیاز انجام شده‌اند.
• Acceptance Criteria بررسی شده‌اند.
• ریسک‌های باقی‌مانده مستند شده‌اند.
• نتیجه نهایی UAT مشخص شده است.
• گزارش UAT تهیه شده است.
• در صورت نیاز، UAT Sign-off دریافت شده است.

چه زمانی UAT را موفق در نظر بگیریم؟

موفقیت UAT فقط به تعداد Test Caseهای Pass شده وابسته نیست.

برای مثال، ممکن است ۹۵ درصد تست‌ها Pass شده باشند، اما یک Defect بسیار مهم در یک فرایند حیاتی کسب‌وکار همچنان باز باشد. در چنین شرایطی، صرفاً بالا بودن Pass Rate نمی‌تواند به معنای موفقیت UAT باشد.

برای ارزیابی نتیجه UAT بهتر است موارد زیر نیز بررسی شوند:

• آیا Acceptance Criteria برآورده شده‌اند؟
• آیا فرایندهای حیاتی کسب‌وکار بدون مشکل کار می‌کنند؟
• آیا Defect مهمی باز باقی مانده است؟
• آیا ریسک‌های باقی‌مانده توسط کسب‌وکار پذیرفته شده‌اند؟
• آیا ذی‌نفع مسئول با وضعیت محصول موافق است؟

بنابراین، معیار موفقیت UAT باید بر اساس هدف پروژه، Acceptance Criteria و سطح ریسک قابل قبول تعیین شود.

UAT Sign-off چیست؟

UAT Sign-off تأیید رسمی یا ثبت‌شده‌ای است که نشان می‌دهد ذی‌نفع مسئول، نتایج UAT را بررسی کرده و محصول را بر اساس معیارهای توافق‌شده پذیرفته است.

Sign-off می‌تواند در قالب‌های مختلف انجام شود؛ برای مثال:

• تأیید در ابزار مدیریت پروژه
• تأیید در سیستم مدیریت تست
• ایمیل رسمی
• سند پذیرش
• امضای فرم UAT

مهم این است که مشخص باشد:

چه کسی → چه چیزی را → بر اساس چه معیارهایی → تأیید کرده است.

نمونه ساده UAT Sign-off

فرض کنید تمام سناریوهای حیاتی فروشگاه اینترنتی با موفقیت اجرا شده‌اند و Defectهای مهم نیز تعیین تکلیف شده‌اند. نتیجه UAT می‌تواند به‌صورت زیر ثبت شود:

مورد	نتیجه
UAT Scope	ثبت و پرداخت سفارش
Test Cases	20
Passed	19
Failed	1
Blocked	0
Open Critical Defects	0
Acceptance Criteria	برآورده شده
Business Decision	Accepted
UAT Status	Signed-off

یک Test Case Fail شده لزوماً به معنای رد کامل محصول نیست. اگر آن مورد اهمیت کمی داشته باشد و ریسک آن توسط کسب‌وکار پذیرفته شود، ممکن است محصول همچنان Accepted شود.

به همین دلیل، تصمیم نهایی UAT باید علاوه بر نتایج تست، بر اساس اهمیت مشکلات و ریسک کسب‌وکار گرفته شود.

نکته مهم درباره موفقیت UAT

UAT را نباید صرفاً یک مرحله برای رسیدن به عددی مانند «۹۰٪ Pass Rate» دانست.

آیا محصول برای نیاز واقعی کسب‌وکار و کاربران، در سطح قابل قبول آماده است؟

برای پاسخ به این سؤال باید کیفیت سناریوها، اهمیت فرایندهای تست‌شده، شدت Defectها، Acceptance Criteria، ریسک‌های باقی‌مانده و تصمیم ذی‌نفعان را در کنار یکدیگر در نظر گرفت.

اشتباهات رایج در تست UAT

اگر UAT بدون برنامه‌ریزی مناسب انجام شود، ممکن است به جای اینکه به تصمیم‌گیری درباره پذیرش محصول کمک کند، به یک مرحله تکراری از تست‌های QA تبدیل شود.

شناخت اشتباهات رایج می‌تواند به تیم کمک کند فرایند UAT را مؤثرتر اجرا کند.

1. شروع UAT قبل از آماده بودن محصول

یکی از رایج‌ترین اشتباهات، شروع UAT در شرایطی است که نرم‌افزار هنوز مشکلات اساسی دارد.

اگر کاربران در همان ابتدای UAT با خطاهای پایه‌ای مانند Login، Navigation یا عملکردهای اصلی مواجه شوند، بخش زیادی از زمان آنها صرف پیدا کردن مشکلاتی می‌شود که بهتر بود در مراحل قبلی QA شناسایی و برطرف می‌شدند.

قبل از شروع UAT بهتر است حداقل سطح مشخصی از آمادگی محصول تعریف شود.

2. استفاده از UAT به‌عنوان جایگزین QA

UAT نباید جایگزین Functional Testing، System Testing یا سایر تست‌های ضروری QA شود.

اگر تیم توسعه یا QA انتظار داشته باشد کاربران کسب‌وکار مشکلات فنی نرم‌افزار را پیدا کنند، UAT از هدف اصلی خود فاصله می‌گیرد.

بهتر است قبل از UAT، تست‌های ضروری انجام شده باشند و محصول به سطح مناسبی از کیفیت رسیده باشد.

3. نداشتن Acceptance Criteria مشخص

اگر مشخص نباشد چه شرایطی باعث پذیرش یک قابلیت می‌شود، نتیجه UAT ممکن است به برداشت شخصی افراد وابسته شود.

برای مثال:

«سیستم باید عملکرد خوبی داشته باشد.»

معیار قابل اندازه‌گیری و مشخصی نیست.

در مقابل:

«پس از پرداخت موفق، سفارش باید ایجاد شده و شماره سفارش به کاربر نمایش داده شود.»

معیار مشخص‌تری برای ارزیابی ایجاد می‌کند.

4. طراحی سناریوهای بیش از حد فنی

UAT از دید کاربر و کسب‌وکار انجام می‌شود. بنابراین سناریوهای UAT نباید بدون دلیل وارد جزئیات پیاده‌سازی شوند.

برای مثال، کاربر کسب‌وکار لزوماً نیازی ندارد بداند:

• کدام API فراخوانی شده است.
• کدام Database Query اجرا شده است.
• ساختار داخلی سرویس چگونه است.

مگر اینکه چنین اطلاعاتی برای هدف خاص تست ضروری باشد.

بهتر است سناریو بر فرایند واقعی کسب‌وکار تمرکز کند.

5. انتخاب کاربران نامناسب برای UAT

اگر افرادی که UAT را انجام می‌دهند شناخت کافی از فرایند کسب‌وکار نداشته باشند، ممکن است نتوانند محصول را از دید واقعی کسب‌وکار ارزیابی کنند.

به همین دلیل باید افرادی انتخاب شوند که:

• با فرایند کاری آشنا باشند.
• نیازهای کاربران را بشناسند.
• بتوانند نتیجه تست را ارزیابی کنند.
• در صورت نیاز اختیار یا نقش مشخصی در پذیرش داشته باشند.

6. آماده نبودن محیط UAT

اگر محیط UAT ناپایدار باشد، سرویس‌های وابسته در دسترس نباشند یا دسترسی کاربران درست تنظیم نشده باشد، نتایج تست قابل اعتماد نخواهند بود.

برای مثال، اگر سرویس پرداخت در دسترس نباشد، نمی‌توان نتیجه گرفت که سناریوی پرداخت Fail شده است.

ممکن است مشکل مربوط به محیط باشد، نه نرم‌افزار.

به همین دلیل باید قبل از شروع UAT، آمادگی محیط بررسی شود.

7. استفاده از داده‌های نامناسب

اگر داده‌های تست با شرایط واقعی کسب‌وکار مطابقت نداشته باشند، ممکن است سناریوهای مهم به‌درستی بررسی نشوند.

برای مثال، اگر UAT یک سیستم بانکی فقط با داده‌های بسیار ساده انجام شود، ممکن است برخی شرایط واقعی مانند مشتریان با وضعیت‌های متفاوت، محدودیت‌های حساب یا تراکنش‌های خاص بررسی نشوند.

بنابراین Test Data باید متناسب با سناریوهای واقعی انتخاب شود.

8. تمرکز فقط روی Happy Path

یکی دیگر از اشتباهات رایج این است که فقط موفقیت‌آمیزترین مسیرها تست شوند.

مثلاً در فروشگاه اینترنتی فقط این سناریو اجرا شود:

انتخاب محصول → پرداخت موفق → ثبت سفارش

در حالی که برخی شرایط مهم دیگر ممکن است نیاز به بررسی داشته باشند:

• پرداخت ناموفق
• لغو سفارش
• اتمام موجودی
• تغییر اطلاعات ارسال
• بازگشت وجه
• قطع ارتباط با سرویس وابسته

UAT قرار نیست تمام حالت‌های ممکن را مانند یک تست جامع QA پوشش دهد، اما مسیرهای مهم کسب‌وکار و استثناهای بااهمیت نباید نادیده گرفته شوند.

9. مشخص نبودن مسئولیت‌ها

اگر مشخص نباشد چه کسی:

• سناریوها را آماده می‌کند،
• تست را اجرا می‌کند،
• Defect را ثبت می‌کند،
• مشکل را پیگیری می‌کند،
• نتیجه را تأیید می‌کند،
• و Sign-off را انجام می‌دهد،

فرایند UAT می‌تواند با سردرگمی مواجه شود.

بهتر است نقش‌ها و مسئولیت‌ها قبل از شروع UAT مشخص باشند.

10. ثبت نکردن نتایج UAT

گاهی کاربران تست‌ها را اجرا می‌کنند و فقط به‌صورت شفاهی اعلام می‌کنند که «همه‌چیز خوب است».

این روش برای پروژه‌های جدی مناسب نیست.

نتایج باید تا حد امکان مستند باشند تا بعداً مشخص باشد:

• چه چیزی تست شده است؟
• چه کسی تست کرده است؟
• چه نتیجه‌ای به دست آمده است؟
• چه مشکلاتی پیدا شده‌اند؟
• چه مشکلاتی رفع شده‌اند؟
• چه ریسک‌هایی باقی مانده‌اند؟
• چه کسی محصول را پذیرفته است؟

مستندسازی مناسب، شفافیت و قابلیت پیگیری UAT را افزایش می‌دهد.

11. در نظر گرفتن Pass Rate به‌عنوان تنها معیار موفقیت

ممکن است ۹۸ درصد Test Caseها Pass شوند، اما همان ۲ درصد باقی‌مانده شامل یک فرایند حیاتی کسب‌وکار باشد.

بنابراین نباید فقط به درصد تست‌های موفق نگاه کرد.

مواردی مانند Business Impact، Severity، Risk و Acceptance Criteria نیز باید در تصمیم‌گیری لحاظ شوند.

12. نداشتن Retest بعد از رفع Defect

فرض کنید یک مشکل مهم در UAT پیدا شده و تیم توسعه اعلام می‌کند که آن را برطرف کرده است.

این موضوع به‌تنهایی کافی نیست.

باید Test Case مربوطه دوباره اجرا شود تا مشخص شود مشکل واقعاً برطرف شده است.

در صورت نیاز، تست‌های مرتبط نیز باید دوباره بررسی شوند.

جریان صحیح این بخش می‌تواند به شکل زیر باشد:

Defect → Fix → Retest → Result

13. تغییر مداوم Scope در طول UAT

اگر در طول UAT بدون کنترل مشخص، قابلیت‌ها و نیازمندی‌های جدید وارد Scope شوند، فرایند تست ممکن است دائماً تغییر کند.

این موضوع باعث می‌شود:

• زمان UAT افزایش پیدا کند.
• Test Caseها نیاز به تغییر داشته باشند.
• نتایج قبلی اعتبار کمتری پیدا کنند.
• تصمیم‌گیری برای Sign-off دشوار شود.

بنابراین تغییرات Scope باید کنترل و مستند شوند.

14. تصور اینکه بعد از Sign-off هیچ مشکلی وجود ندارد

UAT Sign-off به این معنا نیست که نرم‌افزار کاملاً بدون نقص است.

Sign-off نشان می‌دهد محصول بر اساس معیارها، شرایط و ریسک‌های مورد توافق برای پذیرش تأیید شده است.

ممکن است برخی Defectهای کم‌اهمیت باقی بمانند یا برخی ریسک‌ها با آگاهی کسب‌وکار پذیرفته شوند.

بنابراین بهتر است به جای این تصور:

«بعد از Sign-off هیچ Bugای نباید وجود داشته باشد.»

این مفهوم را در نظر بگیریم:

«بعد از Sign-off، وضعیت محصول و ریسک‌های قابل پذیرش برای کسب‌وکار مشخص و تأیید شده‌اند.»

چگونه از این اشتباهات جلوگیری کنیم؟

برای جلوگیری از مشکلات رایج UAT، بهتر است قبل از شروع تست موارد زیر مشخص باشند:

• Scope → چه چیزی قرار است تست شود؟
• Acceptance Criteria → چه شرایطی برای پذیرش لازم است؟
• Users → چه کسانی UAT را انجام می‌دهند؟
• Environment → تست در چه محیطی انجام می‌شود؟
• Test Data → از چه داده‌هایی استفاده می‌کنیم؟
• Scenarios & Test Cases → چه فرایندهایی بررسی می‌شوند؟
• Defect Process → مشکلات چگونه ثبت و پیگیری می‌شوند؟
• Sign-off Criteria → چه شرایطی برای پذیرش نهایی لازم است؟

اگر این موارد از ابتدا مشخص باشند، احتمال تبدیل شدن UAT به یک فرایند نامنظم و کم‌اثر بسیار کمتر خواهد شد.

ابزارهای مورد استفاده در UAT

UAT را می‌توان با ابزارهای مختلفی مدیریت کرد. انتخاب ابزار به اندازه پروژه، روش توسعه، تعداد افراد درگیر و فرایند سازمان بستگی دارد.

نکته مهم این است که ابزار به‌تنهایی باعث موفقیت UAT نمی‌شود؛ بلکه باید بتواند سناریوها، Test Caseها، Defectها، نتایج تست و تأیید نهایی را به‌صورت قابل پیگیری مدیریت کند.

در پروژه‌های کوچک ممکن است یک Spreadsheet برای مدیریت UAT کافی باشد، در حالی که پروژه‌های بزرگ‌تر معمولاً به ابزارهای تخصصی‌تر برای مدیریت Test Case، Requirement، Defect و گزارش‌های تست نیاز دارند.

ابزار مدیریت تست

در پروژه‌های بزرگ‌تر، استفاده از ابزارهای تخصصی مدیریت تست می‌تواند به سازمان‌دهی Test Caseها و نتایج UAT کمک کند.

این ابزارها معمولاً امکاناتی مانند موارد زیر دارند:

• ایجاد و مدیریت Test Case
• دسته‌بندی سناریوها
• اجرای Test Case
• ثبت Pass و Fail
• اتصال Test Case به Requirement
• ثبت و پیگیری Defect
• تهیه گزارش تست
• مشاهده وضعیت کلی UAT

برای مثال، تیم می‌تواند برای هر Requirement چند Acceptance Criteria و برای هر معیار، سناریوهای UAT مشخصی داشته باشد و ارتباط میان آنها را حفظ کند.

از ابزارهای تخصصی مدیریت تست می‌توان به ابزارهایی مانند TestRail، Zephyr و qTest اشاره کرد. انتخاب بین این ابزارها باید بر اساس فرایند تست، اندازه تیم و نیازهای پروژه انجام شود.

ابزارهای مدیریت پروژه و Issue Tracking

گاهی UAT در همان ابزار مدیریت پروژه یا Issue Tracking سازمان انجام می‌شود.

در این روش می‌توان مواردی مانند:

• Requirement
• User Story
• Acceptance Criteria
• Task
• Defect
• UAT Result

را در یک محیط مدیریت کرد.

این روش به‌خصوص در تیم‌هایی که از Agile استفاده می‌کنند، می‌تواند مفید باشد؛ زیرا اطلاعات مربوط به توسعه و تست در یک جریان کاری قرار می‌گیرند.

برای مثال، ابزارهایی مانند Jira، Azure DevOps و GitLab می‌توانند برای مدیریت Work Itemها، User Storyها، Taskها و Defectها مورد استفاده قرار گیرند و در برخی سازمان‌ها بخشی از فرایند UAT نیز در همین محیط مدیریت می‌شود.

ابزارهای مدیریت Defect

در UAT ممکن است کاربران یا تسترها با مشکلات مختلفی مواجه شوند. بنابراین وجود یک فرایند مشخص برای ثبت و پیگیری Defect اهمیت زیادی دارد.

یک Defect مناسب باید حداقل اطلاعاتی مانند موارد زیر را داشته باشد:

• عنوان مشکل
• محیط
• مراحل بازتولید
• Expected Result
• Actual Result
• Severity یا اولویت در صورت استفاده سازمان
• Screenshot یا Log در صورت نیاز
• ارتباط با Test Case یا Requirement

این اطلاعات باعث می‌شوند تیم توسعه بتواند مشکل را سریع‌تر بررسی کند.

در بسیاری از سازمان‌ها Defectها در همان ابزار مدیریت پروژه یا Issue Tracking ثبت می‌شوند. مهم‌تر از نام ابزار، وجود یک فرایند مشخص برای ثبت، اولویت‌بندی، رفع، Retest و بستن Defect است.

ابزارهای مستندسازی

در پروژه‌های کوچک ممکن است UAT با ابزارهای ساده‌تری مدیریت شود.

برای مثال می‌توان از یک Spreadsheet برای ثبت Test Caseها، نتایج تست و Defectها استفاده کرد.

Test Case ID	Scenario	Expected Result	Actual Result	Status	Defect ID
UAT-001	ثبت سفارش	سفارش ایجاد شود	سفارش ایجاد شد	Pass	–
UAT-002	لغو سفارش	سفارش لغو شود	سفارش لغو نشد	Fail	BUG-101
UAT-003	بازگشت وجه	مبلغ بازگردانده شود	مبلغ بازگردانده شد	Pass	–

این روش برای پروژه‌های کوچک می‌تواند کافی باشد، اما با افزایش تعداد Test Caseها و افراد، مدیریت دستی اطلاعات دشوارتر می‌شود.

ابزارهای ارتباطی

UAT معمولاً نیازمند ارتباط بین چند گروه است؛ مانند:

• تسترها
• توسعه‌دهندگان
• Product Owner
• Business Analyst
• کاربران کسب‌وکار
• مشتری

بنابراین ابزارهای ارتباطی نیز می‌توانند در هماهنگی جلسات، اطلاع‌رسانی درباره Defectها و پیگیری وضعیت UAT استفاده شوند.

با این حال، بهتر است نتیجه رسمی تست و تصمیم‌های مهم فقط در پیام‌های پراکنده باقی نمانند و در محل مناسب مستند شوند.

نمونه ابزارهای مورد استفاده در UAT

بسته به نیاز پروژه، می‌توان از ابزارهای مختلفی در بخش‌های مختلف فرایند UAT استفاده کرد:

نوع ابزار	نمونه ابزار	کاربرد در UAT
Test Management	TestRail، Zephyr، qTest	مدیریت Test Case، اجرای تست و گزارش‌گیری
Project / Issue Tracking	Jira، Azure DevOps، GitLab	مدیریت User Story، Task و Defect
Documentation / Spreadsheet	Excel، Google Sheets، Confluence	مستندسازی سناریوها و نتایج تست
Communication	Microsoft Teams، Slack	هماهنگی تیم‌ها و اطلاع‌رسانی

این ابزارها فقط نمونه هستند و انتخاب ابزار مناسب باید بر اساس نیاز واقعی پروژه و فرایند سازمان انجام شود.

هنگام انتخاب ابزار UAT به چه چیزهایی توجه کنیم؟

ابزار مناسب باید متناسب با نیاز پروژه انتخاب شود. صرفاً استفاده از یک ابزار معروف یا پرکاربرد به معنی مناسب بودن آن برای همه پروژه‌ها نیست.

قابلیت Traceability

یکی از مهم‌ترین معیارها، قابلیت Traceability یا قابلیت ردیابی ارتباط بین اجزای مختلف فرایند تست است.

برای مثال، ابزار مناسب باید تا حد امکان امکان حفظ ارتباط زیر را فراهم کند:

Requirement → Acceptance Criteria → Test Scenario → Test Case → Defect → Result

هرچه Traceability بهتر باشد، بررسی پوشش تست، پیدا کردن ارتباط بین مشکلات و نیازمندی‌ها و تهیه گزارش UAT آسان‌تر خواهد بود.

گزارش‌گیری

ابزار باید بتواند اطلاعاتی مانند موارد زیر را در اختیار تیم قرار دهد:

• تعداد Test Caseها
• Pass
• Fail
• Blocked
• Defectهای باز
• Defectهای مهم
• وضعیت کلی UAT

گزارش‌های مناسب به تیم کمک می‌کنند وضعیت UAT را سریع‌تر بررسی کرده و اطلاعات لازم برای تصمیم‌گیری را در اختیار ذی‌نفعان قرار دهد.

همکاری تیمی

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

برای مثال، تستر ممکن است Test Case را اجرا و نتیجه را ثبت کند، در حالی که Developer مسئول بررسی و رفع Defect باشد و Business User نتیجه قابلیت را از دید کسب‌وکار ارزیابی کند.

قابلیت پیگیری تغییرات

در پروژه‌های واقعی، Requirementها و Test Caseها ممکن است تغییر کنند. ابزار مناسب باید کمک کند تغییرات و ارتباط آنها با نتایج قبلی قابل پیگیری باشد.

این قابلیت به‌خصوص زمانی اهمیت دارد که در طول UAT نسخه جدیدی از نرم‌افزار Deploy شود یا Acceptance Criteria تغییر کند.

سطح دسترسی و کنترل اطلاعات

در پروژه‌هایی که افراد مختلفی در UAT حضور دارند، بهتر است ابزار امکان تعریف نقش‌ها و سطح دسترسی مناسب را داشته باشد.

برای مثال، همه کاربران لزوماً نباید امکان تغییر Acceptance Criteria، حذف Test Case یا تغییر نتیجه نهایی UAT را داشته باشند.

سادگی برای کاربران کسب‌وکار

این مورد بسیار مهم است.

اگر قرار است کاربران غیرتخصصی UAT را اجرا کنند، ابزار نباید آن‌قدر پیچیده باشد که خود ابزار به مانعی برای اجرای تست تبدیل شود.

در چنین شرایطی، گاهی یک ابزار ساده و قابل فهم می‌تواند انتخاب مناسب‌تری از یک سیستم بسیار پیچیده باشد.

مقیاس‌پذیری

ابزار انتخاب‌شده باید متناسب با اندازه فعلی و احتمالی آینده پروژه باشد.

ممکن است یک Spreadsheet برای یک پروژه کوچک مناسب باشد، اما با افزایش تعداد کاربران، Test Caseها، Defectها و Releaseها، نیاز به یک ابزار تخصصی‌تر ایجاد شود.

آیا برای UAT حتماً به ابزار تخصصی نیاز داریم؟

خیر. استفاده از ابزار تخصصی یک الزام عمومی برای UAT نیست.

در یک پروژه کوچک ممکن است یک Spreadsheet به‌خوبی نیازهای تیم را پوشش دهد. در مقابل، در پروژه‌های بزرگ با تعداد زیادی Test Case، Requirement، Defect و کاربر، استفاده از ابزار تخصصی می‌تواند مدیریت و Traceability را ساده‌تر کند.

بنابراین بهتر است ابتدا فرایند UAT و نیازهای تیم مشخص شوند و سپس ابزار مناسب انتخاب شود.

ابزار خوب چه مشکلی را در UAT حل می‌کند؟

یک ابزار مناسب می‌تواند به تیم کمک کند اطلاعات UAT را در یک جریان قابل پیگیری مدیریت کند:

Requirement → Acceptance Criteria → Test Scenario → Test Case → Execution → Defect → Retest → Result → Sign-off

این ارتباط باعث می‌شود مشخص باشد هر تست با کدام نیازمندی مرتبط است، چه نتیجه‌ای داشته، چه مشکلاتی ایجاد شده و در نهایت وضعیت پذیرش محصول چگونه تعیین شده است.

در نهایت، انتخاب ابزار باید بر اساس فرایند UAT و نیاز واقعی تیم انجام شود، نه صرفاً محبوبیت یک ابزار.

ابزار خوب، UAT را منظم‌تر و قابل‌پیگیری‌تر می‌کند؛ اما جایگزین Requirement مناسب، Acceptance Criteria مشخص و سناریوهای درست نمی‌شود.

UAT در Agile و Scrum چگونه انجام می‌شود؟

در پروژه‌های Agile، توسعه نرم‌افزار معمولاً به‌صورت تدریجی و در قالب Iteration یا Sprint انجام می‌شود. بنابراین UAT در Agile نیز لزوماً به یک مرحله بزرگ در انتهای کل پروژه محدود نیست و می‌تواند در سطح Feature، User Story، Sprint یا Release انجام شود.

در رویکرد Agile، بسیاری از فعالیت‌هایی که برای User Acceptance Testing لازم هستند از ابتدای توسعه مورد توجه قرار می‌گیرند؛ برای مثال، تعریف نیازمندی‌ها، مشخص کردن Acceptance Criteria و آماده‌سازی سناریوهای پذیرش.

هدف این است که بازخورد کاربر و کسب‌وکار تا حد امکان زود دریافت شود و پذیرش محصول به یک فعالیت ناگهانی در پایان پروژه تبدیل نشود.

UAT در Scrum چه تفاوتی با UAT سنتی دارد؟

در روش‌های سنتی ممکن است UAT به‌عنوان یک مرحله مشخص قبل از تحویل یا Release نهایی انجام شود. اما در Scrum، محصول در Incrementهای کوچک‌تر توسعه پیدا می‌کند و بنابراین امکان بررسی و دریافت بازخورد درباره قابلیت‌ها نیز می‌تواند به‌صورت تدریجی وجود داشته باشد.

به همین دلیل، UAT در Scrum می‌تواند در سطح یک User Story، مجموعه‌ای از User Storyها یا یک Release انجام شود.

رویکرد	نحوه انجام پذیرش
مدل سنتی	ممکن است UAT در یک مرحله مشخص قبل از تحویل نهایی انجام شود.
Agile / Scrum	پذیرش می‌تواند به‌صورت تدریجی در سطح User Story، Feature، Sprint یا Release انجام شود.

ارتباط UAT با User Story

در Scrum، نیازمندی‌ها معمولاً در قالب User Story بیان می‌شوند.

برای مثال:

به‌عنوان یک مشتری، می‌خواهم بتوانم سفارش خود را آنلاین پرداخت کنم تا خرید خود را بدون مراجعه حضوری تکمیل کنم.

این User Story هدف کاربر و ارزش مورد انتظار کسب‌وکار را مشخص می‌کند؛ اما برای اینکه بدانیم این قابلیت چه زمانی قابل پذیرش است، به Acceptance Criteria نیاز داریم.

ارتباط User Story و Acceptance Criteria

برای User Story بالا می‌توان Acceptance Criteria زیر را تعریف کرد:

• کاربر بتواند روش پرداخت آنلاین را انتخاب کند.
• مبلغ پرداختی با مبلغ سفارش مطابقت داشته باشد.
• پرداخت موفق باعث ثبت سفارش شود.
• شماره سفارش پس از پرداخت نمایش داده شود.
• وضعیت سفارش به‌درستی ثبت شود.

این معیارها می‌توانند مبنای طراحی Acceptance Test یا سناریوهای UAT قرار بگیرند.

بنابراین در Agile می‌توان این ارتباط را به شکل زیر مشاهده کرد:

User Story → Acceptance Criteria → Acceptance Test → Result

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

یک روش واحد برای تمام تیم‌های Agile وجود ندارد و زمان اجرای UAT به فرایند سازمان، نوع محصول و نحوه تعریف پذیرش بستگی دارد.

در برخی تیم‌ها، پذیرش یک User Story در همان Sprint و قبل از بسته شدن آن بررسی می‌شود. در برخی پروژه‌ها نیز UAT رسمی‌تر در سطح یک Feature یا Release انجام می‌شود.

برای مثال، ممکن است جریان کار یک User Story به شکل زیر باشد:

Development → QA Testing → Business/User Acceptance → Story Acceptance

یا در سطح Release:

Feature Development → QA → UAT → Release

بنابراین نباید تصور کرد که UAT در Agile همیشه فقط در آخرین روز Sprint انجام می‌شود.

UAT در Sprint چگونه می‌تواند اجرا شود؟

یکی از روش‌های مناسب این است که سناریوهای پذیرش قبل از پایان توسعه آماده باشند تا پس از آماده شدن قابلیت، تیم بتواند بدون تأخیر وارد مرحله Acceptance Testing شود.

مرحله	فعالیت مرتبط با UAT
Refinement	بررسی User Story و Acceptance Criteria
Development	آماده‌سازی سناریوها و Test Data
QA Testing	بررسی کیفیت و رفع مشکلات اصلی
Business Acceptance	اجرای سناریوهای پذیرش
Defect Fix	رفع مشکلات شناسایی‌شده
Retest	بررسی مجدد قابلیت اصلاح‌شده
Acceptance	ثبت نتیجه و تصمیم پذیرش

نقش Acceptance Criteria در Agile UAT

Acceptance Criteria در Agile اهمیت زیادی دارد، زیرا معیار مشخصی برای بررسی قابل قبول بودن یک User Story ایجاد می‌کند.

فرض کنید User Story این باشد:

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

Acceptance Criteria می‌تواند شامل موارد زیر باشد:

1. کاربر بتواند سفارش واجد شرایط را لغو کند.
2. سیستم قبل از لغو، تأیید کاربر را دریافت کند.
3. وضعیت سفارش پس از لغو به «لغوشده» تغییر کند.
4. در صورت پرداخت قبلی، فرایند بازگشت وجه مطابق قوانین کسب‌وکار انجام شود.
5. سفارش لغوشده دیگر وارد فرایند ارسال نشود.

تستر می‌تواند از این معیارها برای طراحی Acceptance Test یا UAT Scenario استفاده کند و بررسی کند که قابلیت از دید کسب‌وکار شرایط موردنظر را برآورده می‌کند یا خیر.

آیا Definition of Done همان UAT است؟

خیر. Definition of Done یا DoD و UAT دو مفهوم متفاوت هستند، هرچند می‌توانند با یکدیگر ارتباط داشته باشند.

Definition of Done مجموعه شرایطی است که تیم بر اساس آن مشخص می‌کند یک User Story یا Increment چه زمانی «انجام‌شده» محسوب می‌شود.

در مقابل، UAT روی پذیرش قابلیت از دید کاربر یا کسب‌وکار تمرکز دارد.

مورد	Definition of Done	UAT
تمرکز	کامل شدن کار بر اساس معیارهای تیم	قابل پذیرش بودن محصول از دید کاربر و کسب‌وکار
مثال	Code Review، تست‌ها و مستندات انجام شده‌اند.	کاربر می‌تواند فرایند واقعی کسب‌وکار را با موفقیت انجام دهد.
سؤال اصلی	آیا این User Story طبق Definition of Done تکمیل شده است؟	آیا این قابلیت از دید کسب‌وکار قابل پذیرش است؟

بنابراین:

DoD مشخص می‌کند تیم چه شرایطی را برای Done شدن کار لازم می‌داند؛ UAT بررسی می‌کند محصول از دید کاربر و کسب‌وکار قابل پذیرش است یا خیر.

نقش تستر در UAT در محیط Agile

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

هنگام بررسی User Story

• آیا User Story واضح است؟
• آیا Acceptance Criteria کامل است؟
• آیا معیارها قابل تست هستند؟
• آیا شرایط منفی و Edge Caseهای مهم مشخص شده‌اند؟

هنگام توسعه

• آماده‌سازی Test Scenarioها
• مشخص کردن Test Data موردنیاز
• بررسی پیش‌نیازهای محیط UAT در صورت نیاز

هنگام اجرای UAT

• پشتیبانی از اجرای سناریوها
• ثبت نتایج تست
• ثبت و پیگیری Defectها
• تفکیک مشکلات محیطی از مشکلات نرم‌افزار

پس از اصلاح Defect

• اجرای Retest
• بررسی نتیجه اصلاح
• در صورت نیاز، اجرای تست‌های مرتبط

این رویکرد باعث می‌شود تست و پذیرش محصول در انتهای کار به یک فعالیت ناگهانی تبدیل نشود.

UAT در Releaseهای Agile

در پروژه‌هایی که چند User Story در یک Release قرار دارند، ممکن است UAT در سطح Release نیز انجام شود.

برای مثال، فرض کنید نسخه جدید فروشگاه اینترنتی شامل این قابلیت‌ها باشد:

• ثبت سفارش
• پرداخت آنلاین
• لغو سفارش
• بازگشت وجه

در این حالت ممکن است هر User Story به‌صورت جداگانه تست شود، اما قبل از انتشار Release نیز چند سناریوی End-to-End بررسی شوند.

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

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

مزایای UAT در Agile

اجرای مناسب UAT در Agile می‌تواند مزایای مختلفی برای تیم فنی و کسب‌وکار داشته باشد:

• دریافت بازخورد زودتر از کسب‌وکار
• کاهش ریسک انباشته شدن مشکلات تا پایان پروژه
• شفاف‌تر شدن Acceptance Criteria
• ارتباط بهتر بین تیم فنی و کسب‌وکار
• شناسایی زودتر فاصله بین محصول و نیاز واقعی کاربر
• امکان اصلاح سریع‌تر قابلیت‌ها
• کاهش احتمال کشف نیازهای مهم کسب‌وکار در مراحل پایانی

در واقع یکی از مزیت‌های اصلی Agile این است که لازم نیست برای دریافت بازخورد درباره محصول تا پایان پروژه صبر کنیم.

یک مثال ساده از UAT در Sprint

فرض کنیم در یک Sprint قابلیت «لغو سفارش» توسعه داده شده است.

User Story

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

Acceptance Criteria

• فقط سفارش‌های واجد شرایط قابل لغو باشند.
• کاربر قبل از لغو تأیید کند.
• وضعیت سفارش به «لغوشده» تغییر کند.
• در صورت نیاز، فرایند بازگشت وجه آغاز شود.

UAT Scenario

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

Expected Result

سفارش لغو شود، وضعیت آن تغییر کند و در صورت وجود شرایط لازم، فرایند بازگشت وجه آغاز شود.

نتیجه UAT

اگر سناریو مطابق معیارهای پذیرش اجرا شود، قابلیت می‌تواند از دید کسب‌وکار پذیرفته شود. اگر مشکلی وجود داشته باشد، Defect ثبت شده و پس از اصلاح، Retest انجام می‌شود.

UAT در Agile چه زمانی موفق است؟

موفقیت UAT در Agile فقط به تعداد Test Caseهای Pass شده وابسته نیست. مهم‌تر از تعداد تست‌ها این است که قابلیت موردنظر واقعاً نیاز کسب‌وکار را برآورده کند.

• آیا Acceptance Criteria برآورده شده‌اند؟
• آیا فرایند اصلی کسب‌وکار بدون مشکل انجام می‌شود؟
• آیا Defect مهمی باقی مانده است؟
• آیا ریسک‌های باقی‌مانده برای کسب‌وکار قابل پذیرش هستند؟
• آیا ذی‌نفع مسئول نتیجه را تأیید می‌کند؟

بنابراین در Agile نیز باید معیارهای پذیرش و شرایط تصمیم‌گیری از قبل تا حد امکان مشخص باشند.

UAT در Agile را چگونه بهتر اجرا کنیم؟

برای اجرای مؤثر UAT در محیط Agile بهتر است فعالیت‌های مرتبط با پذیرش از ابتدای چرخه توسعه در نظر گرفته شوند.

• Acceptance Criteria از ابتدا مشخص باشند.
• تستر در Refinement و بررسی User Story مشارکت داشته باشد.
• سناریوهای پذیرش قبل از پایان توسعه آماده شوند.
• کاربران یا نمایندگان کسب‌وکار به‌موقع درگیر شوند.
• Test Data و Environment از قبل آماده باشند.
• Feedback سریعاً به تیم توسعه منتقل شود.
• Defectها با اولویت مناسب پیگیری شوند.
• پس از رفع مشکلات، Retest انجام شود.
• معیارهای پذیرش قبل از Release به‌صورت شفاف بررسی شوند.
• نتیجه پذیرش و ریسک‌های باقی‌مانده مستند شوند.

سؤالات متداول درباره UAT در Agile و Scrum

آیا UAT در Agile فقط در پایان پروژه انجام می‌شود؟

خیر. UAT می‌تواند در سطح User Story، Feature، Sprint یا Release انجام شود و زمان دقیق آن به فرایند سازمان و نحوه تعریف پذیرش بستگی دارد.

آیا Definition of Done همان Acceptance Criteria است؟

خیر. Acceptance Criteria شرایط پذیرش یک قابلیت را مشخص می‌کند، در حالی که Definition of Done شرایطی را مشخص می‌کند که تیم برای Done شدن یک User Story یا Increment در نظر گرفته است.

آیا تستر باید UAT را اجرا کند؟

تستر می‌تواند در طراحی، آماده‌سازی، پشتیبانی و حتی اجرای تست‌های پذیرش نقش داشته باشد؛ اما تصمیم نهایی درباره پذیرش محصول معمولاً به ذی‌نفع کسب‌وکار، Product Owner، مشتری یا نقش مسئول پذیرش در سازمان بستگی دارد.

آیا UAT باید قبل از پایان Sprint انجام شود؟

الزام واحدی وجود ندارد. در برخی تیم‌ها پذیرش User Story در همان Sprint انجام می‌شود و در برخی پروژه‌ها UAT در سطح Feature یا Release انجام می‌شود.

مهم‌ترین تفاوت UAT و QA در Agile چیست؟

QA بیشتر کیفیت و رفتار نرم‌افزار را در برابر الزامات و معیارهای تست بررسی می‌کند، در حالی که UAT بر این تمرکز دارد که آیا محصول از دید کاربر و کسب‌وکار برای استفاده و پذیرش مناسب است یا خیر.

در Agile، UAT می‌تواند از یک مرحله نهایی به یک فعالیت مستمر برای دریافت بازخورد، اعتبارسنجی نیازهای کسب‌وکار و اطمینان از ارزش واقعی محصول تبدیل شود.

تفاوت UAT با QA و مسئولیت هر نقش در فرایند پذیرش

یکی از اشتباهات رایج این است که UAT را همان QA Testing در نظر بگیریم. هر دو با کیفیت نرم‌افزار ارتباط دارند، اما هدف، تمرکز و مسئولیت‌های متفاوتی دارند.

QA بیشتر به این سؤال می‌پردازد:

آیا نرم‌افزار مطابق الزامات و معیارهای فنی و کیفی تعریف‌شده کار می‌کند؟

در حالی که UAT بیشتر به این سؤال پاسخ می‌دهد:

آیا نرم‌افزار نیاز واقعی کاربر و کسب‌وکار را برآورده می‌کند و برای پذیرش آماده است؟

تفاوت QA Testing و UAT

برای درک بهتر تفاوت این دو، می‌توان هدف، اجراکننده، نوع تست و خروجی آنها را با یکدیگر مقایسه کرد.

مورد	QA Testing	UAT
هدف اصلی	بررسی کیفیت و رفتار نرم‌افزار	بررسی پذیرش محصول از دید کاربر و کسب‌وکار
تمرکز	Functional، Integration، Regression و سایر تست‌ها	فرایندها و نیازهای واقعی کسب‌وکار
اجراکننده معمول	QA/Test Engineer یا سایر اعضای تیم تست	کاربران کسب‌وکار یا نمایندگان آنها
Test Case	معمولاً جزئی‌تر و گسترده‌تر	بیشتر مبتنی بر سناریوهای واقعی کسب‌وکار
زمان اجرا	در طول چرخه توسعه	بسته به پروژه، قبل از Release یا در طول توسعه
معیار ارزیابی	Requirement، Specification و معیارهای تست	Acceptance Criteria و نیاز کسب‌وکار
خروجی	اطلاعات درباره کیفیت، پوشش تست و Defectها	شواهد و نتیجه مربوط به پذیرش محصول
نتیجه نهایی	وضعیت کیفیت محصول	Accepted، Not Accepted یا تصمیم مشابه

البته این تقسیم‌بندی مطلق نیست و در سازمان‌های مختلف ممکن است مسئولیت‌ها و نحوه اجرای QA و UAT متفاوت باشد.

آیا Tester می‌تواند مسئول UAT باشد؟

پاسخ این سؤال به فرایند سازمان بستگی دارد. تستر می‌تواند نقش بسیار مهمی در طراحی، آماده‌سازی، پشتیبانی و حتی اجرای UAT داشته باشد، اما تصمیم نهایی درباره پذیرش محصول لزوماً بر عهده تستر نیست.

• بررسی Acceptance Criteria
• طراحی سناریوهای UAT
• آماده‌سازی Test Case
• بررسی محیط UAT
• آماده‌سازی Test Data
• پشتیبانی از اجرای تست
• ثبت و پیگیری Defect
• انجام Retest
• تهیه گزارش UAT

اما تصمیم نهایی درباره پذیرش کسب‌وکار ممکن است بر عهده Product Owner، Business User، Customer یا ذی‌نفع مسئول باشد.

بنابراین بهتر است بین اجرای تست و تصمیم پذیرش تفاوت قائل شویم.

UAT Execution و UAT Acceptance چه تفاوتی دارند؟

یکی از نکات مهم در تعیین مسئولیت‌های UAT این است که «چه کسی تست را اجرا می‌کند؟» با «چه کسی درباره پذیرش تصمیم می‌گیرد؟» یک سؤال نیست.

مفهوم	سؤال اصلی	مسئول معمول
UAT Execution	چه کسی سناریوها را اجرا و نتایج را ثبت می‌کند؟	Business User، Tester یا نماینده کسب‌وکار
UAT Acceptance	چه کسی درباره قابل پذیرش بودن محصول تصمیم می‌گیرد؟	Product Owner، Customer یا ذی‌نفع مسئول

این دو نقش الزاماً متعلق به یک نفر نیستند. در برخی سازمان‌ها تستر اجرای UAT را مدیریت می‌کند، اما تصمیم نهایی پذیرش توسط کسب‌وکار انجام می‌شود.

نقش Tester در UAT

تستر می‌تواند در تمام مراحل UAT نقش تسهیل‌کننده و کنترل‌کننده کیفیت را داشته باشد.

قبل از UAT

• بررسی Requirementها
• تحلیل Acceptance Criteria
• طراحی سناریوهای UAT
• آماده‌سازی Test Caseها
• مشخص کردن Test Data
• بررسی آمادگی Environment

هنگام اجرای UAT

• پشتیبانی از اجرای سناریوها
• ثبت نتایج تست
• ثبت و پیگیری Defectها
• تفکیک مشکلات محیطی از مشکلات نرم‌افزار
• به‌روزرسانی وضعیت Test Caseها

بعد از UAT

• انجام Retest
• بررسی وضعیت Defectها
• تهیه گزارش UAT
• کنترل Traceability بین Requirement و Test
• مستندسازی نتایج نهایی

نقش Developer در UAT

Developer معمولاً مسئول اجرای اصلی UAT نیست، اما نقش مهمی در پشتیبانی فنی از این فرایند دارد.

• رفع Defectهای پیدا شده در UAT
• بررسی Logها
• تحلیل مشکلات فنی
• Deploy نسخه اصلاح‌شده
• پاسخ به سؤالات فنی تیم تست

همکاری سریع بین Tester و Developer می‌تواند زمان بررسی و رفع مشکلات پیدا شده در UAT را کاهش دهد.

نقش Product Owner در UAT

در تیم‌های Agile، Product Owner معمولاً ارتباط نزدیکی با نیازهای کسب‌وکار و ارزش محصول دارد.

• تعریف یا تأیید نیازمندی‌ها
• مشارکت در تعریف Acceptance Criteria
• بررسی نتیجه Acceptance Test
• اولویت‌بندی مشکلات از دید محصول
• مشارکت در تصمیم‌گیری درباره پذیرش قابلیت

با این حال، مسئولیت دقیق Product Owner در UAT به ساختار سازمان و پروژه بستگی دارد.

نقش Business User در UAT

Business User یا نماینده کسب‌وکار می‌تواند یکی از مهم‌ترین افراد در UAT باشد؛ زیرا شناخت او از فرایند واقعی کسب‌وکار به ارزیابی قابلیت کمک می‌کند.

برای مثال، در یک سیستم حسابداری، کاربر مالی ممکن است بهتر از یک تستر بتواند تشخیص دهد که:

آیا فرایند ثبت و تأیید یک سند مالی مطابق روش واقعی سازمان است؟

تستر می‌تواند عملکرد سیستم را بررسی کند، اما شناخت فرایند واقعی کسب‌وکار یکی از نقاط قوت Business User است.

نقش Customer در UAT

در برخی پروژه‌ها، به‌خصوص پروژه‌های سفارشی، مشتری یا نماینده مشتری نیز ممکن است در UAT حضور داشته باشد.

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

در چنین پروژه‌ای، UAT می‌تواند نقش مهمی در تصمیم‌گیری برای تحویل نهایی محصول داشته باشد.

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

جدول زیر یک الگوی عمومی برای درک مسئولیت نقش‌های مختلف در UAT ارائه می‌کند. این تقسیم‌بندی در هر سازمان ممکن است متفاوت باشد.

نقش	مسئولیت معمول در UAT
Tester / QA	طراحی تست، آماده‌سازی، اجرا، ثبت Defect و گزارش
Developer	رفع مشکلات و پشتیبانی فنی
Product Owner	نمایندگی نیاز محصول و مشارکت در پذیرش
Business User	ارزیابی فرایندها از دید کسب‌وکار
Customer	تأیید محصول در صورت وجود فرایند پذیرش مشتری
Project/Product Manager	هماهنگی، پیگیری و تصمیم‌گیری در سطح پروژه در صورت نیاز

چه کسی مسئول نهایی UAT است؟

نمی‌توان یک پاسخ واحد برای تمام سازمان‌ها ارائه کرد. در بعضی سازمان‌ها Business User مسئول اجرای UAT است، در بعضی تیم‌ها Product Owner یا نماینده مشتری تصمیم پذیرش را می‌گیرد و در برخی پروژه‌ها QA یا Test Manager مسئول هماهنگی و گزارش‌دهی UAT است.

بنابراین مهم‌تر از تعیین یک عنوان شغلی ثابت، مشخص کردن مسئولیت‌هاست:

• چه کسی UAT را اجرا می‌کند؟
• چه کسی Defectها را پیگیری می‌کند؟
• چه کسی نتیجه را تأیید می‌کند؟
• چه کسی تصمیم نهایی درباره Acceptance می‌گیرد؟
• چه کسی Sign-off را انجام می‌دهد؟

آیا UAT بخشی از QA است؟

از نظر فرایندی، UAT می‌تواند بخشی از چرخه کلی تضمین کیفیت و اعتبارسنجی محصول باشد، اما از نظر هدف و مسئولیت با تست‌های معمول QA تفاوت دارد.

QA می‌تواند بررسی کند که نرم‌افزار مطابق معیارهای مشخص عملکرد مناسبی دارد، در حالی که UAT کمک می‌کند مشخص شود آیا محصول از دید کاربر و کسب‌وکار برای استفاده و پذیرش مناسب است یا خیر.

بنابراین بهتر است UAT را نه جایگزین QA بدانیم و نه کاملاً از فرایند کیفیت جدا کنیم.

مثال عملی برای درک تفاوت QA و UAT

فرض کنید یک سیستم فروش بلیت طراحی شده است.

تستر بررسی می‌کند:

آیا کاربر می‌تواند بلیت را انتخاب و خریداری کند؟

اما Business User ممکن است سؤال متفاوتی داشته باشد:

آیا فرایند فروش بلیت دقیقاً مطابق قوانین و فرایند کاری شرکت است؟

ممکن است سیستم از نظر فنی کاملاً درست کار کند، اما یکی از قوانین کسب‌وکار در فرایند پیاده‌سازی نشده باشد.

در این حالت ممکن است نتیجه به شکل زیر باشد:

QA Test → Pass

UAT → Fail

این مثال نشان می‌دهد که ممکن است نرم‌افزار از نظر فنی عملکرد مناسبی داشته باشد، اما هنوز از دید کسب‌وکار قابل پذیرش نباشد.

جمع‌بندی مسئولیت‌ها

به‌صورت ساده می‌توان گفت:

• Tester / QA: کیفیت و رفتار سیستم را بررسی می‌کند و می‌تواند اجرای UAT را تسهیل و مدیریت کند.
• Business User: بررسی می‌کند که سیستم برای فرایند واقعی کسب‌وکار مناسب است.
• Developer: مشکلات فنی شناسایی‌شده را برطرف می‌کند.
• Product Owner یا ذی‌نفع مسئول: بسته به ساختار پروژه، در تصمیم پذیرش محصول نقش دارد.

در نهایت، UAT یک فعالیت کاملاً فردی نیست؛ بلکه نتیجه همکاری بین تیم فنی، تیم تست و کسب‌وکار است.

نکته کلیدی: اجرای UAT و تصمیم درباره پذیرش محصول الزاماً توسط یک نفر انجام نمی‌شود. مهم این است که نقش‌ها، مسئولیت‌ها و اختیار تصمیم‌گیری از ابتدا مشخص باشند.

انواع تست پذیرش (Acceptance Testing)

Acceptance Testing یک مفهوم گسترده برای ارزیابی قابل‌قبول بودن یک محصول، سیستم یا قابلیت بر اساس معیارهای از پیش تعیین‌شده است. User Acceptance Testing (UAT) یکی از شناخته‌شده‌ترین انواع تست پذیرش محسوب می‌شود.

بسته به هدف تست، معیارهای پذیرش، نوع محصول و اینکه چه فرد یا سازمانی محصول را ارزیابی می‌کند، ممکن است انواع مختلفی از Acceptance Testing یا فعالیت‌های مرتبط با پذیرش در یک پروژه وجود داشته باشد.

مهم‌ترین مواردی که ممکن است در این زمینه با آنها مواجه شوید عبارت‌اند از:

• User Acceptance Testing (UAT)
• Business Acceptance Testing (BAT)
• Contract Acceptance Testing
• Regulatory Acceptance Testing
• Operational Acceptance Testing (OAT)
• Alpha Testing
• Beta Testing

البته نام‌گذاری و نحوه تفکیک این فعالیت‌ها ممکن است بین سازمان‌ها، پروژه‌ها و منابع مختلف متفاوت باشد. بنابراین بهتر است علاوه بر نام تست، هدف، معیار پذیرش، اجراکننده و تصمیم‌گیرنده نهایی نیز مشخص شود.

1. User Acceptance Testing (UAT)

User Acceptance Testing یا UAT با هدف بررسی این موضوع انجام می‌شود که آیا محصول نیازهای واقعی کاربران و کسب‌وکار را برآورده می‌کند و برای استفاده یا پذیرش موردنظر مناسب است یا خیر.

در UAT معمولاً به جای تمرکز صرف بر جزئیات فنی، سناریوهای واقعی کسب‌وکار و فرایندهایی که کاربران در دنیای واقعی انجام می‌دهند بررسی می‌شوند.

مثال UAT

فرض کنید یک سیستم فروش آنلاین برای یک شرکت ساخته شده است. کاربر کسب‌وکار می‌تواند بررسی کند که آیا فرایند خرید مطابق نیاز واقعی سازمان انجام می‌شود یا خیر.

• ثبت سفارش
• پرداخت آنلاین
• مشاهده وضعیت سفارش
• لغو سفارش
• بررسی فرایند بازگشت وجه

اگر فرایندهای موردنظر مطابق Acceptance Criteria و نیازهای کسب‌وکار انجام شوند، محصول می‌تواند از منظر UAT قابل پذیرش باشد.

2. Business Acceptance Testing (BAT)

Business Acceptance Testing یا BAT بیشتر بر این موضوع تمرکز دارد که آیا سیستم از فرایندها، اهداف و نیازهای کسب‌وکار پشتیبانی می‌کند یا خیر.

سؤال اصلی در BAT می‌تواند این باشد:

آیا سیستم از فرایند و اهداف کسب‌وکار موردنظر به شکل صحیح پشتیبانی می‌کند؟

برای مثال، در یک سیستم منابع انسانی ممکن است بررسی شود که آیا فرایند استخدام، تأیید درخواست، ثبت اطلاعات کارکنان و گردش کار مربوط به آنها مطابق فرایند سازمان انجام می‌شود یا خیر.

در بعضی سازمان‌ها BAT و UAT تقریباً به یک معنا استفاده می‌شوند و در برخی دیگر بین آنها تفاوت قائل می‌شوند. بنابراین تعریف دقیق این اصطلاح باید بر اساس فرایند سازمان مشخص شود.

3. Contract Acceptance Testing

در پروژه‌هایی که محصول بر اساس یک قرارداد بین مشتری و ارائه‌دهنده توسعه داده می‌شود، ممکن است معیارهای پذیرش و تعهدات فنی یا کسب‌وکاری در قرارداد مشخص شده باشند.

در این شرایط، Acceptance Testing می‌تواند بررسی کند که آیا محصول شرایط و تعهدات توافق‌شده در قرارداد را برآورده کرده است یا خیر.

مثال Contract Acceptance Testing

فرض کنید در قرارداد توسعه یک نرم‌افزار مشخص شده باشد که:

• سیستم باید قابلیت مشخصی را ارائه کند.
• گزارش مشخصی را تولید کند.
• تعداد معینی کاربر را پشتیبانی کند.
• فرایند مشخصی را مطابق شرایط توافق‌شده انجام دهد.

در این حالت، تست پذیرش قراردادی می‌تواند شواهدی فراهم کند که نشان دهد محصول الزامات توافق‌شده را برآورده کرده است.

4. Regulatory Acceptance Testing

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

در چنین شرایطی ممکن است فعالیت‌هایی با هدف بررسی پذیرش یا انطباق محصول با الزامات قانونی انجام شوند.

این موضوع در حوزه‌هایی مانند موارد زیر اهمیت بیشتری پیدا می‌کند:

• بانکداری
• بیمه
• سلامت
• داروسازی
• حمل‌ونقل
• صنایع دارای الزامات قانونی و نظارتی

مثال Regulatory Acceptance Testing

فرض کنید یک سیستم مالی باید الزامات مشخصی برای ثبت، نگهداری و گزارش تراکنش‌ها رعایت کند.

در این حالت، فقط درست کار کردن قابلیت‌ها کافی نیست؛ بلکه باید مشخص شود سیستم الزامات قانونی و نظارتی مرتبط را نیز برآورده می‌کند.

5. Operational Acceptance Testing (OAT)

Operational Acceptance Testing یا OAT روی آمادگی سیستم برای بهره‌برداری در محیط واقعی تمرکز دارد.

سؤال اصلی در OAT می‌تواند این باشد:

آیا سیستم از نظر عملیاتی برای ورود به محیط Production و ادامه فعالیت در شرایط واقعی آماده است؟

بسته به نیاز پروژه، مواردی مانند زیر ممکن است در OAT بررسی شوند:

• Backup و Restore
• Monitoring
• Logging
• Disaster Recovery
• مدیریت دسترسی‌ها
• Deployment
• Rollback
• Maintenance
• Performance در شرایط عملیاتی موردنیاز

مثال تفاوت UAT و OAT

ممکن است یک نرم‌افزار از دید کاربر کاملاً درست کار کند، اما فرآیند Backup آن به‌درستی تنظیم نشده باشد.

در این شرایط ممکن است:

UAT → Pass

اما:

OAT → Fail

زیرا UAT بیشتر به پذیرش محصول از دید کاربر و کسب‌وکار توجه دارد، در حالی که OAT آمادگی عملیاتی سیستم را بررسی می‌کند.

6. Alpha Testing

Alpha Testing معمولاً قبل از انتشار گسترده محصول و در یک محیط کنترل‌شده انجام می‌شود.

در این مرحله ممکن است محصول توسط کارکنان سازمان، تیم داخلی یا گروه محدودی از افراد مورد بررسی قرار گیرد تا مشکلات مهم قبل از انتشار برای کاربران گسترده‌تر شناسایی شوند.

مثال Alpha Testing

فرض کنید یک شرکت نرم‌افزاری نسخه جدید یک اپلیکیشن را آماده کرده است. قبل از انتشار عمومی، نسخه موردنظر در اختیار کارکنان یا یک گروه داخلی قرار می‌گیرد تا قابلیت‌ها و مشکلات احتمالی بررسی شوند.

نکته: Alpha Testing لزوماً همان UAT نیست. ممکن است در یک پروژه Alpha Testing با فعالیت‌های پذیرش هم‌پوشانی داشته باشد، اما هدف و تعریف آن می‌تواند متفاوت باشد.

7. Beta Testing

در Beta Testing نسخه‌ای از محصول در اختیار گروهی از کاربران واقعی یا نزدیک به کاربران واقعی قرار می‌گیرد تا محصول در شرایط واقعی‌تر مورد استفاده قرار گیرد.

یکی از اهداف Beta Testing می‌تواند جمع‌آوری Feedback و شناسایی مشکلاتی باشد که ممکن است در محیط کنترل‌شده داخلی مشاهده نشده باشند.

مثال Beta Testing

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

نکته: استفاده کاربران واقعی از یک نسخه Beta به‌تنهایی به معنی انجام UAT رسمی نیست. UAT بر پذیرش محصول بر اساس نیازها و معیارهای مشخص تمرکز دارد.

تفاوت انواع Acceptance Testing

برای درک بهتر تفاوت این مفاهیم، می‌توان آنها را به‌صورت زیر مقایسه کرد:

نوع	تمرکز اصلی	سؤال کلیدی
UAT	کاربر و کسب‌وکار	آیا محصول نیازهای کاربر و کسب‌وکار را برآورده می‌کند؟
BAT	فرایند و اهداف کسب‌وکار	آیا سیستم از فرایندهای کسب‌وکار پشتیبانی می‌کند؟
Contract Acceptance	تعهدات قراردادی	آیا شرایط توافق‌شده در قرارداد برآورده شده‌اند؟
Regulatory Acceptance	قوانین و الزامات نظارتی	آیا الزامات قانونی و نظارتی رعایت شده‌اند؟
OAT	عملیات	آیا سیستم برای بهره‌برداری در محیط واقعی آماده است؟
Alpha Testing	تست کنترل‌شده پیش از انتشار	محصول در محیط داخلی یا کنترل‌شده چه مشکلاتی دارد؟
Beta Testing	کاربران واقعی یا محدود	محصول در شرایط واقعی‌تر چگونه عمل می‌کند؟

این جدول یک تقسیم‌بندی مفهومی است. در پروژه‌های واقعی ممکن است برخی از این فعالیت‌ها با نام متفاوت یا در قالب یک فرایند واحد انجام شوند.

آیا Alpha و Beta همان UAT هستند؟

خیر. هرچند ممکن است بین آنها هم‌پوشانی وجود داشته باشد، اما این اصطلاحات یک مفهوم واحد را بیان نمی‌کنند.

UAT بر پذیرش محصول از دید کاربر یا کسب‌وکار بر اساس نیازها، سناریوها و معیارهای مشخص تمرکز دارد.

در مقابل، Alpha و Beta Testing بیشتر به مرحله، محیط و گروه افرادی که محصول را بررسی می‌کنند مربوط می‌شوند.

یک نسخه Beta ممکن است توسط کاربران واقعی استفاده شود، اما این موضوع به‌تنهایی به معنای انجام UAT رسمی نیست.

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

UAT و OAT هر دو می‌توانند در مسیر آماده‌سازی محصول برای انتشار اهمیت داشته باشند، اما سؤال متفاوتی را پاسخ می‌دهند.

در UAT تمرکز بیشتر روی این سؤال است:

آیا محصول نیازهای کاربر و کسب‌وکار را برآورده می‌کند؟

در OAT تمرکز بیشتر روی این سؤال است:

آیا سیستم از نظر عملیاتی برای استفاده در محیط Production آماده است؟

مثال

UAT:

آیا کارمند می‌تواند درخواست مرخصی خود را مطابق فرایند سازمان ثبت و پیگیری کند؟

OAT:

آیا سیستم Backup مناسب دارد و در صورت بروز مشکل می‌توان سرویس را بازیابی کرد؟

بنابراین ممکن است یک سیستم از نظر UAT پذیرفته شود، اما هنوز از نظر عملیاتی برای Production آماده نباشد.

Acceptance Testing را با چه سؤالاتی تحلیل کنیم؟

در منابع و سازمان‌های مختلف ممکن است نام‌ها و مرزبندی‌های متفاوتی برای انواع Acceptance Testing وجود داشته باشد. به همین دلیل، بهتر است هنگام مواجهه با اصطلاحاتی مانند UAT، BAT، OAT یا Contract Acceptance فقط به نام آنها اکتفا نکنیم.

برای درک دقیق هر فعالیت پذیرش، چهار سؤال اصلی را مطرح کنید:

1. چه چیزی قرار است پذیرفته شود؟
2. بر اساس چه معیارهایی قرار است پذیرش انجام شود؟
3. چه کسی محصول یا قابلیت را ارزیابی می‌کند؟
4. چه کسی درباره پذیرش نهایی تصمیم می‌گیرد؟

پاسخ به این چهار سؤال کمک می‌کند حتی اگر سازمان از اصطلاحات متفاوتی استفاده کند، هدف و مسئولیت هر فعالیت به‌درستی مشخص شود.

جمع‌بندی انواع تست پذیرش

Acceptance Testing فقط به یک نوع تست محدود نمی‌شود. UAT بیشتر بر پذیرش محصول از دید کاربر و کسب‌وکار تمرکز دارد، در حالی که فعالیت‌هایی مانند Contract Acceptance، Regulatory Acceptance و OAT می‌توانند جنبه‌های دیگری از پذیرش محصول را بررسی کنند.

همچنین Alpha و Beta Testing را نباید صرفاً به‌عنوان معادل UAT در نظر گرفت؛ زیرا این اصطلاحات بیشتر به محیط، مرحله و گروه کاربران درگیر در تست اشاره دارند و ممکن است در برخی پروژه‌ها با فرایند پذیرش هم‌پوشانی داشته باشند.

مهم‌تر از نام تست، این است که مشخص باشد چه چیزی قرار است پذیرفته شود، معیار پذیرش چیست، چه کسی آن را ارزیابی می‌کند و چه کسی تصمیم نهایی را می‌گیرد.

UAT Metrics؛ شاخص‌های مهم برای اندازه‌گیری UAT

اجرای UAT فقط به ثبت Pass و Fail محدود نمی‌شود. در پروژه‌های واقعی، تیم باید بتواند وضعیت UAT را به شکل قابل اندازه‌گیری گزارش و تحلیل کند.

برای این کار از UAT Metrics یا شاخص‌های اندازه‌گیری UAT استفاده می‌شود.

این شاخص‌ها به تیم کمک می‌کنند متوجه شود:

• چه مقدار از تست‌ها انجام شده است؟
• چه تعداد تست موفق یا ناموفق بوده‌اند؟
• چه مشکلاتی باقی مانده است؟
• آیا Acceptance Criteria پوشش داده شده‌اند؟
• آیا سناریوهای مهم کسب‌وکار بررسی شده‌اند؟
• آیا شواهد کافی برای تصمیم‌گیری درباره پذیرش محصول وجود دارد؟

البته هیچ Metric واحدی به‌تنهایی نمی‌تواند موفقیت UAT را مشخص کند. بهتر است چند شاخص در کنار یکدیگر و با توجه به Business Impact، Risk و Criticality تفسیر شوند.

1. تعداد Test Caseهای اجراشده

یکی از ساده‌ترین شاخص‌ها، تعداد Test Caseهایی است که اجرا شده‌اند.

برای مثال:

Total Test Cases: 100
Executed: 90
Not Executed: 10

این شاخص نشان می‌دهد چه مقدار از برنامه تست اجرا شده است.

اما باید توجه داشت که اجرای تعداد زیادی Test Case لزوماً به معنی کیفیت بالای UAT نیست؛ زیرا ممکن است Test Caseهای کم‌اهمیت اجرا شده باشند و یک سناریوی حیاتی کسب‌وکار هنوز بررسی نشده باشد.

2. Pass Rate

Pass Rate نشان می‌دهد چه درصدی از Test Caseهای اجراشده موفق بوده‌اند.

فرمول ساده آن:

Pass Rate = Passed Test Cases ÷ Executed Test Cases × 100

برای مثال، اگر از 100 Test Case اجراشده، 92 مورد Pass شده باشند:

Pass Rate = 92%

این شاخص برای گزارش وضعیت کلی مفید است، اما نباید تنها معیار تصمیم‌گیری درباره پذیرش محصول باشد.

ممکن است Pass Rate بالا باشد، اما یک سناریوی بسیار مهم کسب‌وکار همچنان Fail باشد.

3. Fail Rate

Fail Rate درصد Test Caseهایی را نشان می‌دهد که در زمان اجرا با نتیجه مورد انتظار مطابقت نداشته‌اند.

فرمول:

Fail Rate = Failed Test Cases ÷ Executed Test Cases × 100

مثلاً:

• Executed = 100
• Failed = 8

در این صورت:

Fail Rate = 8%

Fail Rate بالا می‌تواند نشان‌دهنده وجود مشکلاتی در محصول، Test Data، Environment یا حتی طراحی Test Caseها باشد. بنابراین صرفاً مشاهده عدد Fail Rate کافی نیست و علت Fail شدن نیز باید بررسی شود.

4. Blocked Test Cases

گاهی یک Test Case نه Pass است و نه Fail، زیرا امکان اجرای آن وجود ندارد.

برای مثال:

• سرویس وابسته در دسترس نیست.
• Test Data موردنیاز وجود ندارد.
• دسترسی کاربر تنظیم نشده است.
• یک Defect مانع ادامه تست شده است.

در این حالت Test Case می‌تواند Blocked شود.

Status	Count
Passed	80
Failed	10
Blocked	5
Not Executed	5

وجود تعداد زیاد Test Caseهای Blocked می‌تواند نشانه وجود مشکل در Environment، Dependency، Test Data یا آمادگی UAT باشد.

5. Acceptance Criteria Coverage

یکی از Metricهای مهم برای UAT، بررسی میزان پوشش Acceptance Criteria است.

فرض کنید یک Feature دارای 20 Acceptance Criteria باشد و تست‌های طراحی‌شده 18 مورد از آنها را پوشش دهند.

در این صورت:

Acceptance Criteria Coverage = 18 ÷ 20 × 100 = 90%

این شاخص کمک می‌کند بدانیم چه مقدار از شرایط پذیرش واقعاً در تست‌ها پوشش داده شده است.

برای UAT، این شاخص می‌تواند از صرفاً شمردن تعداد Test Caseها اطلاعات ارزشمندتری ارائه دهد؛ زیرا ارتباط تست با معیارهای واقعی پذیرش را بهتر نشان می‌دهد.

6. Defect Count

تعداد Defectهای شناسایی‌شده نیز یکی از شاخص‌های مهم است.

برای مثال:

• Total Defects = 25
• Critical = 0
• High = 3
• Medium = 10
• Low = 12

اما صرفاً تعداد Defectها کافی نیست.

25 Defect کم‌اهمیت لزوماً وضعیت بدتری نسبت به 2 Defect Critical ایجاد نمی‌کند. بنابراین باید Severity، Business Impact و وضعیت Defectها نیز در کنار تعداد آنها بررسی شوند.

7. Open Critical Defects

یکی از مهم‌ترین شاخص‌ها در تصمیم‌گیری UAT می‌تواند تعداد Defectهای Critical باز باشد.

Open Critical Defects = 0

در برخی پروژه‌ها صفر بودن Defectهای Critical باز می‌تواند یکی از Exit Criteriaها باشد.

با این حال، این موضوع یک قانون عمومی برای تمام پروژه‌ها نیست. در برخی شرایط ممکن است یک Defect مهم با اطلاع و پذیرش ریسک توسط مسئول کسب‌وکار برای Release باقی بماند.

8. Defect Closure Rate

این شاخص نشان می‌دهد چه درصدی از Defectهای ثبت‌شده تا یک نقطه زمانی مشخص بسته شده‌اند.

فرمول نمونه:

Defect Closure Rate = Closed Defects ÷ Total Defects × 100

مثلاً اگر 20 Defect ثبت شده باشد و 18 مورد بسته شده باشند:

Defect Closure Rate = 90%

این Metric می‌تواند برای بررسی روند رسیدگی به Defectها مفید باشد، اما بهتر است در کنار Severity و Business Impact تفسیر شود.

9. Retest Pass Rate

بعد از رفع Defectها، باید آنها Retest شوند. یکی از شاخص‌های مفید این است که چه درصدی از Retestها موفق بوده‌اند.

مثلاً:

• Retest Executed = 20
• Retest Passed = 18
• Retest Failed = 2

در این حالت:

Retest Pass Rate = 90%

اگر این عدد پایین باشد، ممکن است نشان‌دهنده این باشد که برخی Defectها به‌طور کامل برطرف نشده‌اند یا Fixها باعث ایجاد مشکلات جدید شده‌اند.

10. Test Execution Progress

این Metric نشان می‌دهد UAT چه مقدار پیشرفت کرده است.

فرمول:

Execution Progress = Executed Test Cases ÷ Total Test Cases × 100

مثلاً:

• Total = 100
• Executed = 70

در نتیجه:

Execution Progress = 70%

این شاخص برای گزارش روزانه یا هفتگی وضعیت UAT مفید است؛ زیرا نشان می‌دهد چه مقدار از برنامه تست اجرا شده است.

یک نمونه Dashboard ساده UAT

فرض کنیم وضعیت یک پروژه به شکل زیر باشد:

Metric	Result
Total Test Cases	100
Executed	95
Passed	88
Failed	7
Blocked	0
Execution Progress	95%
Pass Rate	92.6%
Acceptance Criteria Coverage	100%
Total Defects	18
Open Critical Defects	0
Open High Defects	1
Retest Pass Rate	94%

با نگاه به این اطلاعات می‌توان تصویر بهتری از وضعیت UAT به دست آورد؛ اما برای تصمیم نهایی باید اهمیت سناریوهای Fail شده، Defectهای باز و ریسک‌های باقی‌مانده نیز بررسی شوند.

آیا Pass Rate بالا یعنی UAT موفق بوده است؟

خیر.

این یکی از مهم‌ترین نکات در استفاده از Metrics است.

فرض کنید:

Pass Rate = 98%

در نگاه اول وضعیت بسیار خوبی به نظر می‌رسد.

اما اگر دو Test Case Fail شده مربوط به این سناریو باشند:

مشتری نمی‌تواند پرداخت آنلاین انجام دهد.

در این حالت 98 درصد Pass Rate نمی‌تواند به‌تنهایی نشان دهد که محصول آماده پذیرش است.

بنابراین هنگام تحلیل UAT Metrics باید علاوه بر اعداد، Business Criticality، Business Impact و Risk را نیز در نظر گرفت.

Metrics را چگونه تفسیر کنیم؟

بهتر است به جای تمرکز روی یک عدد، چند شاخص را در کنار یکدیگر قرار دهیم.

برای مثال:

• Pass Rate بالا
• Acceptance Criteria Coverage بالا
• Critical Defect باز = 0
• سناریوهای حیاتی Pass شده‌اند
• ریسک‌های باقی‌مانده مشخص و پذیرفته شده‌اند

ترکیب این اطلاعات می‌تواند تصویر قابل‌اعتمادتری از وضعیت UAT نسبت به یک Metric منفرد ارائه دهد.

چه Metricهایی برای UAT مهم‌تر هستند؟

همه Metricها ارزش یکسانی ندارند و انتخاب آنها باید متناسب با هدف و شرایط پروژه انجام شود.

Metricهای ضروری

• Total / Executed Test Cases
• Pass / Fail / Blocked
• Pass Rate
• Acceptance Criteria Coverage
• Open Critical / High Defects
• وضعیت سناریوهای Critical
• نتیجه نهایی UAT

Metricهای تکمیلی

• Defect Closure Rate
• Retest Pass Rate
• Execution Progress
• Defect Trend

بنابراین لازم نیست گزارش UAT را با ده‌ها نمودار و عدد پر کنیم. هدف Metrics این است که وضعیت واقعی پذیرش محصول را شفاف‌تر کنند، نه اینکه گزارش را پیچیده‌تر کنند.

خطر استفاده نادرست از UAT Metrics

Metrics زمانی مفید هستند که برای درک وضعیت واقعی محصول استفاده شوند، نه اینکه تیم صرفاً برای بهتر نشان دادن اعداد، رفتار تست را تغییر دهد.

برای مثال، اگر تیم فقط بر افزایش Pass Rate تمرکز کند، ممکن است Test Caseهای ساده‌تر در اولویت قرار بگیرند و سناریوهای مهم کسب‌وکار کمتر مورد توجه قرار گیرند.

به همین دلیل Metrics باید در کنار Risk، Business Impact، Acceptance Criteria و Criticality تحلیل شوند.

یک نکته مهم برای تسترها

Metricها ابزار تصمیم‌گیری هستند، نه خود تصمیم.

برای مثال، تستر ممکن است گزارش کند:

«92 درصد Test Caseها Pass شده‌اند و هیچ Defect با Severity Critical باز نیست.»

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

«محصول برای Release تأیید شد.»

تصمیم نهایی باید بر اساس معیارهای توافق‌شده، ریسک‌های باقی‌مانده و مسئولیت‌های تعریف‌شده در پروژه گرفته شود.

در نهایت، UAT Metrics باید به یک سؤال مهم پاسخ دهند:

آیا شواهد کافی برای تصمیم‌گیری درباره پذیرش محصول در اختیار داریم؟

اگر پاسخ این سؤال بر اساس داده‌ها، سناریوهای حیاتی، Acceptance Criteria و ریسک‌های باقی‌مانده قابل دفاع باشد، Metrics وظیفه خود را به‌درستی انجام داده‌اند.

UAT Report چیست و چگونه نوشته می‌شود؟

پس از پایان اجرای UAT، نتایج تست باید به‌صورت مشخص و قابل پیگیری مستند شوند.

UAT Report گزارشی است که وضعیت اجرای تست، نتایج، Defectها، ریسک‌های باقی‌مانده و در نهایت وضعیت پذیرش محصول را خلاصه می‌کند.

هدف گزارش UAT این نیست که تمام جزئیات Test Caseها را دوباره تکرار کند؛ بلکه باید به ذی‌نفعان کمک کند در مدت کوتاهی متوجه شوند:

UAT در چه وضعیتی قرار دارد و آیا محصول از دید کسب‌وکار آماده پذیرش است یا خیر؟

بخش‌های اصلی یک UAT Report

ساختار گزارش می‌تواند در سازمان‌های مختلف متفاوت باشد، اما یک گزارش مناسب معمولاً شامل بخش‌های زیر است.

1. اطلاعات کلی پروژه

در ابتدای گزارش بهتر است اطلاعات پایه مشخص شود:

• نام پروژه
• نام Release یا Version
• قابلیت یا Scope مورد بررسی
• محیط تست
• تاریخ شروع UAT
• تاریخ پایان UAT
• تهیه‌کننده گزارش

2. هدف UAT

در این بخش توضیح داده می‌شود که UAT با چه هدفی انجام شده است.

برای مثال:

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

این بخش باعث می‌شود خواننده بداند دقیقاً چه چیزی مورد ارزیابی قرار گرفته است.

3. Scope

در این قسمت مشخص می‌کنیم چه قابلیت‌هایی داخل محدوده UAT بوده‌اند.

In Scope:

• ثبت سفارش
• پرداخت آنلاین
• لغو سفارش
• مشاهده وضعیت سفارش

Out of Scope:

• Performance Testing
• Security Testing
• تست زیرساخت
• قابلیت‌هایی که در این Release ارائه نشده‌اند

مشخص کردن Out of Scope اهمیت زیادی دارد، زیرا مانع برداشت اشتباه از نتیجه UAT می‌شود.

4. خلاصه نتایج تست

یکی از مهم‌ترین قسمت‌های گزارش، خلاصه نتایج اجرای Test Caseها است.

وضعیت	تعداد
Total Test Cases	100
Passed	92
Failed	5
Blocked	3
Not Executed	0

از این اطلاعات می‌توان وضعیت کلی اجرای تست را مشاهده کرد؛ با این حال، برای تصمیم‌گیری درباره پذیرش محصول باید اهمیت سناریوها و وضعیت Defectها نیز بررسی شود.

5. UAT Metrics

در این قسمت می‌توان شاخص‌های مهم UAT را به‌صورت خلاصه گزارش کرد.

Metric	Result
Execution Progress	100%
Pass Rate	92%
Acceptance Criteria Coverage	100%
Critical Open Defects	0
High Open Defects	1
Retest Pass Rate	95%

این اطلاعات نباید صرفاً به‌صورت عددی ارائه شوند؛ بهتر است در کنار آنها توضیح کوتاهی درباره معنای نتایج و تأثیر آنها بر پذیرش محصول نیز وجود داشته باشد.

6. وضعیت Defectها

در این بخش وضعیت مشکلات شناسایی‌شده در UAT گزارش می‌شود.

Severity	Total	Open	Closed
Critical	2	0	2
High	5	1	4
Medium	10	2	8
Low	8	3	5

در این مثال، دو Defect با Severity برابر Critical شناسایی شده‌اند، اما هر دو قبل از پایان UAT رفع و Retest شده‌اند.

یک Defect با Severity برابر High همچنان باز است و باید در بخش Risk یا Known Issues نیز توضیح داده شود.

7. Acceptance Criteria Status

از آنجا که UAT ارتباط نزدیکی با Acceptance Criteria دارد، بهتر است وضعیت آنها نیز در گزارش مشخص شود.

Acceptance Criteria	Status
ثبت سفارش موفق	Pass
پرداخت آنلاین	Pass
نمایش شماره سفارش	Pass
لغو سفارش	Pass
بازگشت وجه	Pass
ارسال Notification	Fail

در این مثال، قابلیت Notification هنوز با مشکل مواجه است.

بنابراین صرفاً مشاهده Pass Rate کافی نیست و باید مشخص شود کدام معیار پذیرش Fail شده است و این Failure چه تأثیری بر کسب‌وکار دارد.

8. Critical Business Scenarios

یکی از بخش‌های مهم گزارش، وضعیت سناریوهای حیاتی کسب‌وکار است.

Business Scenario	Status
ثبت سفارش	Pass
پرداخت	Pass
لغو سفارش	Pass
بازگشت وجه	Pass
ارسال Notification	Fail

این جدول برای مدیران و ذی‌نفعان بسیار مفید است، زیرا به جای تمرکز صرف بر Test Caseهای فنی، وضعیت فرایندهای واقعی کسب‌وکار را نشان می‌دهد.

9. Known Issues و ریسک‌های باقی‌مانده

اگر در پایان UAT هنوز مشکلاتی وجود داشته باشند، باید آنها به‌صورت شفاف گزارش شوند.

قابلیت ارسال Notification در برخی شرایط با تأخیر انجام می‌شود. این مشکل در حال بررسی است و در شرایط فعلی تأثیری بر ثبت سفارش و پرداخت ندارد.

در صورت وجود چنین مشکلاتی بهتر است مشخص شود:

• Impact چیست؟
• Severity چیست؟
• آیا Workaround وجود دارد؟
• چه زمانی قرار است مشکل رفع شود؟
• چه کسی مسئول پیگیری آن است؟
• آیا ریسک توسط فرد یا گروه مسئول پذیرفته شده است؟

10. نتیجه نهایی UAT

در انتهای گزارش باید نتیجه کلی UAT مشخص باشد.

برای مثال:

• UAT Result: Accepted
• UAT Result: Accepted with Known Issues
• UAT Result: Not Accepted

با این حال، بهتر است فقط یک عبارت کوتاه نوشته نشود و دلیل نتیجه نیز توضیح داده شود.

نمونه کامل نتیجه UAT

فرض کنید نتایج نهایی به شکل زیر باشد:

• 100 Test Case اجرا شده است.
• 92 مورد Pass شده‌اند.
• 5 مورد Fail شده‌اند.
• 3 مورد Blocked بوده‌اند.
• هیچ Defect Critical بازی وجود ندارد.
• یک Defect High باز باقی مانده است.
• تمام Acceptance Criteriaهای حیاتی Pass شده‌اند.
• یک مشکل کم‌اهمیت در Notification وجود دارد.
• Business User ریسک مشکلات باقی‌مانده را بر اساس معیارهای توافق‌شده پذیرفته است.

در این شرایط ممکن است نتیجه به شکل زیر گزارش شود:

UAT Status: Accepted with Known Issues

تمام سناریوهای حیاتی کسب‌وکار با موفقیت اجرا شده‌اند و هیچ Defect با Severity Critical باز باقی نمانده است. یک Defect با Severity High و چند مشکل کم‌اهمیت همچنان وجود دارند، اما بر اساس ارزیابی کسب‌وکار، تأثیر آنها بر فرایندهای حیاتی قابل قبول است. موارد باقی‌مانده مستند شده‌اند و برای رفع آنها برنامه پیگیری تعیین شده است.

این نوع گزارش بسیار بهتر از نوشتن صرفاً «UAT Passed» است، زیرا وضعیت واقعی محصول، محدودیت‌ها و ریسک‌های آن را نیز نشان می‌دهد.

نمونه قالب UAT Report

در یک پروژه واقعی می‌توان گزارش را به شکل زیر ساختاربندی کرد:

UAT Summary

مورد	مقدار
Project	E-Commerce Platform
Release	v2.5
UAT Environment	UAT
Start Date	2026/08/01
End Date	2026/08/05
Total Test Cases	100
Passed	92
Failed	5
Blocked	3
Critical Open Defects	0
High Open Defects	1
Acceptance Criteria Coverage	100%
Final Result	Accepted with Known Issues

UAT Report برای چه کسانی تهیه می‌شود؟

گزارش UAT می‌تواند برای افراد مختلفی مفید باشد، از جمله:

• Test Manager
• QA Manager
• Product Owner
• Project Manager
• Business Owner
• Business User
• Customer
• سایر ذی‌نفعان پروژه

اما سطح جزئیات گزارش برای همه افراد یکسان نیست.

برای مثال، Test Manager ممکن است به جزئیات Defectها و Test Caseها نیاز داشته باشد، در حالی که مدیر کسب‌وکار بیشتر به این موارد توجه می‌کند:

• آیا قابلیت‌های مهم کار می‌کنند؟
• چه ریسک‌هایی باقی مانده‌اند؟
• آیا محصول قابل پذیرش است؟
• آیا شرایط لازم برای Release فراهم است؟

تفاوت UAT Report با Test Summary Report

این دو گزارش می‌توانند شبیه به هم باشند، اما تمرکز آنها الزاماً یکسان نیست.

Test Summary Report معمولاً وضعیت کلی فعالیت‌های تست و کیفیت محصول را از دید فرایند تست گزارش می‌کند.

در مقابل، UAT Report بیشتر روی نتایج Acceptance Testing و وضعیت پذیرش محصول از دید کاربر و کسب‌وکار تمرکز دارد.

به همین دلیل UAT Report باید ارتباط مشخصی با این زنجیره داشته باشد:

Acceptance Criteria → Business Scenarios → Acceptance Result

نکته مهم در تهیه UAT Report

گزارش UAT نباید فقط مجموعه‌ای از اعداد باشد.

برای مثال:

Pass Rate = 92%

به‌تنهایی اطلاعات کافی نمی‌دهد.

گزارش باید به این سؤال پاسخ دهد:

این 92 درصد چه معنایی برای کسب‌وکار دارد؟

اگر تمام سناریوهای حیاتی Pass شده‌اند و Failها مربوط به قابلیت‌های کم‌اهمیت هستند، نتیجه می‌تواند قابل قبول باشد.

اما اگر فقط یک Test Case Fail شده و همان Test Case مربوط به پرداخت اصلی سیستم باشد، وضعیت کاملاً متفاوت است.

بنابراین یک گزارش UAT خوب باید اعداد را در کنار Business Impact و Risk تفسیر کند.

جمع‌بندی

UAT Report در واقع خلاصه‌ای از شواهد و نتایج UAT است که به ذی‌نفعان کمک می‌کند درباره پذیرش محصول تصمیم بگیرند.

یک گزارش مناسب باید حداقل مشخص کند:

• چه چیزی تست شد؟
• چه تعداد تست اجرا شد؟
• نتایج چه بودند؟
• چه Defectهایی باقی مانده‌اند؟
• Acceptance Criteria چه وضعیتی دارند؟
• چه ریسک‌هایی وجود دارد؟
• و در نهایت، وضعیت پذیرش محصول چیست؟

به همین دلیل، UAT Report را می‌توان یکی از مهم‌ترین خروجی‌های فرایند UAT دانست؛ زیرا نتیجه تست را از مجموعه‌ای از اعداد و Defectها به شواهد قابل استفاده برای تصمیم‌گیری درباره پذیرش محصول تبدیل می‌کند.

Traceability در UAT چیست و چرا اهمیت دارد؟

در پروژه‌های نرم‌افزاری، فقط اجرای Test Case کافی نیست. باید بتوانیم مشخص کنیم هر تست دقیقاً برای بررسی کدام نیازمندی طراحی شده، چه نتیجه‌ای داشته و در صورت وجود مشکل، آن مشکل به کدام بخش از نیازمندی یا معیار پذیرش مربوط است.

این مفهوم با عنوان Traceability یا قابلیت ردیابی شناخته می‌شود.

در UAT، Traceability کمک می‌کند ارتباط بین نیاز کسب‌وکار، معیار پذیرش، سناریوی تست و نتیجه نهایی حفظ شود.

به‌صورت ساده می‌توان این ارتباط را چنین نمایش داد:

Business Requirement
↓
Acceptance Criteria
↓
UAT Scenario
↓
Test Case
↓
Defect
↓
Retest
↓
Final Result

چرا Traceability در UAT مهم است؟

فرض کنید یک سیستم فروشگاهی دارای 50 Requirement باشد.

اگر 100 Test Case داشته باشیم، اما ندانیم هر Test Case مربوط به کدام Requirement است، نمی‌توانیم به‌راحتی پاسخ دهیم:

آیا همه نیازهای مهم کسب‌وکار تست شده‌اند؟

ممکن است تعداد Test Caseها زیاد باشد، اما یک Requirement بسیار مهم اصلاً تست نشده باشد.

Traceability این مشکل را کاهش می‌دهد و کمک می‌کند ارتباط بین نیازمندی‌ها و شواهد تست قابل پیگیری باشد.

Traceability چه سؤالاتی را پاسخ می‌دهد؟

با داشتن Traceability می‌توان به سؤالاتی مانند این پاسخ داد:

• این Test Case برای کدام Requirement است؟
• این Acceptance Criteria چگونه تست شده است؟
• کدام سناریو یک نیازمندی خاص را پوشش می‌دهد؟
• کدام Defect مربوط به کدام Requirement است؟
• آیا Defect مربوط به یک Acceptance Criteria خاص رفع شده است؟
• آیا بعد از Fix، تست مربوطه Retest شده است؟
• وضعیت نهایی هر Requirement چیست؟

این اطلاعات برای Tester، QA Manager، Product Owner و سایر ذی‌نفعان پروژه می‌تواند ارزشمند باشد.

یک مثال واقعی از Traceability

فرض کنید در یک فروشگاه اینترنتی Requirement زیر وجود دارد:

Business Requirement

مشتری باید بتواند پس از انتخاب محصولات، سفارش خود را به‌صورت آنلاین پرداخت کند.

برای این Requirement، Acceptance Criteria تعریف می‌کنیم.

Acceptance Criteria

• AC-01: مشتری بتواند روش پرداخت آنلاین را انتخاب کند.
• AC-02: مبلغ پرداختی با مبلغ سفارش مطابقت داشته باشد.
• AC-03: پس از پرداخت موفق، سفارش ایجاد شود.
• AC-04: شماره سفارش به مشتری نمایش داده شود.

حالا برای این Acceptance Criteriaها سناریو طراحی می‌کنیم.

UAT Scenarios

• UAT-S01: پرداخت موفق یک سفارش
• UAT-S02: پرداخت ناموفق یک سفارش
• UAT-S03: بررسی ایجاد سفارش پس از پرداخت
• UAT-S04: بررسی نمایش شماره سفارش

سپس Test Caseها را تعریف می‌کنیم.

UAT Test Cases

Test Case	Acceptance Criteria	Scenario	Result
UAT-TC-01	AC-01	UAT-S01	Pass
UAT-TC-02	AC-02	UAT-S01	Pass
UAT-TC-03	AC-03	UAT-S01	Fail
UAT-TC-04	AC-04	UAT-S04	Pass

در اینجا مشخص است که:

AC-03 → UAT-TC-03 → Fail

بنابراین می‌توانیم دقیقاً متوجه شویم کدام Acceptance Criteria با مشکل مواجه شده است.

ارتباط Defect با Traceability

فرض کنیم Test Case مربوط به AC-03 Fail شده است.

تستر یک Defect با شناسه BUG-245 ثبت می‌کند:

پس از پرداخت موفق، سفارش ایجاد نمی‌شود.

حالا Traceability کامل‌تر می‌شود:

BR-01
↓
AC-03
↓
UAT-S01
↓
UAT-TC-03
↓
BUG-245
↓
Fix
↓
Retest
↓
Pass

این ارتباط بسیار ارزشمند است، زیرا از Requirement اولیه تا نتیجه نهایی قابل پیگیری است.

Traceability Matrix چیست؟

برای مدیریت این ارتباط می‌توان از Traceability Matrix یا ماتریس ردیابی استفاده کرد.

یک نمونه ساده:

Requirement	Acceptance Criteria	UAT Scenario	Test Case	Defect	Final Result
BR-01	AC-01	UAT-S01	TC-01	–	Pass
BR-01	AC-02	UAT-S01	TC-02	–	Pass
BR-01	AC-03	UAT-S01	TC-03	BUG-245	Pass (After Retest)
BR-01	AC-04	UAT-S04	TC-04	–	Pass

در ردیف مربوط به AC-03، Test Case ابتدا Fail شده، Defect ثبت شده، مشکل رفع شده و سپس بعد از Retest به Pass رسیده است.

Traceability در چه مراحلی ایجاد می‌شود؟

Traceability فقط در پایان UAT ساخته نمی‌شود. بهتر است این ارتباط از مراحل ابتدایی پروژه ایجاد و در طول چرخه توسعه و تست به‌روزرسانی شود.

مرحله Requirement

Requirement دارای شناسه مشخص می‌شود.

BR-001

مرحله Acceptance Criteria

برای آن Requirement معیارهای پذیرش تعریف می‌شوند:

AC-001

مرحله Test Design

Test Scenario و Test Case طراحی می‌شوند:

UAT-S001
UAT-TC-001

مرحله Execution

نتیجه اجرای Test Case ثبت می‌شود:

Pass / Fail / Blocked

مرحله Defect

در صورت Fail شدن تست، Defect مربوطه ثبت می‌شود.

BUG-001

مرحله Retest

پس از Fix، Test Case دوباره اجرا می‌شود تا مشخص شود مشکل برطرف شده است.

مرحله نهایی

در نهایت وضعیت Requirement و Acceptance Criteria بر اساس نتایج تست و Defectهای مرتبط مشخص می‌شود.

Traceability چه کمکی به Test Coverage می‌کند؟

یکی از مهم‌ترین کاربردهای Traceability، بررسی Coverage است.

فرض کنید پروژه دارای:

20 Acceptance Criteria

باشد.

با استفاده از Traceability Matrix مشخص می‌شود:

• 18 مورد Test Case مرتبط دارند.
• 2 مورد هیچ Test Case مرتبطی ندارند.

در نتیجه می‌توان متوجه شد:

Acceptance Criteria Coverage = 18 ÷ 20 × 100 = 90%

این موضوع قبل از پایان UAT باید بررسی شود تا Acceptance Criteriaهای بدون پوشش تعیین تکلیف شوند.

Traceability و Impact Analysis

Traceability فقط برای تست کردن نیست.

وقتی یک Requirement تغییر می‌کند، می‌توان از Traceability برای Impact Analysis استفاده کرد.

فرض کنید:

BR-005

تغییر کرده است.

با Traceability می‌توان بررسی کرد:

• کدام Acceptance Criteria تحت تأثیر قرار می‌گیرند؟
• کدام UAT Scenarioها باید تغییر کنند؟
• کدام Test Caseها باید دوباره بررسی یا اجرا شوند؟
• آیا Defectهای مرتبط تحت تأثیر قرار می‌گیرند؟

این موضوع در پروژه‌های بزرگ، به‌خصوص پروژه‌هایی که Requirementها مرتباً تغییر می‌کنند، اهمیت بیشتری پیدا می‌کند.

آیا همیشه به Traceability Matrix نیاز داریم؟

نه لزوماً.

در یک پروژه کوچک ممکن است ارتباط‌ها با یک Spreadsheet ساده مدیریت شوند.

در پروژه‌های بزرگ‌تر که:

• Requirementهای زیادی دارند،
• چند تیم درگیر هستند،
• تعداد Test Caseها زیاد است،
• Releaseهای متعددی وجود دارد،
• یا الزامات قانونی و قراردادی وجود دارد،

Traceability اهمیت بسیار بیشتری پیدا می‌کند.

Traceability در ابزارهای تست

ابزارهای مدیریت Requirement و Test Management می‌توانند امکان ایجاد ارتباط بین موارد مختلف را فراهم کنند.

برای مثال، در یک فرایند مدیریت تست می‌توان ارتباط‌هایی مانند زیر را ثبت کرد:

Requirement → Test Case → Test Execution → Defect

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

Traceability چه تفاوتی با Test Coverage دارد؟

این دو مفهوم با یکدیگر مرتبط هستند، اما یکسان نیستند.

Test Coverage بیشتر می‌پرسد:

چه مقدار از نیازمندی‌ها یا شرایط موردنظر تست شده‌اند؟

اما Traceability می‌پرسد:

ارتباط بین نیازمندی، تست، Defect و نتیجه دقیقاً چیست؟

برای مثال ممکن است بگوییم:

Acceptance Criteria Coverage = 100%

اما Traceability نشان دهد که هر معیار دقیقاً با کدام Test Case پوشش داده شده و نتیجه اجرای آن چه بوده است.

بنابراین Traceability می‌تواند شواهد و جزئیات بیشتری برای بررسی Coverage فراهم کند.

یک نکته مهم برای تسترها

Traceability نباید تبدیل به یک فعالیت صرفاً مستندسازی و زمان‌بر شود.

هدف آن این نیست که برای هر فعالیت کوچک چندین جدول ایجاد کنیم.

هدف اصلی این است که بتوانیم در هر لحظه پاسخ دهیم:

این نیازمندی چگونه تست شده و نتیجه آن چیست؟

اگر بتوانیم این سؤال را به‌سرعت پاسخ دهیم، Traceability به هدف اصلی خود رسیده است.

خلاصه Traceability در UAT

می‌توان کل مفهوم را به شکل زیر خلاصه کرد:

Business Requirement
⬇
Acceptance Criteria
⬇
UAT Scenario
⬇
Test Case
⬇
Test Execution
⬇
Defect، در صورت وجود
⬇
Retest
⬇
Final Result

این زنجیره باعث می‌شود تصمیم‌گیری درباره پذیرش محصول بر اساس شواهد قابل ردیابی انجام شود، نه صرفاً بر اساس یک اعلام شفاهی مانند «به نظر می‌رسد سیستم درست کار می‌کند».

تفاوت UAT با سایر انواع تست نرم‌افزار

UAT یکی از بخش‌های مهم فرایند اعتبارسنجی و پذیرش نرم‌افزار است، اما با تست‌هایی مانند Unit Testing، Integration Testing، System Testing، Functional Testing و Regression Testing یکسان نیست.

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

در تست‌های معمول QA، تمرکز بیشتر روی بررسی رفتار و کیفیت سیستم بر اساس نیازمندی‌ها و معیارهای تعریف‌شده است؛ در حالی که در UAT تمرکز اصلی روی این است که آیا محصول از دید کاربر و کسب‌وکار برای استفاده واقعی و پذیرش مناسب است یا خیر.

UAT در مقایسه با Unit Testing

Unit Testing معمولاً روی کوچک‌ترین واحدهای قابل تست نرم‌افزار، مانند یک Function یا Method، تمرکز دارد.

هدف این است که مشخص شود هر واحد نرم‌افزار به‌صورت مستقل رفتار مورد انتظار را دارد یا خیر.

در مقابل، UAT معمولاً با سناریوهای واقعی کسب‌وکار و جریان‌های کاری کاربر سروکار دارد.

مثال

در یک سیستم فروش:

Unit Test:

آیا Function مربوط به محاسبه تخفیف، مبلغ صحیح را برمی‌گرداند؟

UAT:

آیا کاربر می‌تواند یک سفارش را با کد تخفیف ثبت کند و فرایند خرید مطابق انتظار کسب‌وکار انجام شود؟

بنابراین سطح و هدف این دو تست کاملاً متفاوت است.

UAT در مقایسه با Integration Testing

Integration Testing بررسی می‌کند که اجزای مختلف سیستم چگونه با یکدیگر تعامل می‌کنند و آیا تبادل اطلاعات بین آنها به‌درستی انجام می‌شود یا خیر.

برای مثال:

آیا سیستم فروشگاه می‌تواند پس از ثبت سفارش، اطلاعات لازم را به سرویس پرداخت ارسال کند و پاسخ مناسب دریافت کند؟

در UAT سؤال می‌تواند گسترده‌تر باشد:

آیا کل فرایند خرید، از انتخاب محصول تا پرداخت و ثبت نهایی سفارش، مطابق فرایند واقعی کسب‌وکار انجام می‌شود؟

بنابراین Integration Testing بیشتر روی تعامل بین اجزای سیستم تمرکز دارد، در حالی که UAT روی فرایند و نتیجه مورد انتظار کاربر و کسب‌وکار تمرکز می‌کند.

UAT در مقایسه با System Testing

در System Testing کل سیستم به‌صورت یکپارچه و در برابر نیازمندی‌ها و رفتارهای مورد انتظار بررسی می‌شود.

در UAT نیز ممکن است سناریوهای End-to-End اجرا شوند، اما زاویه نگاه متفاوت است. در UAT تمرکز بیشتری روی نیاز واقعی کاربر، فرایند کسب‌وکار و تصمیم پذیرش وجود دارد.

برای مثال:

System Testing:

آیا سیستم در شرایط مشخص، سفارش را به‌درستی ثبت و وضعیت آن را به‌روزرسانی می‌کند؟

UAT:

آیا فرایند ثبت سفارش برای کاربر و کسب‌وکار همان فرایندی است که انتظار می‌رود و قابلیت برای پذیرش مناسب است؟

مرز این دو در پروژه‌های مختلف ممکن است تا حدی همپوشانی داشته باشد؛ بنابراین تفاوت آنها را نباید صرفاً بر اساس نوع Test Case یا End-to-End بودن سناریو مشخص کرد. هدف و مسئولیت فرایند اهمیت بیشتری دارد.

UAT در مقایسه با Functional Testing

Functional Testing بررسی می‌کند که یک قابلیت مطابق رفتار مورد انتظار عمل می‌کند یا خیر.

مثلاً:

آیا با وارد کردن Username و Password صحیح، کاربر وارد سیستم می‌شود؟

در UAT ممکن است همین قابلیت در قالب یک سناریوی واقعی کسب‌وکار بررسی شود:

آیا کارمند می‌تواند با حساب سازمانی خود وارد سیستم شود و فرایند کاری موردنظرش را با موفقیت انجام دهد؟

نکته مهم این است که Functional Testing و UAT لزوماً کاملاً جدا از یکدیگر نیستند. یک سناریوی UAT می‌تواند شامل بررسی رفتارهای Functional باشد، اما هدف نهایی UAT ارزیابی قابلیت از منظر نیاز و پذیرش کاربر و کسب‌وکار است.

UAT در مقایسه با Regression Testing

هدف Regression Testing بررسی این است که تغییرات جدید باعث خراب شدن قابلیت‌هایی که قبلاً درست کار می‌کردند نشده باشند.

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

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

بنابراین:

Regression Testing می‌پرسد: آیا تغییرات جدید چیزی را که قبلاً درست کار می‌کرد خراب کرده‌اند؟

UAT می‌پرسد: آیا محصول یا قابلیت جدید برای نیاز واقعی کسب‌وکار قابل پذیرش است؟

UAT در مقایسه با Smoke Testing

Smoke Testing معمولاً یک بررسی اولیه و سریع است که مشخص می‌کند Build یا نسخه جدید برای ادامه تست آمادگی اولیه دارد یا خیر.

برای مثال:

• آیا برنامه اجرا می‌شود؟
• آیا Login کار می‌کند؟
• آیا صفحات اصلی باز می‌شوند؟
• آیا قابلیت‌های اصلی در دسترس هستند؟

Smoke Test معمولاً سطح محدودی دارد، در حالی که UAT یک فرایند هدفمند برای بررسی پذیرش محصول بر اساس سناریوها، Acceptance Criteria و نیازهای کسب‌وکار است.

به همین دلیل، در بسیاری از فرایندها بهتر است قبل از شروع UAT، Smoke Testing و سایر تست‌های ضروری انجام شده باشند تا UAT به محلی برای پیدا کردن مشکلات پایه‌ای Build تبدیل نشود.

جدول مقایسه UAT با انواع تست

نوع تست	تمرکز اصلی	سؤال کلیدی
Unit Testing	واحدهای کوچک کد	آیا این Unit درست کار می‌کند؟
Integration Testing	ارتباط اجزای سیستم	آیا اجزا درست با هم تعامل دارند؟
System Testing	کل سیستم	آیا سیستم مطابق نیازمندی‌ها کار می‌کند؟
Functional Testing	عملکرد قابلیت‌ها	آیا قابلیت رفتار مورد انتظار را دارد؟
Regression Testing	اثر تغییرات	آیا تغییرات جدید چیزی را خراب کرده‌اند؟
Smoke Testing	آمادگی اولیه Build	آیا Build برای ادامه تست مناسب است؟
UAT	پذیرش کاربر و کسب‌وکار	آیا محصول برای استفاده واقعی قابل پذیرش است؟

آیا UAT جایگزین سایر تست‌ها می‌شود؟

خیر. UAT قرار نیست جایگزین Unit، Integration، System، Functional یا Regression Testing شود.

بهتر است این تست‌ها را بخش‌هایی از یک فرایند بزرگ‌تر در نظر بگیریم که هرکدام سؤال متفاوتی را پاسخ می‌دهند.

برای مثال:

• Unit Testing: آیا اجزای کوچک درست کار می‌کنند؟
• Integration Testing: آیا اجزا درست با هم تعامل دارند؟
• System Testing: آیا سیستم یکپارچه درست کار می‌کند؟
• Regression Testing: آیا تغییرات جدید باعث ایجاد مشکل در قابلیت‌های قبلی نشده‌اند؟
• UAT: آیا محصول از دید کاربر و کسب‌وکار قابل پذیرش است؟

این ترتیب البته در همه پروژه‌ها دقیقاً یکسان نیست و بسته به روش توسعه، معماری سیستم و فرایند سازمان ممکن است تغییر کند.

یک مثال کامل از تفاوت تست‌ها

فرض کنید یک فروشگاه اینترنتی قابلیت پرداخت آنلاین را توسعه داده است.

Unit Testing

Developer بررسی می‌کند:

آیا محاسبه مبلغ پرداخت به‌درستی انجام می‌شود؟

Integration Testing

تیم تست بررسی می‌کند:

آیا سیستم فروشگاه به‌درستی با درگاه پرداخت ارتباط برقرار می‌کند؟

Functional Testing

تستر بررسی می‌کند:

آیا کاربر می‌تواند پرداخت را با اطلاعات معتبر با موفقیت انجام دهد؟

Regression Testing

تستر بررسی می‌کند:

آیا تغییرات سیستم پرداخت باعث خراب شدن قابلیت‌های قبلی مانند ثبت سفارش نشده‌اند؟

UAT

Business User بررسی می‌کند:

آیا کل فرایند خرید و پرداخت مطابق فرایند واقعی کسب‌وکار انجام می‌شود و محصول برای پذیرش مناسب است؟

در این مثال می‌بینیم که همه تست‌ها می‌توانند حول یک قابلیت واحد انجام شوند، اما سؤال، هدف و زاویه نگاه آنها متفاوت است.

یک نکته مهم برای تسترها

یکی از اشتباهات رایج این است که تصور کنیم:

«اگر تمام Test Caseهای QA Pass شده‌اند، پس UAT هم باید Pass شود.»

این نتیجه لزوماً درست نیست.

ممکن است تمام تست‌های فنی و Functional Pass شده باشند، اما در UAT مشخص شود که یک فرایند کسب‌وکار به شکل مورد انتظار پیاده‌سازی نشده است.

بنابراین UAT یک لایه متفاوت از ارزیابی محصول است.

به بیان ساده:

تست‌های QA بررسی می‌کنند که سیستم مطابق الزامات و معیارهای تعریف‌شده رفتار می‌کند.

UAT بررسی می‌کند که آیا محصول از دید کاربر و کسب‌وکار برای استفاده و پذیرش مناسب است یا خیر.

این تفکیک یک ساده‌سازی آموزشی است و در عمل، مرز مسئولیت QA و UAT می‌تواند بر اساس فرایند و ساختار هر سازمان متفاوت باشد.

جمع‌بندی تفاوت UAT و سایر تست‌ها

UAT را نباید صرفاً «یک تست دیگر در کنار بقیه تست‌ها» بدانیم که قرار است همان موارد را دوباره بررسی کند.

هدف اصلی UAT این است که محصول را از منظر کاربر، کسب‌وکار و سناریوهای واقعی استفاده ارزیابی کند و شواهد لازم برای تصمیم‌گیری درباره پذیرش محصول را فراهم کند.

به همین دلیل، حتی اگر یک محصول از نظر فنی و Functional Testing وضعیت خوبی داشته باشد، هنوز ممکن است برای پذیرش کسب‌وکار آماده نباشد.

تست‌های مختلف به ما کمک می‌کنند بفهمیم نرم‌افزار مطابق معیارهای تعریف‌شده درست کار می‌کند؛ UAT کمک می‌کند بفهمیم آیا نرم‌افزار برای استفاده و پذیرش واقعی کسب‌وکار مناسب است یا خیر.

سوالات متداول درباره UAT

UAT چیست؟

User Acceptance Testing (UAT) فرایندی است که در آن نرم‌افزار از دید کاربران و کسب‌وکار بررسی می‌شود تا مشخص شود آیا محصول نیازهای واقعی و معیارهای پذیرش تعریف‌شده را برآورده می‌کند یا خیر.

هدف UAT فقط پیدا کردن Bug نیست؛ بلکه بررسی این موضوع است که آیا محصول برای پذیرش و استفاده واقعی آماده است یا خیر.

UAT را چه کسی انجام می‌دهد؟

UAT معمولاً توسط کاربران کسب‌وکار، نمایندگان مشتری، Product Owner یا سایر ذی‌نفعان مرتبط با محصول انجام می‌شود.

تستر نیز می‌تواند در طراحی سناریوها، آماده‌سازی Test Caseها، اجرای تست، ثبت Defectها و گزارش نتایج نقش داشته باشد.

بنابراین کسی که تست را اجرا می‌کند الزاماً همان فردی نیست که تصمیم نهایی درباره پذیرش محصول را می‌گیرد.

آیا Tester مسئول انجام UAT است؟

لزوماً نه. تستر می‌تواند نقش مهمی در برنامه‌ریزی و اجرای UAT داشته باشد، اما مسئولیت پذیرش نهایی معمولاً به Business User، Product Owner، Customer یا فرد مسئول دیگری در سازمان واگذار می‌شود.

این موضوع به ساختار پروژه و فرایند سازمان بستگی دارد.

UAT در چه مرحله‌ای انجام می‌شود؟

UAT معمولاً زمانی انجام می‌شود که قابلیت‌های موردنظر توسعه یافته و تست‌های ضروری QA انجام شده باشند.

در بسیاری از پروژه‌ها UAT قبل از Release نهایی یا ورود قابلیت به Production انجام می‌شود. با این حال، زمان دقیق UAT به روش توسعه، نوع پروژه و فرایند سازمان بستگی دارد.

آیا UAT باید قبل از Production انجام شود؟

در بسیاری از پروژه‌ها بله. UAT یکی از فعالیت‌هایی است که می‌تواند قبل از تصمیم نهایی برای Release انجام شود.

هدف این است که قبل از استفاده گسترده کاربران، مشخص شود محصول از دید کسب‌وکار قابل پذیرش است.

تفاوت UAT و QA چیست؟

QA یک حوزه گسترده برای تضمین کیفیت محصول و فرایند توسعه است و فعالیت‌های تست مختلفی را شامل می‌شود.

UAT مشخصاً روی پذیرش محصول از دید کاربر و کسب‌وکار تمرکز دارد.

QA: آیا نرم‌افزار مطابق الزامات و معیارهای کیفیت مورد انتظار کار می‌کند؟

UAT: آیا نرم‌افزار برای نیاز واقعی کاربر و کسب‌وکار قابل پذیرش است؟

آیا UAT همان Functional Testing است؟

خیر.

Functional Testing بررسی می‌کند که قابلیت‌های سیستم مطابق رفتار مورد انتظار کار می‌کنند.

UAT بیشتر روی این تمرکز دارد که آیا محصول در قالب سناریوهای واقعی کسب‌وکار نیاز کاربر را برآورده می‌کند یا خیر.

آیا UAT همان Regression Testing است؟

خیر.

Regression Testing بررسی می‌کند که تغییرات جدید باعث خراب شدن قابلیت‌های قبلی نشده باشند.

UAT بررسی می‌کند که محصول یا قابلیت موردنظر برای کاربر و کسب‌وکار قابل پذیرش است یا خیر.

UAT Test Case چیست؟

UAT Test Case مجموعه‌ای از شرایط، داده‌ها، مراحل و نتایج مورد انتظار است که برای بررسی یک سناریوی پذیرش طراحی می‌شود.

مثال:

Test Case: ثبت موفق سفارش

Precondition: کاربر وارد حساب خود شده و محصول در سبد خرید دارد.

Test Steps:

1. ورود به صفحه Checkout
2. انتخاب روش پرداخت
3. پرداخت مبلغ سفارش
4. بررسی نتیجه

Expected Result: سفارش با موفقیت ثبت شود و شماره سفارش به کاربر نمایش داده شود.

Acceptance Criteria چه ارتباطی با UAT دارد؟

Acceptance Criteria مشخص می‌کند که یک قابلیت برای پذیرفته شدن چه شرایطی باید داشته باشد.

UAT از این معیارها برای طراحی سناریوها و ارزیابی نتیجه استفاده می‌کند.

Requirement → Acceptance Criteria → UAT Scenario → Test Case → Result

آیا همه Bugها باید قبل از پایان UAT رفع شوند؟

خیر.

هدف این نیست که در پایان UAT حتماً تعداد Bugها به صفر برسد.

ممکن است Defectهای کم‌اهمیت باقی بمانند، به شرطی که:

• تأثیر آنها مشخص باشد.
• ریسک آنها ارزیابی شده باشد.
• وضعیت آنها مشخص باشد.
• فرد یا گروه مسئول ریسک را بپذیرد.
• این مشکلات مانع پذیرش قابلیت‌های حیاتی نباشند.

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

Fail شدن UAT لزوماً به معنی شکست کامل پروژه نیست.

ابتدا باید علت Fail مشخص شود. ممکن است مشکل ناشی از Bug، برآورده نشدن Acceptance Criteria، پیاده‌سازی اشتباه فرایند کسب‌وکار، Test Data یا Environment باشد.

پس از تحلیل مشکل ممکن است فرایند زیر انجام شود:

Fix → Retest → Regression Testing در صورت نیاز → UAT مجدد

UAT Sign-off چیست؟

UAT Sign-off به تأیید رسمی نتیجه UAT توسط فرد یا گروه مسئول پذیرش گفته می‌شود.

Sign-off می‌تواند به شکل تأیید در ابزار مدیریت پروژه، ثبت در سیستم، ایمیل رسمی یا امضای سند انجام شود.

آیا UAT Pass به معنی بدون Bug بودن نرم‌افزار است؟

خیر.

UAT Pass به این معنی نیست که هیچ Defectی در محصول وجود ندارد؛ بلکه یعنی بر اساس Acceptance Criteria، Scope، Business Impact و ریسک‌های قابل قبول، شرایط لازم برای پذیرش فراهم شده است.

مهم‌ترین Metric در UAT چیست؟

یک Metric واحد که همیشه مهم‌ترین باشد وجود ندارد.

معمولاً باید مجموعه‌ای از شاخص‌ها مانند موارد زیر بررسی شوند:

• Pass Rate
• Test Execution Progress
• Acceptance Criteria Coverage
• تعداد Defectها
• Open Critical/High Defects
• وضعیت سناریوهای حیاتی کسب‌وکار

این اعداد باید در کنار Business Impact و Risk تفسیر شوند.

آیا UAT را می‌توان Automation کرد؟

بخشی از فعالیت‌های UAT را می‌توان Automation کرد، اما UAT به‌طور کامل قابل جایگزینی با Automation نیست.

برای مثال، برخی سناریوهای تکراری را می‌توان با Automated Test اجرا کرد؛ اما تصمیم درباره اینکه آیا محصول واقعاً نیاز کسب‌وکار را برآورده می‌کند، ممکن است به قضاوت انسانی نیاز داشته باشد.

آیا UAT در Agile و Scrum انجام می‌شود؟

بله.

UAT می‌تواند در محیط‌های Agile نیز انجام شود. در Agile ممکن است Acceptance Criteria از زمان تعریف User Story مشخص شوند و در پایان یک Sprint یا قبل از Release، قابلیت توسط Product Owner یا Business User بررسی شود.

تفاوت UAT و Beta Testing چیست؟

UAT و Beta Testing هر دو می‌توانند با کاربران مرتبط باشند، اما مفهوم یکسانی ندارند.

UAT روی پذیرش محصول بر اساس نیازها و معیارهای مشخص کسب‌وکار تمرکز دارد.

Beta Testing معمولاً شامل ارائه نسخه‌ای از محصول به گروهی از کاربران برای استفاده در شرایط واقعی‌تر و دریافت Feedback است.

UAT Entry Criteria چیست؟

Entry Criteria شرایطی هستند که باید قبل از شروع UAT برقرار باشند.

• Build آماده باشد.
• Environment آماده باشد.
• Test Data آماده باشد.
• Acceptance Criteria مشخص باشد.
• Test Caseها آماده باشند.
• تست‌های ضروری QA انجام شده باشند.
• کاربران UAT دسترسی لازم داشته باشند.

UAT Exit Criteria چیست؟

Exit Criteria شرایطی هستند که مشخص می‌کنند UAT چه زمانی می‌تواند پایان پیدا کند.

• سناریوهای حیاتی اجرا شده باشند.
• Acceptance Criteriaهای مهم بررسی شده باشند.
• Defectهای Critical تعیین تکلیف شده باشند.
• Retest انجام شده باشد.
• ریسک‌های باقی‌مانده مشخص شده باشند.
• نتیجه نهایی UAT مشخص شده باشد.

UAT Report چیست؟

UAT Report گزارشی از وضعیت و نتیجه اجرای UAT است.

این گزارش معمولاً شامل Scope، تعداد Test Caseها، Pass / Fail / Blocked، Acceptance Criteria Coverage، Defectها، ریسک‌های باقی‌مانده، وضعیت سناریوهای حیاتی و نتیجه نهایی UAT است.

Traceability در UAT چه کاربردی دارد؟

Traceability کمک می‌کند ارتباط بین Requirement، Acceptance Criteria، Test Scenario، Test Case، Defect و نتیجه نهایی قابل پیگیری باشد.

Requirement → Acceptance Criteria → Test Case → Defect → Retest → Result

با این ارتباط می‌توان بررسی کرد که آیا نیازمندی‌های مهم واقعاً تست شده‌اند یا خیر.

آیا UAT فقط برای نرم‌افزارهای بزرگ استفاده می‌شود؟

خیر.

UAT می‌تواند در پروژه‌های کوچک و بزرگ استفاده شود. میزان رسمی بودن فرایند UAT به عواملی مانند اندازه پروژه، تعداد کاربران، اهمیت سیستم، ریسک کسب‌وکار و الزامات قراردادی یا قانونی بستگی دارد.

مهم‌ترین نکته در UAT چیست؟

مهم‌ترین نکته این است که UAT را صرفاً به عنوان یک مرحله دیگر برای پیدا کردن Bug در نظر نگیریم.

هدف اصلی UAT پاسخ دادن به این سؤال است:

آیا محصول از دید کاربر و کسب‌وکار، نیازهای مورد انتظار را برآورده می‌کند و برای پذیرش مناسب است؟

به همین دلیل، موفقیت UAT فقط با تعداد Test Caseهای Pass شده مشخص نمی‌شود؛ بلکه باید Acceptance Criteria، سناریوهای حیاتی، Defectها، ریسک‌ها و Business Impact را در کنار یکدیگر بررسی کرد.

جمع‌بندی؛ UAT چه نقشی در کیفیت نرم‌افزار دارد؟

User Acceptance Testing یا UAT یکی از فعالیت‌های مهم در ارزیابی و پذیرش نرم‌افزار است که تمرکز آن بر نیازهای واقعی کاربران و کسب‌وکار قرار دارد.

در تست‌های مختلف نرم‌افزار، هر نوع تست سؤال متفاوتی را پاسخ می‌دهد؛ اما UAT در نهایت به یک سؤال کلیدی می‌رسد:

آیا این محصول برای استفاده واقعی و پذیرش کسب‌وکار مناسب است؟

برای پاسخ به این سؤال، تست پذیرش کاربر باید بر اساس معیارهای مشخص و سناریوهای واقعی کسب‌وکار انجام شود.

در یک فرایند مناسب UAT، ابتدا Entry Criteria مشخص می‌کند که آیا شرایط لازم برای شروع تست فراهم است یا خیر. سپس با استفاده از Acceptance Criteria، UAT Scenario و Test Case قابلیت‌های موردنظر ارزیابی می‌شوند.

در طول اجرای UAT نیز وضعیت تست‌ها، Defectها و ریسک‌ها باید به‌صورت مستند پیگیری شوند. استفاده از UAT Metrics کمک می‌کند وضعیت تست بر اساس داده و شواهد قابل اندازه‌گیری بررسی شود و UAT Report نیز نتیجه این فعالیت‌ها را در اختیار ذی‌نفعان قرار می‌دهد.

از طرف دیگر، Traceability باعث می‌شود ارتباط بین Requirement، Acceptance Criteria، Test Case، Defect و نتیجه نهایی قابل ردیابی باشد.

در پایان نیز Exit Criteria مشخص می‌کند که آیا شرایط لازم برای پایان UAT و تصمیم‌گیری درباره پذیرش محصول فراهم شده است یا خیر.

UAT موفق یعنی چه؟

UAT موفق الزاماً به معنی نرم‌افزاری بدون هیچ Bug نیست.

ممکن است در پایان UAT چند Defect کم‌اهمیت همچنان وجود داشته باشند، اما اگر شرایط زیر برقرار باشد، بر اساس معیارهای پروژه می‌توان درباره پذیرش محصول تصمیم‌گیری کرد:

• سناریوهای حیاتی کسب‌وکار با موفقیت اجرا شده باشند.
• Acceptance Criteriaهای مهم برآورده شده باشند.
• Defectهای مهم تعیین تکلیف شده باشند.
• ریسک‌های باقی‌مانده مشخص و مستند شده باشند.
• ذی‌نفع یا فرد مسئول پذیرش، نتیجه را تأیید کرده باشد.

بنابراین، بهتر است UAT را صرفاً یک مرحله برای پیدا کردن Bug ندانیم.

UAT در واقع پلی است بین تیم توسعه و تست و نیاز واقعی کسب‌وکار؛ جایی که مشخص می‌شود محصولی که از نظر فنی ساخته و تست شده، آیا در دنیای واقعی نیز همان ارزشی را که انتظار می‌رود ایجاد می‌کند یا خیر.

نقش تستر در UAT

برای یک تستر نرم‌افزار، شناخت UAT فقط به معنای یادگیری نحوه نوشتن چند Test Case نیست.

تستر می‌تواند در بخش‌های مختلف فرایند UAT نقش مهمی داشته باشد، از جمله:

• تحلیل Requirementها و درک نیازهای موردنظر.
• درک Acceptance Criteria و تبدیل آنها به سناریوهای قابل تست.
• شناسایی سناریوهای واقعی و حیاتی کسب‌وکار.
• طراحی Test Caseهای مناسب برای UAT.
• اجرای تست‌ها و مستندسازی نتایج.
• ثبت و پیگیری Defectها و بررسی Business Impact آنها.
• حفظ Traceability بین Requirement، Acceptance Criteria و Test Caseها.
• تهیه و تحلیل UAT Metrics.
• تهیه UAT Report و ارائه شواهد لازم برای تصمیم‌گیری.

البته این موضوع به این معنی نیست که تستر مسئول تصمیم نهایی درباره پذیرش محصول یا پذیرش ریسک‌های کسب‌وکار است. این مسئولیت معمولاً بر عهده Business User، Product Owner، Customer یا فرد دیگری است که در پروژه اختیار پذیرش را دارد.

نیازهای مورد انتظار را برآورده می‌کند و برای پذیرش مناسب است؟

در نتیجه، UAT را می‌توان یکی از نقاطی دانست که در آن مهارت‌های تست نرم‌افزار، تحلیل نیازمندی و درک کسب‌وکار به یکدیگر می‌رسند.

UAT در یک نگاه

اگر بخواهیم کل فرایند UAT را به‌صورت ساده خلاصه کنیم، می‌توان آن را چنین در نظر گرفت:

Requirement
↓
Acceptance Criteria
↓
UAT Scenario
↓
Test Case
↓
Test Execution
↓
Defect و Retest در صورت نیاز
↓
UAT Metrics و Report
↓
Exit Criteria
↓
Acceptance Decision

این زنجیره کمک می‌کند تصمیم‌گیری درباره پذیرش محصول بر اساس شواهد، معیارهای مشخص و ریسک‌های قابل ارزیابی انجام شود، نه صرفاً بر اساس یک اعلام شفاهی مانند «به نظر می‌رسد سیستم درست کار می‌کند».

سخن پایانی

در نهایت، هدف UAT این نیست که فقط ثابت کنیم نرم‌افزار کار می‌کند؛ بلکه باید مشخص کنیم آیا نرم‌افزار چیزی را که کاربر و کسب‌وکار واقعاً به آن نیاز دارند، به شکل قابل قبول ارائه می‌کند یا خیر.

به همین دلیل، یک UAT مناسب فقط به Pass و Fail کردن Test Caseها محدود نمی‌شود؛ بلکه باید Acceptance Criteria، سناریوهای حیاتی، Defectها، ریسک‌ها، Business Impact و شواهد قابل ردیابی را در کنار یکدیگر قرار دهد تا تصمیم نهایی درباره پذیرش محصول آگاهانه‌تر و قابل دفاع‌تر باشد.

منابع

برای مطالعه بیشتر درباره User Acceptance Testing، Acceptance Testing، مدیریت تست و مفاهیم مرتبط، منابع زیر پیشنهاد می‌شوند:

• 
  ISTQB – Acceptance Testing —
  
  منبع رسمی ISTQB درباره Acceptance Testing
  
  
• 
  ISTQB Glossary —
  
  واژه‌نامه ISTQB برای بررسی تعاریف اصطلاحات تست نرم‌افزار
  
  
• 
  ISTQB – Test Management —
  
  منبع رسمی درباره مدیریت فعالیت‌های تست، معیارها و گزارش‌دهی
  
  
• 
  ISTQB – Certified Tester Foundation Level —
  
  منبع رسمی برای مفاهیم پایه تست نرم‌افزار
  
  
• 
  Agile Manifesto —
  
  منبع اصلی برای اصول و ارزش‌های توسعه نرم‌افزار چابک
  
  
• 
  The Scrum Guide —
  
  منبع مرجع Scrum و مفاهیم مرتبط با Product Owner، Increment و توسعه چابک
  
  

منابع اصلی این مقاله

در میان منابع بالا، برای مطالب مطرح‌شده در این مقاله، ISTQB مهم‌ترین مرجع تخصصی محسوب می‌شود؛ به‌خصوص برای تعریف Acceptance Testing، User Acceptance Testing، Test Case، Traceability، Entry Criteria و Exit Criteria.

• 
  
  International Software Testing Qualifications Board (ISTQB)
  
  
• 
  
  ISTQB Glossary
  
  
• 
  
  ISTQB Acceptance Testing
  
  

نکته: نام‌گذاری و نحوه اجرای UAT ممکن است بین سازمان‌ها و پروژه‌های مختلف متفاوت باشد. بنابراین بهتر است تعاریف ارائه‌شده در این مقاله در کنار فرایند و استانداردهای مورد استفاده در هر سازمان تفسیر شوند.

سوالات متداول درباره UAT

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

User Acceptance Testing (UAT) فرایندی است که در آن نرم‌افزار از دید کاربران و کسب‌وکار بررسی می‌شود تا مشخص شود آیا محصول نیازهای واقعی و معیارهای پذیرش تعریف‌شده را برآورده می‌کند یا خیر.

هدف UAT فقط پیدا کردن Bug نیست؛ بلکه بررسی این موضوع است که آیا محصول برای پذیرش و استفاده واقعی آماده است یا خیر.

UAT را چه کسی انجام می‌دهد؟

UAT معمولاً توسط کاربران کسب‌وکار، نمایندگان مشتری، Product Owner یا سایر ذی‌نفعان مرتبط با محصول انجام می‌شود.

تستر نیز می‌تواند در طراحی سناریوها، آماده‌سازی Test Caseها، اجرای تست، ثبت Defectها و گزارش نتایج نقش داشته باشد.

بنابراین کسی که تست را اجرا می‌کند الزاماً همان فردی نیست که تصمیم نهایی درباره پذیرش محصول را می‌گیرد.

آیا Tester مسئول انجام UAT است؟

لزوماً نه.

تستر می‌تواند نقش مهمی در برنامه‌ریزی و اجرای UAT داشته باشد، اما مسئولیت پذیرش نهایی معمولاً به Business User، Product Owner، Customer یا فرد مسئول دیگری در سازمان واگذار می‌شود.

این موضوع به ساختار پروژه و فرایند سازمان بستگی دارد.

UAT در چه مرحله‌ای انجام می‌شود؟

UAT معمولاً زمانی انجام می‌شود که قابلیت‌های موردنظر توسعه یافته و تست‌های ضروری QA انجام شده باشند.

در بسیاری از پروژه‌ها UAT قبل از Release نهایی یا ورود قابلیت به Production انجام می‌شود.

با این حال، زمان دقیق UAT به روش توسعه، نوع پروژه و فرایند سازمان بستگی دارد.

آیا UAT باید قبل از Production انجام شود؟

در بسیاری از پروژه‌ها بله. UAT یکی از فعالیت‌هایی است که قبل از تصمیم نهایی برای Release انجام می‌شود.

هدف این است که قبل از استفاده گسترده کاربران، مشخص شود محصول از دید کسب‌وکار قابل پذیرش است.

اما اینکه UAT الزاماً باید در چه مرحله‌ای انجام شود، به فرایند Release سازمان بستگی دارد.

تفاوت UAT و QA چیست؟

QA یک حوزه گسترده برای تضمین کیفیت محصول و فرایند توسعه است و فعالیت‌های تست مختلفی را شامل می‌شود.

UAT مشخصاً روی پذیرش محصول از دید کاربر و کسب‌وکار تمرکز دارد.

QA: آیا نرم‌افزار مطابق الزامات و معیارهای کیفیت مورد انتظار کار می‌کند؟

UAT: آیا نرم‌افزار برای نیاز واقعی کاربر و کسب‌وکار قابل پذیرش است؟

آیا UAT همان Functional Testing است؟

خیر.

Functional Testing بررسی می‌کند که قابلیت‌های سیستم مطابق رفتار مورد انتظار کار می‌کنند.

UAT بیشتر روی این تمرکز دارد که آیا محصول در قالب سناریوهای واقعی کسب‌وکار نیاز کاربر را برآورده می‌کند یا خیر.

این دو می‌توانند همپوشانی داشته باشند، اما هدف و دیدگاه آنها یکسان نیست.

آیا UAT همان Regression Testing است؟

خیر.

Regression Testing بررسی می‌کند که تغییرات جدید باعث خراب شدن قابلیت‌های قبلی نشده باشند.

UAT بررسی می‌کند که محصول یا قابلیت موردنظر برای کاربر و کسب‌وکار قابل پذیرش است یا خیر.

UAT Test Case چیست؟

UAT Test Case مجموعه‌ای از شرایط، داده‌ها، مراحل و نتایج مورد انتظار است که برای بررسی یک سناریوی پذیرش طراحی می‌شود.

Test Case: ثبت موفق سفارش

Precondition: کاربر وارد حساب خود شده و محصول در سبد خرید دارد.

Test Steps:

1. ورود به صفحه Checkout
2. انتخاب روش پرداخت
3. پرداخت مبلغ سفارش
4. بررسی نتیجه

Expected Result: سفارش با موفقیت ثبت شود و شماره سفارش به کاربر نمایش داده شود.

Acceptance Criteria چه ارتباطی با UAT دارد؟

Acceptance Criteria مشخص می‌کند که یک قابلیت برای پذیرفته شدن چه شرایطی باید داشته باشد.

UAT از این معیارها برای طراحی سناریوها و ارزیابی نتیجه استفاده می‌کند.

Requirement → Acceptance Criteria → UAT Scenario → Test Case → Result

به همین دلیل، Acceptance Criteria یکی از مهم‌ترین ورودی‌های UAT محسوب می‌شود.

آیا همه Bugها باید قبل از پایان UAT رفع شوند؟

خیر.

هدف این نیست که در پایان UAT حتماً تعداد Bugها به صفر برسد.

ممکن است Defectهای کم‌اهمیت باقی بمانند، به شرطی که:

• تأثیر آنها مشخص باشد.
• ریسک آنها ارزیابی شده باشد.
• وضعیت آنها مشخص باشد.
• فرد یا گروه مسئول ریسک را بپذیرد.
• این مشکلات مانع پذیرش قابلیت‌های حیاتی نباشند.

Defectهای Critical و مشکلات مؤثر بر فرایندهای حیاتی معمولاً اهمیت بسیار بیشتری دارند.

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

Fail شدن UAT لزوماً به معنی شکست کامل پروژه نیست.

ابتدا باید مشخص شود علت Fail چیست. ممکن است مشکل مربوط به Bug، Acceptance Criteria، فرایند کسب‌وکار، Test Data یا Environment باشد.

پس از تحلیل مشکل، ممکن است نیاز باشد:

Fix → Retest → Regression Testing در صورت نیاز → UAT مجدد

UAT Sign-off چیست؟

UAT Sign-off به تأیید رسمی نتیجه UAT توسط فرد یا گروه مسئول پذیرش گفته می‌شود.

Sign-off می‌تواند نشان دهد که بر اساس معیارهای توافق‌شده، محصول از دید کسب‌وکار قابل پذیرش است.

Sign-off ممکن است به شکل تأیید در ابزار مدیریت پروژه، ثبت در سیستم، ایمیل رسمی یا امضای سند انجام شود.

آیا UAT Pass به معنی بدون Bug بودن نرم‌افزار است؟

خیر.

UAT Pass به این معنی نیست که هیچ Defectی در محصول وجود ندارد.

بلکه یعنی بر اساس Acceptance Criteria، Scope، Business Impact و ریسک‌های قابل قبول، شرایط لازم برای پذیرش فراهم شده است.

مهم‌ترین Metric در UAT چیست؟

یک Metric واحد که همیشه مهم‌ترین باشد وجود ندارد.

معمولاً باید مجموعه‌ای از شاخص‌ها را بررسی کرد، از جمله:

• Pass Rate
• Test Execution Progress
• Acceptance Criteria Coverage
• تعداد Defectها
• Open Critical/High Defects
• وضعیت سناریوهای حیاتی کسب‌وکار

این اعداد باید در کنار Business Impact و Risk تفسیر شوند.

آیا UAT را می‌توان Automation کرد؟

بخشی از فعالیت‌های UAT را می‌توان Automation کرد، اما UAT به‌طور کامل قابل جایگزینی با Automation نیست.

برای مثال، می‌توان برخی سناریوهای تکراری را با Automated Test اجرا کرد.

اما تصمیم درباره اینکه «آیا این محصول واقعاً نیاز کسب‌وکار را برآورده می‌کند؟» ممکن است به قضاوت و ارزیابی انسان نیاز داشته باشد.

بنابراین Automation می‌تواند به UAT کمک کند، اما لزوماً جایگزین کامل Business Acceptance نیست.

آیا UAT در Agile و Scrum انجام می‌شود؟

بله.

UAT می‌تواند در محیط‌های Agile نیز انجام شود.

در Agile ممکن است Acceptance Criteria از همان زمان تعریف User Story مشخص شوند و در پایان یک Sprint یا قبل از Release، قابلیت توسط Product Owner یا Business User بررسی شود.

بنابراین Agile بودن پروژه به معنی حذف UAT نیست؛ بلکه نحوه و زمان اجرای آن ممکن است متفاوت باشد.

تفاوت UAT و Beta Testing چیست؟

UAT و Beta Testing هر دو می‌توانند با کاربران مرتبط باشند، اما مفهوم یکسانی ندارند.

UAT روی پذیرش محصول بر اساس نیازها و معیارهای مشخص کسب‌وکار تمرکز دارد.

Beta Testing معمولاً شامل ارائه نسخه‌ای از محصول به گروهی از کاربران برای استفاده در شرایط واقعی‌تر و دریافت Feedback است.

بنابراین یک محصول می‌تواند Beta Testing داشته باشد بدون اینکه الزاماً یک فرایند رسمی UAT را پشت سر گذاشته باشد.

UAT Entry Criteria چیست؟

Entry Criteria شرایطی هستند که باید قبل از شروع UAT برقرار باشند.

• Build آماده باشد.
• Environment آماده باشد.
• Test Data آماده باشد.
• Acceptance Criteria مشخص باشد.
• Test Caseها آماده باشند.
• تست‌های ضروری QA انجام شده باشند.
• کاربران UAT دسترسی لازم داشته باشند.

UAT Exit Criteria چیست؟

Exit Criteria شرایطی هستند که مشخص می‌کنند UAT چه زمانی می‌تواند پایان پیدا کند.

• سناریوهای حیاتی اجرا شده باشند.
• Acceptance Criteriaهای مهم بررسی شده باشند.
• Defectهای Critical تعیین تکلیف شده باشند.
• Retest انجام شده باشد.
• ریسک‌های باقی‌مانده مشخص شده باشند.
• نتیجه نهایی UAT مشخص شده باشد.

UAT Report چیست؟

UAT Report گزارشی از وضعیت و نتیجه اجرای UAT است.

این گزارش معمولاً شامل Scope، تعداد Test Caseها، Pass / Fail / Blocked، Acceptance Criteria Coverage، Defectها، ریسک‌های باقی‌مانده، وضعیت سناریوهای حیاتی و نتیجه نهایی UAT است.

هدف آن کمک به ذی‌نفعان برای تصمیم‌گیری درباره پذیرش محصول است.

Traceability در UAT چه کاربردی دارد؟

Traceability کمک می‌کند ارتباط بین Requirement، Acceptance Criteria، Test Scenario، Test Case، Defect و نتیجه نهایی قابل پیگیری باشد.

Requirement → Acceptance Criteria → Test Case → Defect → Retest → Result

با این ارتباط می‌توان بررسی کرد که آیا نیازمندی‌های مهم واقعاً تست شده‌اند یا خیر.

آیا UAT فقط برای نرم‌افزارهای بزرگ استفاده می‌شود؟

خیر.

UAT می‌تواند در پروژه‌های کوچک و بزرگ استفاده شود.

البته میزان رسمی بودن فرایند UAT به عواملی مانند اندازه پروژه، تعداد کاربران، اهمیت سیستم، ریسک کسب‌وکار و الزامات قراردادی و قانونی بستگی دارد.

در یک پروژه کوچک ممکن است UAT با چند سناریوی ساده انجام شود، در حالی که در یک سیستم بانکی یا سازمانی ممکن است فرایند UAT کاملاً رسمی و مستند باشد.

مهم‌ترین نکته در UAT چیست؟

مهم‌ترین نکته این است که UAT را صرفاً به عنوان یک مرحله دیگر برای پیدا کردن Bug در نظر نگیریم.

هدف اصلی UAT پاسخ دادن به این سؤال است:

آیا محصول از دید کاربر و کسب‌وکار، نیازهای مورد انتظار را برآورده می‌کند و برای پذیرش مناسب است؟

به همین دلیل، موفقیت UAT فقط با تعداد Test Caseهای Pass شده مشخص نمی‌شود؛ بلکه باید Acceptance Criteria، سناریوهای حیاتی، Defectها، ریسک‌ها و Business Impact را در کنار یکدیگر بررسی کرد.