معیارهای پذیرش یا Acceptance Criteria | نحوه نوشتن + فرمت‌ها + مثال‌های کاربردی

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

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

در این مقاله، با زبانی ساده و همراه با مثال‌های ملموس یاد می‌گیریم که اکسپتنس کرایتریا چه هستند، چطور نوشته می‌شوند، چه تفاوتی با Definition of Done دارند، و چگونه می‌توان آن‌ها را به کمک فرمت‌هایی مثل Gherkin به‌صورت حرفه‌ای پیاده‌سازی کرد.

Acceptance Criteria چیست؟

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

چرا معیارهای پذیرش اهمیت دارند؟

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

معیارهای پذیرش مزایای زیر را دارند:

• هم‌راستا کردن انتظارات ذی‌نفعان

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

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

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

• پشتیبانی از تست کیس‌ها و اعتبارسنجی

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

تفاوت Acceptance Criteria با Definition of Done چیست؟

AC ها به‌طور اختصاصی برای هر یوزر استوری نوشته می‌شوند و رفتار یا نتایج مورد انتظار برای آن ویژگی خاص را مشخص می‌کنند.

تعریف انجام‌شده یا Definition of Done یک چک‌لیست سراسری و کلی برای تمام آیتم‌هایی‌ست که باید قبل از تحویل نهایی آن آیتم رعایت شود تا به‌عنوان انجام‌شده تلقی شود. مثلاً: بازبینی کد انجام شود، تست‌ها پاس شوند و نرم‌افزار روی محیط Staging مستقر شود؛ تا بگوییم این یک فیچر انجام شده است.

اجازه دهید تفاوت  AC و DoD را با یک مثال بررسی کنیم:

یوزر استوری:

«به‌عنوان یک کاربر، می‌خواهم رمز عبورم را ریست کنم تا بتوانم دوباره وارد حسابم شوم.»

معیارهای پذیرش / AC (مختص این داستان کاربر):

موارد زیر مشخص می‌کنند چه چیزهایی باید در این فیچر پیاده‌سازی شود تا مورد پذیرش قرار گیرد:

1. کاربر باید ظرف ۵ دقیقه ایمیل بازیابی رمز عبور خود را دریافت کند.

2. لینک ریست رمز پس از ۲۴ ساعت منقضی شود.

3. رمز عبور جدید باید حداقل ۸ کاراکتر باشد و حداقل یک عدد داشته باشد.

4. اگر ایمیل واردشده در سیستم ثبت نشده باشد، پیام خطای مناسب نمایش داده شود.

تعریف انجام‌شده / DoD (برای تمامی داستان‌های کاربر):

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

• کد نوشته، بررسی و به شاخه اصلی / Main اضافه شده باشد.

• تمام تست های واحد / Unit Tests با موفقیت پاس شده باشند.

• معیارهای پذیرش رعایت شده باشند.

• فیچر روی محیط Staging تست شده باشد.

• هیچ باگ بحرانی باقی نمانده باشد.

• مستندات (در صورت نیاز) به‌روزرسانی شده باشند.

• فیچر در جلسه اسپرینت ریویو دمو شده باشد.

به‌طور خلاصه...

انواع حالت‌های رایج معیارهای پذیرش

اکسپتنس کرایتریا می‌توانند در قالب‌های مختلفی نوشته شوند. انتخاب قالب مناسب به سلیقه تیم شما، نوع فیچر مورد نظر و میزان جزئیاتی که نیاز دارید بستگی دارد. در ادامه، سه نوع رایج AC ها را با مثال بررسی می‌کنیم:

1. معیارهای سناریو محور (Given / When / Then)

این مدل Acceptance Criteria بر پایه BDD یا توسعه رفتار محور شکل گرفته و برای تیم‌هایی مناسب است که می‌خواهند رفتار کاربر را در شرایط مختلف به‌صورت کاملاً شفاف توصیف کنند. در این روش، تأکید بر سه بخش است:

• فرض / Given: شرایط اولیه؛

• وقتی / When: عملی که انجام می‌شود؛

• آنگاه / Then: نتیجه مورد انتظار.

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

مثال:

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

• Given: من در صفحه ورود هستم؛

• When: روی «فراموشی رمز عبور» کلیک می‌کنم و ایمیلم را وارد می‌کنم؛

• Then: باید ظرف ۵ دقیقه یک ایمیل بازیابی رمز عبور دریافت کنم.

2. معیارهای قاعده‌محور (Rule-Oriented)

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

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

مثال:

• لینک بازیابی باید ظرف ۲۴ ساعت منقضی شود.

• رمز جدید باید حداقل ۸ کاراکتر و حداقل یک عدد داشته باشد.

• پیام خطا نباید مشخص کند آیا ایمیل ثبت شده است یا نه.

3. قالب‌های ترکیبی یا سفارشی

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

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

مثال:

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

• اگر ایمیل نامعتبر یا خالی باشد ← پیام خطای عمومی نشان داده شود؛ بدون اینکه بگوید این ایمیل که به اشتباه وارد شده در سیستم وجود دارد یا نه.

