معیار پذیرش نرم‌افزار اختصاصی باید روشن کند چه کسی، در چه شرایطی، کدام نتیجه را بررسی می‌کند. جمله‌هایی مثل «صفحه خوب کار کند» یا «سیستم سریع باشد» برای تحویل کافی نیستند؛ چون تیم و کارفرما ممکن است از آن‌ها برداشت متفاوتی داشته باشند. در این راهنما معیارها را به سناریوهای قابل مشاهده تبدیل می‌کنیم تا دامنه، آزمون و رفع نقص پیش از پایان کار شفاف باشد.
معیار پذیرش با فهرست قابلیت‌ها فرق دارد
قابلیت می‌گوید سیستم چه کاری می‌تواند بکند؛ معیار پذیرش می‌گوید چه نتیجه‌ای برای پذیرفتن آن قابلیت لازم است. «کاربر می‌تواند پیش‌فاکتور بسازد» یک قابلیت است. معیار دقیق‌تر می‌تواند بگوید: «وقتی کاربر مجاز اقلام و مشتری را انتخاب می‌کند، پیش‌فاکتور با شناسهٔ قابل پیگیری و جمع درست نمایش داده می‌شود؛ رکورد در سابقهٔ مشتری ثبت می‌شود و کاربر غیرمجاز امکان تغییرش را ندارد.» جزئیات نهایی باید با قرارداد و قواعد محصول شما سازگار شود.
برای هر سناریو چه بنویسیم؟
از قالب «با فرض اینکه… وقتی… آنگاه…» استفاده کنید. نقش، دادهٔ ورودی، نتیجهٔ قابل مشاهده و حالت شکست را بنویسید. نمونه:
| بخش | نمونهٔ معیار |
|---|---|
| نقش | کاربر فروشِ مجاز به ثبت پیش‌فاکتور |
| پیش‌شرط | مشتری و قلم قابل فروش در سیستم وجود دارند |
| اقدام | کاربر قلم را انتخاب و پیش‌فاکتور را ذخیره می‌کند |
| نتیجه | شناسه، اقلام و جمع در صفحه و سابقهٔ مشتری دیده می‌شوند |
| حالت منفی | کاربر بدون دسترسی نمی‌تواند رکورد را تغییر دهد |
برای معیارهای غیرعملکردی نیز روش مشاهده را مشخص کنید. اگر کیفیت موبایل، دسترس‌پذیری، پشتیبان‌گیری یا امنیت اهمیت دارد، محیط آزمون، نقش بررسی‌کننده و شواهد مورد انتظار را بنویسید. از عباراتی مانند «امنیت کامل» استفاده نکنید؛ کنترل مشخص، مسئول و مدرک آزمون را تعیین کنید. چارچوب NIST CSF 2.0 دسته‌بندی مفیدی برای گفت‌وگو دربارهٔ حکمرانی و ریسک امنیتی ارائه می‌کند، اما به‌تنهایی گواهی یا تأیید محصول شما نیست. راهنمای رسمی NIST
فهرست تحویل را از ابتدا توافق کنید
تحویل فقط فایل نهایی نیست. نسخهٔ قابل اجرا، دسترسی‌ها، مستندات راه‌اندازی، روش پشتیبان‌گیری و بازیابی، اتصال‌های فعال، دادهٔ آزمایشی مجاز، فهرست موارد خارج از دامنه و مسئول پشتیبانی پس از تحویل را در توافق پروژه مشخص کنید. اگر سورس‌کد، مخزن، دامنه یا حساب ابری جزو تحویل است، مالکیت و روش انتقال آن را پیش از آغاز روشن کنید. چیزی را که در قرارداد یا صورت‌جلسه نیامده، فرض‌شده تلقی نکنید.
نقص، تغییر دامنه و تصمیم پذیرش
برای هر مورد آزمون، نتیجهٔ قبول/رد، محیط و نسخه، شواهد، شدت اثر بر کار و مسئول پیگیری را ثبت کنید. پیشاپیش روشن کنید چه کسی نقص را دسته‌بندی می‌کند، چه موردی مانع پذیرش است و اصلاح چگونه دوباره بررسی می‌شود. درخواست قابلیت تازه را از نقص جدا کنید: اولی تغییر دامنه و برآورد تازه می‌خواهد؛ دومی عدم انطباق با معیار توافق‌شده است. آستانهٔ شدت یا تعداد نقص را از یک مقاله کپی نکنید؛ آن را متناسب با خطر و قرارداد همان پروژه تعیین کنید.
ملاحظات آزمون در پروژه‌های ایرانی
سناریوها را با تقویم شمسی و میلادی مورد استفاده، رقم‌های فارسی و لاتین، نمایش و محاسبهٔ ریال/تومان، منطقهٔ زمانی، زبان رابط و اتصال‌های واقعی کسب‌وکار اجرا کنید. اگر جریان فاکتور یا مالیات در دامنه است، نمونه‌های مرزی و قواعد مرجع را با حسابدار یا منبع رسمی کنترل کنید. این مقاله حکم مالیاتی یا حقوقی صادر نمی‌کند. برای اتصال پیامک یا پرداخت، آزمون را در محیط و حسابی انجام دهید که شرایط واقعی آن کسب‌وکار را دارد؛ تصویر یا نمونهٔ آزمایشی، تأیید اتصال زنده نیست.
جلسهٔ پذیرش را قابل بازتولید کنید
کاربر نماینده را از قبل معرفی کنید، نسخه و دادهٔ آزمون را ثابت نگه دارید، هر سناریو را طبق ترتیب توافق‌شده اجرا کنید و نتیجه را با مسئولان ثبت کنید. برای سناریوی ردشده، گام بازتولید و انتظار را بنویسید. پس از اصلاح، همان آزمون را دوباره اجرا کنید و اثر اصلاح بر گردش‌کارهای مرتبط را نیز بررسی کنید. یک صورت‌جلسهٔ کوتاه با نسخه، موارد قبول‌شده، موارد باز و تصمیم نهایی از اختلاف برداشت جلوگیری می‌کند.
برای دیدن نمونهٔ فرایندهای CRM، صفحهٔ CRM آرویون و دموی نمایشی کیمیا را ببینید. اطلاعات و شرکت داخل دمو ساختگی و نمایشی‌اند، نه تحویل به مشتری واقعی. اگر برای سامانهٔ اختصاصی نیاز دارید، خدمات توسعهٔ وب‌اپلیکیشن و فرم درخواست CRM را مرور کنید.
پرسش‌های متداول
چه کسی معیار پذیرش را می‌نویسد؟
صاحب فرایند و نمایندهٔ کاربران باید نتیجهٔ کاری را تعریف کنند؛ تیم فنی کمک می‌کند معیار به رفتاری قابل آزمون تبدیل شود. یک طرف نباید به‌تنهایی فرض‌های طرف دیگر را تعیین کند.
آیا لازم است همهٔ ایرادها قبل از پذیرش بسته شوند؟
این تصمیم به قرارداد و اثر هر مورد بر کار بستگی دارد. از ابتدا فرق میان مانع پذیرش، نقص قابل پیگیری و درخواست توسعهٔ جدید را تعیین کنید و تصمیم را ثبت کنید.
آیا قبولی آزمون به معنی امنیت یا کیفیت کامل است؟
خیر. آزمون فقط سناریوها و نسخهٔ مشخص‌شده را پوشش می‌دهد. محدودهٔ آزمون، محدودیت‌ها و مسئولیت رسیدگی پس از تحویل را شفاف بنویسید.
منابع و محدودهٔ بررسی
راهنمای NIST دربارهٔ پذیرش نرم‌افزار بر مشارکت کاربران در تعریف نیازها و معیارهای پذیرش تأکید می‌کند. چارچوب NIST CSF 2.0 نیز مرجع گفت‌وگو دربارهٔ پیامدهای امنیتی است. این منابع جای قرارداد، آزمون مستقل یا بررسی متخصص را نمی‌گیرند.
