پاسخ کوتاه
UAT یا User Acceptance Testing، تست پذیرش کاربر است: نماینده کاربران کسبوکار نسخه مشخصی از نرمافزار را با داده و سناریوی نزدیک به واقعیت آزمایش میکند تا تطابق آن با نیاز و معیار پذیرش تأیید شود. UAT جای تست فنی تیم توسعه را نمیگیرد و باید با نتیجه، شواهد و موارد باز ثبت شود.
معیار پذیرش دقیقاً چه چیزی را مشخص میکند؟
معیار پذیرش مرز قابل مشاهده یک قابلیت است. بهجای توصیف روش برنامهنویسی، میگوید چه کسی، تحت چه شرایطی، چه کاری انجام میدهد و چه نتیجهای باید ببیند. برای نمونه، «کارشناس مالی پس از تأیید مدیر بتواند فایل خروجی تراکنشهای همان شعبه را دریافت کند» از «ساخت گزارش مالی» بسیار قابل آزمونتر است.
Definition of Done معمولاً استاندارد داخلی تیم برای کاملشدن کار است؛ مانند بازبینی کد، عبور تستها و انتشار در محیط آزمایش. معیار پذیرش درباره رفتار همان قابلیت از دید کسبوکار است. هر دو لازماند و جای یکدیگر را نمیگیرند.
گزارش سریع باشد
- معیار پذیرش قابل آزمون
- گزارش ماهانه با حداکثر ۵۰ هزار رکورد در شرایط توافقشده حداکثر طی ۱۰ ثانیه نمایش داده شود
- شاهد پذیرش
- زمان ثبتشده در اجرای سناریوی مشخص
سطح دسترسی رعایت شود
- معیار پذیرش قابل آزمون
- کاربر شعبه فقط پروندههای شعبه خود را ببیند و درخواست شعبه دیگر پاسخ مجاز نگیرد
- شاهد پذیرش
- آزمون با دو حساب و ثبت نتیجه
پیامک ارسال شود
- معیار پذیرش قابل آزمون
- پس از تغییر وضعیت به «تأییدشده»، پیامک حداکثر در بازه توافقشده ارسال و شناسه آن ثبت شود
- شاهد پذیرش
- لاگ ارسال و مشاهده پیام آزمایشی
UAT را چه کسی و در چه محیطی انجام میدهد؟
نمایندهای از کاربران واقعی باید مالک اجرای UAT باشد؛ کسی که استثناها و قواعد روزمره فرایند را میشناسد. مدیر پروژه میتواند نتیجه را جمعبندی کند، اما اگر فقط تیم توسعه نرمافزار را آزمایش کند، ریسک نادیدهماندن تفاوت میان طراحی و کار واقعی بالا میرود.
محیط UAT باید تا حد ممکن به نسخه نهایی نزدیک باشد، اما نباید با اطلاعات حساس واقعی و بدون کنترل کار کند. نقشها، تنظیمات، سرویسهای آزمایشی و مجموعه داده باید از قبل آماده و نسخه نرمافزار ثابت شود تا نتیجه هر اجرا قابل بازتولید باشد.
- مسئول کسبوکار برای تأیید نهایی هر جریان
- کاربران منتخب برای اجرای سناریوهای عادی و استثناها
- نماینده تیم فنی برای آمادهسازی محیط و ثبت شواهد
- نسخه ثابت، داده آزمایشی کنترلشده و حسابهای نقشمحور
- زمان شروع، پایان و قاعده تصمیم درباره ایرادهای باز
قالب ساده برای نوشتن سناریوی پذیرش
برای هر جریان مهم حداقل یک مسیر موفق، یک خطای متداول، کنترل سطح دسترسی و یک حالت مرزی بنویسید. قالب «با فرض اینکه / وقتی / آنگاه» باعث میشود پیششرط، اقدام و نتیجه از هم جدا باشند.
با فرض اینکه
- پرسش
- وضعیت اولیه چیست؟
- نمونه
- درخواست ثبت شده و کاربر نقش مدیر واحد دارد
وقتی
- پرسش
- کاربر چه اقدامی میکند؟
- نمونه
- درخواست را تأیید و توضیح را ثبت میکند
آنگاه
- پرسش
- چه نتیجهای قابل مشاهده است؟
- نمونه
- وضعیت تغییر میکند، زمان و نام تأییدکننده ثبت و اعلان ارسال میشود
شاهد
- پرسش
- قبولی چگونه اثبات میشود؟
- نمونه
- تصویر نتیجه، شناسه درخواست و رکورد تاریخچه
تفاوت باگ، درخواست تغییر و مورد خارج از محدوده
اگر رفتار نرمافزار با معیار پذیرش یا نیاز مصوب تفاوت دارد، معمولاً باگ است. اگر معیار رعایت شده اما کارفرما رفتار دیگری میخواهد، درخواست تغییر است. نیاز جدیدی که در محدوده نسخه فعلی تعریف نشده نیز باید برآورد، اولویت و زمانبندی جدا داشته باشد.
ثبت این تفکیک به معنی نادیدهگرفتن بازخورد کاربر نیست؛ کمک میکند ایراد واقعی سریع اصلاح شود و تغییر محصول نیز بدون پنهانشدن در فهرست خطاها تصمیمگیری شود.
باگ
- نشانه
- نتیجه با معیار مصوب تطابق ندارد
- اقدام مناسب
- تعیین شدت، اصلاح و آزمون مجدد
درخواست تغییر
- نشانه
- معیار فعلی پاس میشود اما رفتار دیگری مطلوب است
- اقدام مناسب
- تحلیل اثر، برآورد و تأیید تغییر
خارج از محدوده
- نشانه
- قابلیت یا نقش در نسخه جاری تعریف نشده است
- اقدام مناسب
- قرارگرفتن در نقشه راه یا قرارداد تکمیلی
ابهام
- نشانه
- مستندات درباره نتیجه مورد انتظار سکوت یا تناقض دارند
- اقدام مناسب
- تصمیم مشترک و اصلاح معیار برای ادامه
شدت ایراد و قاعده امضای تحویل را از قبل تعیین کنید
پذیرش نباید به صفرشدن هر ایراد ظاهری وابسته باشد. بهتر است شدتها با اثر کسبوکاری تعریف شوند: مسدودکننده برای توقف جریان اصلی یا خطر داده، بالا برای اختلال مهم بدون راه جایگزین مناسب، متوسط برای اختلال محدود و پایین برای مسئله ظاهری یا کماثر.
در صورتجلسه، نسخه آزمایششده، سناریوهای پاسشده، موارد باز، مسئول و موعد هر مورد و تصمیم نهایی ثبت شود. پذیرش مشروط نیز باید دقیقاً بگوید چه چیزی مانده و آیا مانع راهاندازی است یا خیر.
- شماره نسخه و تاریخ استقرار محیط UAT
- فهرست سناریوها و نتیجه پاس، رد یا اجرانشده
- شناسه و شدت ایرادهای باز همراه با مسئول و موعد
- محدودیتها و مواردی که به مرحله بعد منتقل میشوند
- نام و نقش تأییدکنندگان کسبوکار و فنی
نکته: برای پروژههای حساس یا قراردادهای رسمی، متن پذیرش و آثار حقوقی صورتجلسه را با مشاور حقوقی متناسب با قرارداد خود بررسی کنید.
پرسشهای متداول
UAT چیست و چه کسی آن را اجرا میکند؟
UAT تست پذیرش کاربر است. نماینده کاربران یا مالک فرایند کسبوکار سناریوهای واقعی را اجرا میکند و تیم فنی محیط، داده و شواهد لازم را فراهم میکند.
آیا UAT همان تست نرمافزار توسط برنامهنویس است؟
خیر. تستهای فنی کیفیت پیادهسازی را بررسی میکنند؛ UAT تطابق محصول با سناریو و نیاز واقعی کسبوکار را با مشارکت نماینده کاربران میسنجد.
معیار پذیرش را چه زمانی باید نوشت؟
پیش از شروع توسعه همان قابلیت. نوشتن آن در زمان تحلیل یا برنامهریزی، ابهام را پیش از هزینهشدن زمان توسعه آشکار میکند.
آیا وجود یک باگ مانع تحویل کل پروژه است؟
به شدت، اثر و قاعده توافقشده بستگی دارد. ایراد مسدودکننده معمولاً مانع پذیرش است؛ موارد کماثر میتوانند با مسئول و موعد مشخص در پذیرش مشروط ثبت شوند.
برای هر قابلیت چند سناریوی UAT لازم است؟
عدد ثابتی وجود ندارد. مسیر موفق، خطاهای مهم، کنترل دسترسی و حالتهای مرزی پرتکرار باید پوشش داده شوند؛ جریانهای پرریسک سناریوهای بیشتری میخواهند.
خدمت و راهنماهای مرتبط
برای ادامه مسیر، صفحه خدمت مرتبط، نمونهکار و راهنماهای مکمل را ببینید.
منابع و مبنای تدوین
این راهنما با استفاده از مستندات فنی و منابع تخصصی زیر تدوین شده است. تصمیم نهایی هر پروژه باید با دادهها، قرارداد و شرایط واقعی همان سازمان تطبیق داده شود.