به طور خلاصه:

چه کسی Acceptance Criteria را می‌نویسد؟

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

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

چه زمانی معیارهای پذیرش را بنویسیم؟

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

در حین بک لاگ ریفاینمنت

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

قبل از برنامه‌ریزی اسپرینت

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

درست به‌موقع

نوشتن خیلی زود AC‌ها احتمالاً منجر به نوشتن جزئیات غیرضروری می‌شود. خیلی دیر هم می‌تواند منجر به سردرگمی یا انتظارات نادرست شود. هدف این است که معیارهای پذیرش به‌موقع نوشته شوند؛ نه خیلی زود و نه خیلی دیر، تا از شفافیت و مرتبط بودن آن‌ها کم نشود.

نکات مهم نوشتن Acceptance Criteria قدرتمند

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

• یوزر استوری: همیشه معیارهای پذیرش را به یوزر استوری‌ها ارتباط دهید. این کار کمک می‌کند AC ها با عملکرد و خروجی مورد انتظار خود ارتباط دقیق‌تری بگیرند.

• نتایج مورد انتظار: سعی کنید همیشه تجربه کاربری حاصل از انجام AC و خروجی‌های مطلوب را به‌وضوح بیان کنید. دقیقاً بگویید که فیچر باید چه ارزشی برای کاربر ایجاد کند؛ همچنین از تمرکز روی جزئیات فنی پیاده‌سازی پرهیز کنید و فضا را پیچیده نکنید.

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

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

• قابلیت اندازه‌گیری: در صورت امکان، معیارها را با واژگان قابل‌اندازه‌گیری بنویسید. این موضوع به تعیین دقیق «قبول» یا «رد» شدن در زمان تست کمک می‌کند.

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

• تست پذیرش کاربر / UAT: در کنار معیارهای تیم توسعه، معیارهای مربوط به تست پذیرش کاربر را نیز در نظر بگیرید. این معیارها از دیدگاه کاربردپذیری بررسی می‌شوند و مشخص می‌کنند که آیا ویژگی با انتظارات کاربر مطابقت دارد یا خیر.

• همکاری: نوشتن معیارها باید به‌صورت مشارکتی انجام شود. مالک محصول، تیم توسعه و سایر ذی‌نفعان مرتبط باید در فرایند تدوین معیارها مشارکت کنند تا مجموعه‌ای جامع و چندوجهی شکل بگیرد.

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

مثال‌هایی از نوشتن معیارهای پذیرش

در این بخش چند نمونه خوب و کاربردی از معیارهای پذیرش را برای شما آورده‌ایم:

مثال ۱

User Story:

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

Acceptance Criteria:

• عملکرد جستجو باید نتایجی را نمایش دهد که دقیقاً با نام واردشده مطابقت دارند.

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

• نتایج جستجو باید به شکل واضح و منظم نمایش داده شوند و شامل نام محصول، تصویر و قیمت باشند.

• صفحه نتایج باید قابلیت صفحه‌بندی داشته باشد و در هر صفحه حداکثر ۲۰ آیتم نمایش داده شود.

مثال ۲

User Story:

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

Acceptance Criteria:

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

• امکان ویرایش نام، نام خانوادگی، ایمیل و شماره تلفن برای کاربر فراهم باشد.

• پس از کلیک روی دکمه «ذخیره»، تغییرات باید با موفقیت در سیستم ثبت شوند.

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

مثال ۳

User Story:

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

Acceptance Criteria:

• در پنل مدیریتی، بخشی اختصاصی برای گزارش‌دهی در نظر گرفته شده باشد.

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

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

• کاربر بتواند گزارش‌ها را در فرمت‌های مختلف (مثل CSV و PDF) دانلود کند.

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

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

مثال 1 از فرمت Gherkin

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

توضیح:
در این مثال، شرایط اولیه مشخص است (کاربر در صفحه ورود است و حساب فعال دارد)، اقدامی که کاربر انجام می‌دهد تعریف شده (واردکردن اطلاعات و کلیک)؛ و نتایج مورد انتظار نیز واضح و قابل تست هستند.

مثال 2 از فرمت Gherkin

افزودن محصول به سبد خرید

مزیت استفاده از Gherkin:

• ساده و قابل‌درک برای همه اعضای تیم (حتی غیر فنی‌ها)

• قابل‌تبدیل به تست خودکار در ابزارهای BDD مانند Cucumber

• ساختار منطقی و منظم برای توصیف رفتارهای مورد انتظار سیستم

• کمک به هم‌راستایی بهتر بین تحلیلگران کسب‌وکار، توسعه‌دهندگان و تسترها

جمع‌بندی

معیارهای پذیرش یا Acceptance Criteria یکی از مؤثرترین ابزارها برای شفاف‌سازی انتظارات، کاهش ابهام و تضمین کیفیت در فرایند توسعه چابک هستند. AC‌ ها به تیم کمک می‌کنند تا از ابتدا بدانند «چه چیزی» باید تحویل داده شود، نه صرفاً «چگونه» باید تحویل داده شود.

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