در توسعه نرمافزار، یکی از مشکلات رایج این است که اعضای تیم برداشت یکسانی از نیازمندیها نداشته باشند. ممکن است Product Owner دقیقاً بداند از یک قابلیت چه انتظاری دارد، Developer برداشت متفاوتی از آن داشته باشد و Tester نیز نرمافزار را بر اساس تفسیر دیگری از Requirement ارزیابی کند.
برای مثال، فرض کنید در یک User Story نوشته شده است:
«بهعنوان یک کاربر، میخواهم بتوانم با ایمیل و رمز عبور وارد سیستم شوم تا به حساب کاربری خود دسترسی داشته باشم.»
اما از کجا بدانیم این User Story چه زمانی واقعاً تکمیل شده است؟ آیا نمایش صفحه Dashboard بعد از ورود کافی است؟ اگر رمز عبور اشتباه باشد چه اتفاقی باید بیفتد؟ آیا باید پیام خطا نمایش داده شود؟ آیا ایمیل نامعتبر باید توسط سیستم شناسایی شود؟ بعد از چند بار ورود ناموفق چه اتفاقی باید رخ دهد؟
اینجاست که Acceptance Criteria یا معیارهای پذیرش اهمیت پیدا میکنند.
معیارهای پذیرش مشخص میکنند که یک User Story یا قابلیت نرمافزاری برای اینکه قابل پذیرش باشد، باید چه شرایطی را برآورده کند. این معیارها به اعضای تیم کمک میکنند درباره رفتار و نتیجه مورد انتظار به یک درک مشترک برسند و در ادامه، مبنای مناسبی برای بررسی و تست قابلیت موردنظر فراهم میکنند.
از دید تست نرمافزار، Acceptance Criteria اهمیت ویژهای دارد؛ زیرا Tester میتواند با استفاده از آن مشخص کند چه رفتارهایی باید بررسی شوند، چه شرایط مهمی باید پوشش داده شوند و آیا پیادهسازی انجامشده با نیاز مورد انتظار مطابقت دارد یا خیر.
با این حال، Acceptance Criteria با Acceptance Testing یا User Acceptance Testing (UAT) یکسان نیست. Acceptance Criteria شرایطی را مشخص میکند که برای پذیرش یک قابلیت باید برآورده شوند، در حالی که Acceptance Testing و UAT به فرایند ارزیابی و پذیرش نرمافزار مربوط میشوند. در ادامه مقاله، این تفاوتها را با مثالهای عملی بررسی خواهیم کرد.
در این مقاله ابتدا با مفهوم Acceptance Criteria (معیارهای پذیرش) آشنا میشویم، سپس ویژگیهای یک معیار پذیرش خوب و روشهای نوشتن آن را بررسی میکنیم. در ادامه نیز ارتباط Acceptance Criteria با User Story، Test Case، Acceptance Testing، UAT، Definition of Done، Agile، Scrum و BDD را توضیح خواهیم داد تا در پایان، دید کاملی نسبت به نقش معیارهای پذیرش در فرایند توسعه و تست نرمافزار داشته باشید.
Acceptance Criteria چیست؟ | معیار پذیرش چیست؟
Acceptance Criteria یا معیارهای پذیرش مجموعهای از شرایط مشخصی است که یک User Story، قابلیت یا Feature باید آنها را برآورده کند تا بتوان آن را مطابق انتظار ذینفعان و نیازهای کسبوکار، قابل پذیرش در نظر گرفت.
به زبان ساده، Acceptance Criteria مشخص میکند:
«برای اینکه بگوییم این قابلیت درست و قابل قبول است، چه شرایطی باید برقرار باشد؟»
این معیارها کمک میکنند اعضای تیم، از جمله Product Owner، Business Analyst، Developer و Tester، برداشت مشترکتری از نتیجه مورد انتظار داشته باشند. بنابراین Acceptance Criteria فقط برای Tester نوشته نمیشود و نباید آن را صرفاً فهرستی از موارد تست در نظر گرفت.
یک مثال ساده
فرض کنید در یک فروشگاه اینترنتی چنین User Story داشته باشیم:
بهعنوان یک مشتری، میخواهم بتوانم محصولی را به سبد خرید اضافه کنم تا بتوانم آن را خریداری کنم.
این User Story هدف و نیاز کاربر را بیان میکند، اما هنوز جزئیات کافی برای مشخصکردن شرایط پذیرش آن وجود ندارد.
برای این User Story میتوان معیارهای پذیرش زیر را تعریف کرد:
- کاربر باید بتواند یک محصول موجود را به سبد خرید اضافه کند.
- پس از افزودن محصول، تعداد اقلام موجود در سبد خرید باید بهروزرسانی شود.
- قیمت محصول باید در سبد خرید نمایش داده شود.
- اگر محصول موجود نباشد، نباید امکان افزودن آن به سبد خرید وجود داشته باشد.
- در صورت موفقیتآمیز بودن عملیات، محصول باید در سبد خرید نمایش داده شود.
در این مثال، User Story بیان میکند کاربر چه چیزی میخواهد و چرا، در حالی که Acceptance Criteria مشخص میکند این نیاز تحت چه شرایطی برآوردهشده در نظر گرفته میشود.
چرا این تفاوت مهم است؟
اگر فقط User Story را داشته باشیم، ممکن است اعضای تیم درباره جزئیات رفتار سیستم برداشتهای متفاوتی داشته باشند.
برای مثال، Developer ممکن است تصور کند اضافهشدن محصول به سبد خرید کافی است؛ در حالی که Product Owner انتظار دارد تعداد اقلام، قیمت محصول و وضعیت موجودی نیز بهدرستی مدیریت شوند.
Acceptance Criteria این ابهام را کاهش میدهد و یک معیار مشترک برای بررسی نتیجه ایجاد میکند.
از طرف دیگر، همین معیارها میتوانند در مرحله تست به Tester کمک کنند تا Test Scenario و Test Caseهای مناسب را طراحی کند. برای مثال، معیار «اگر محصول موجود نباشد، نباید امکان افزودن آن به سبد خرید وجود داشته باشد» میتواند به سناریویی برای بررسی رفتار سیستم در یک Negative Scenario منجر شود.
بنابراین میتوان رابطه این مفاهیم را به شکل زیر خلاصه کرد:
- User Story → نیاز و هدف کاربر را بیان میکند.
- Acceptance Criteria → شرایط برآوردهشدن آن نیاز را مشخص میکند.
- Test Case → بررسی میکند که آیا این شرایط در سیستم واقعاً برقرار هستند یا خیر.
البته این رابطه به این معنا نیست که هر Acceptance Criterion دقیقاً معادل یک Test Case است؛ یک معیار پذیرش ممکن است به چندین سناریو و Test Case منجر شود.
یک تعریف کوتاه برای به خاطر سپردن
Acceptance Criteria مجموعهای از شرایط مشخص و قابل بررسی است که تعیین میکند یک User Story یا قابلیت، چه زمانی نیازمندی مورد انتظار را برآورده کرده و قابل پذیرش است.
چرا Acceptance Criteria اهمیت دارد؟
در یک پروژه نرمافزاری، صرفاً داشتن یک Requirement یا User Story به این معنا نیست که همه اعضای تیم برداشت یکسانی از آن داشته باشند. هرچه یک نیازمندی کلیتر باشد، احتمال تفسیرهای متفاوت نیز بیشتر میشود.
Acceptance Criteria یا معیارهای پذیرش کمک میکند این ابهام کاهش پیدا کند و تیم درباره رفتار و نتیجه مورد انتظار یک قابلیت به درک مشترکی برسد.
۱. کاهش ابهام در نیازمندیها
یکی از مهمترین کاربردهای Acceptance Criteria، تبدیل یک نیاز کلی به شرایط مشخص و قابل بررسی است.
«کاربر باید بتواند رمز عبور خود را تغییر دهد.»
این جمله بهتنهایی سؤالات زیادی ایجاد میکند:
- آیا کاربر باید رمز عبور فعلی را وارد کند؟
- حداقل طول رمز عبور جدید چقدر است؟
- اگر رمز عبور جدید با رمز قبلی یکسان باشد چه اتفاقی میافتد؟
- در صورت واردکردن رمز عبور نامعتبر چه پیامی باید نمایش داده شود؟
- آیا بعد از تغییر رمز، کاربر باید دوباره وارد سیستم شود؟
با تعریف معیارهای پذیرش مناسب، این ابهامها میتوانند قبل از پیادهسازی یا تست شناسایی و برطرف شوند.
۲. ایجاد درک مشترک بین اعضای تیم
Acceptance Criteria فقط برای Tester نوشته نمیشود.
Product Owner، Business Analyst، Developer و Tester میتوانند هنگام تعریف و بررسی معیارهای پذیرش درباره رفتار مورد انتظار سیستم گفتگو کنند.
این همکاری باعث میشود اختلاف برداشتها زودتر شناسایی شوند؛ یعنی قبل از اینکه یک Requirement به کد تبدیل شود و در مرحله تست مشخص شود که اعضای تیم درباره نیاز اصلی برداشت متفاوتی داشتهاند.
۳. کمک به Developer برای پیادهسازی صحیح
Acceptance Criteria برای Developer نیز یک مرجع مهم برای درک رفتار مورد انتظار Feature محسوب میشود.
Developer با بررسی معیارهای پذیرش میتواند بهتر متوجه شود که Feature موردنظر باید چه رفتارهایی داشته باشد و چه شرایطی باید در پیادهسازی در نظر گرفته شوند.
البته Acceptance Criteria نباید بهگونهای نوشته شود که نحوه پیادهسازی فنی را به Developer دیکته کند. تمرکز آن باید روی رفتار و نتیجه مورد انتظار سیستم باشد، نه جزئیات کدنویسی و Implementation.
۴. کمک به Tester برای طراحی تست
یکی از مهمترین کاربردهای Acceptance Criteria برای تیم QA و تست نرمافزار، استفاده از آن بهعنوان یکی از ورودیهای طراحی تست است.
Tester میتواند هر معیار پذیرش را بررسی کند و بر اساس آن، Test Scenario و Test Caseهای مناسب را شناسایی کند.
«در صورت واردکردن رمز عبور اشتباه، سیستم باید پیام خطای مناسب نمایش دهد.»
بر اساس این معیار، Tester میتواند سناریوهای مختلفی را برای بررسی رفتار سیستم در نظر بگیرد، از جمله:
- واردکردن رمز عبور اشتباه
- واردکردن رمز عبور خالی
- بررسی ترکیبهای مختلف اطلاعات نامعتبر
- بررسی متن و محل نمایش پیام خطا
- بررسی رفتار سیستم پس از نمایش خطا
بنابراین Acceptance Criteria میتواند به Tester کمک کند تا نیازهای قابل تست را بهتر شناسایی و سناریوهای مرتبط را برنامهریزی کند؛ هرچند بهتنهایی تضمینکننده کامل بودن Test Coverage نیست.
۵. ایجاد مبنایی برای ارزیابی نتیجه
Acceptance Criteria یک نقطه مرجع برای بررسی این موضوع ایجاد میکند که آیا یک User Story یا Feature به نتیجه مورد انتظار رسیده است یا خیر.
به جای اینکه در پایان توسعه صرفاً بپرسیم:
«آیا این Feature آماده است؟»
میتوانیم بررسی کنیم:
«آیا معیارهای پذیرش تعریفشده برای این Feature برآورده شدهاند؟»
این رویکرد، ارزیابی نتیجه را شفافتر و قابل اتکاتر میکند.
۶. شناسایی زودهنگام مشکلات Requirement
گاهی هنگام تلاش برای تعریف Acceptance Criteria مشخص میشود که خود Requirement هنوز به اندازه کافی واضح نیست.
«سیستم باید عملکرد خوبی داشته باشد.»
این عبارت برای تعریف یک معیار پذیرش مناسب نیست، زیرا «عملکرد خوب» قابل اندازهگیری و تست نیست.
اما هنگام تلاش برای تبدیل این نیاز به یک معیار پذیرش، تیم مجبور میشود درباره مفهوم «عملکرد خوب» تصمیم بگیرد؛ برای مثال مشخص کند یک عملیات باید حداکثر در چه مدت زمانی پاسخ دهد.
در نتیجه، Acceptance Criteria میتواند به شناسایی ابهام، نقص و تناقض در نیازمندیها پیش از ورود به مراحل بعدی توسعه کمک کند.
۷. کاهش دوبارهکاری
هرچه ابهام در نیازمندی دیرتر شناسایی شود، اصلاح آن معمولاً هزینه بیشتری خواهد داشت.
اگر Developer بر اساس یک برداشت اشتباه Feature را پیادهسازی کند و این موضوع در مرحله تست یا حتی بعد از انتشار مشخص شود، اصلاح آن میتواند به تغییر کد، تست مجدد و حتی تغییر سایر بخشهای سیستم منجر شود.
تعریف مناسب Acceptance Criteria از ابتدا میتواند بخشی از این مشکلات را پیش از شروع توسعه یا در مراحل اولیه شناسایی کند و در نتیجه، احتمال دوبارهکاری را کاهش دهد.
جمعبندی
بنابراین میتوان گفت Acceptance Criteria یک زبان مشترک برای بیان نتیجه مورد انتظار یک قابلیت ایجاد میکند.
این معیارها به تیم کمک میکنند:
نیازمندی را بهتر درک کنند → ابهامها را زودتر شناسایی کنند → قابلیت را بر اساس انتظار مشخص توسعه دهند → تست مناسب طراحی کنند → و در نهایت درباره قابل پذیرش بودن نتیجه تصمیم بگیرند.
در بخش بعدی بررسی میکنیم که Acceptance Criteria چه زمانی و چگونه باید تعریف شود و آیا لازم است حتماً قبل از شروع توسعه نوشته شده باشد یا میتواند در طول فرایند توسعه تکمیل و اصلاح شود.
Acceptance Criteria چه زمانی و چگونه تعریف میشود؟
یکی از پرسشهای مهم درباره Acceptance Criteria (معیارهای پذیرش) این است که این معیارها دقیقاً چه زمانی باید تعریف شوند. آیا باید قبل از شروع توسعه کاملاً مشخص باشند یا میتوان آنها را در طول کار روی User Story تغییر و تکمیل کرد؟
پاسخ این است که Acceptance Criteria معمولاً همزمان با تحلیل و آمادهسازی User Story شکل میگیرد، اما در رویکردهای Agile میتواند در طول فرایند توسعه نیز مورد بحث، اصلاح و تکمیل قرار گیرد.
Acceptance Criteria معمولاً چه زمانی تعریف میشود؟
در یک فرایند Agile، معمولاً ابتدا یک نیاز کسبوکار یا نیاز کاربر به شکل یک User Story بیان میشود. سپس تیم درباره جزئیات آن گفتگو میکند و شرایطی را مشخص میکند که باید برای پذیرش آن User Story برقرار باشند.
به شکل ساده میتوان این روند را چنین در نظر گرفت:
نیاز کسبوکار → User Story → Acceptance Criteria → توسعه → تست و ارزیابی
البته این فرایند لزوماً خطی و یکطرفه نیست. ممکن است هنگام طراحی، توسعه یا تست مشخص شود که یکی از معیارهای پذیرش ناقص، مبهم یا نیازمند تصمیمگیری بیشتری است. در چنین شرایطی تیم میتواند دوباره به سراغ Requirement و Acceptance Criteria برگردد و آنها را اصلاح یا تکمیل کند.
آیا Acceptance Criteria باید قبل از شروع توسعه آماده باشد؟
بهتر است Acceptance Criteria پیش از شروع پیادهسازی یک User Story به اندازه کافی مشخص و قابل فهم باشد؛ زیرا در این حالت Developer و Tester درک روشنتری از نتیجه مورد انتظار خواهند داشت.
اما «آماده بودن» به معنای کامل و غیرقابلتغییر بودن نیست.
در Agile، نیازمندیها میتوانند در طول زمان تکامل پیدا کنند. بنابراین ممکن است در جلسات Backlog Refinement، Sprint Planning یا حتی هنگام اجرای User Story، اطلاعات جدیدی به دست آید و معیارهای پذیرش نیز بر اساس آن اصلاح یا تکمیل شوند.
نکته مهم این است که تغییر Acceptance Criteria باید آگاهانه و با توافق افراد مرتبط انجام شود و نباید صرفاً برای توجیه یک پیادهسازی انجامشده یا عبور از یک مشکل تستی تغییر کند.
نقش جلسات گفتگو و Backlog Refinement
یکی از زمانهای مناسب برای بررسی Acceptance Criteria، جلسات Backlog Refinement است.
در این جلسات، اعضای تیم میتوانند درباره User Story و معیارهای پذیرش آن سؤال کنند، ابهامهای احتمالی را شناسایی کنند و درباره رفتار مورد انتظار به توافق برسند.
برای مثال، اگر User Story این باشد:
«بهعنوان مشتری، میخواهم سفارش خود را لغو کنم.»
ممکن است تیم درباره موارد مختلفی سؤال کند:
- سفارش تا چه مرحلهای قابل لغو است؟
- آیا سفارش ارسالشده هم قابل لغو است؟
- آیا مبلغ پرداختشده به کاربر بازگردانده میشود؟
- بازپرداخت چه زمانی انجام میشود؟
- اگر لغو سفارش ناموفق باشد چه اتفاقی رخ میدهد؟
پاسخ به این سؤالها میتواند به تعریف یا اصلاح Acceptance Criteria منجر شود و درک مشترک تیم از رفتار مورد انتظار را افزایش دهد.
Acceptance Criteria در طول توسعه
گاهی برخی جزئیات تنها زمانی مشخص میشوند که تیم وارد مرحله طراحی یا پیادهسازی میشود.
برای مثال، ممکن است هنگام توسعه مشخص شود که یک حالت خاص در Requirement اولیه در نظر گرفته نشده است. در چنین شرایطی تیم باید ابتدا درباره رفتار مورد انتظار تصمیم بگیرد و در صورت نیاز، Acceptance Criteria را بهروزرسانی کند.
این موضوع اهمیت یک اصل را نشان میدهد:
Acceptance Criteria یک مجموعه شرایط قابل بازبینی است و تا زمانی که نیازمندی در حال شکلگیری و تکامل است، میتواند بر اساس تصمیمات جدید اصلاح یا تکمیل شود.
با این حال، پس از اینکه تیم روی معیارهای پذیرش به توافق رسید و توسعه و تست بر اساس آنها انجام شد، تغییر آنها باید کنترلشده و شفاف باشد؛ زیرا تغییر معیارها میتواند روی Scope، پیادهسازی و Test Caseها تأثیر بگذارد.
چه زمانی Acceptance Criteria باید نهایی شود؟
برای یک User Story که قرار است وارد Sprint شود، بهتر است تیم پیش از شروع جدی توسعه به یک درک مشترک و قابل اتکا از Acceptance Criteria رسیده باشد.
به بیان ساده:
«قبل از شروع توسعه باید بدانیم چه چیزی را میخواهیم بسازیم و از کجا خواهیم فهمید که ساختهشدن آن موفق بوده است.»
اما این موضوع نباید به این معنا باشد که تیم در Agile باید تمام جزئیات محصول را از ماهها قبل مشخص کند. معیارهای پذیرش مربوط به یک Story میتوانند زمانی که آن Story به اندازه کافی آماده ورود به توسعه است، دقیقتر و نهاییتر شوند.
یک نکته مهم برای Tester
از دید Tester، بررسی Acceptance Criteria فقط در زمان اجرای تست اهمیت ندارد.
Tester میتواند از همان مرحله بررسی User Story، معیارهای پذیرش را از نظر شفافیت، کامل بودن، قابلیت تست و پوشش شرایط مهم ارزیابی کند.
اگر Tester قبل از شروع توسعه متوجه شود که مثلاً یک Acceptance Criterion قابل اندازهگیری نیست یا یک حالت مهم در آن مشخص نشده است، مطرحکردن این موضوع در همان مرحله میتواند از ایجاد مشکل در مراحل بعدی جلوگیری کند.
بنابراین Tester در Acceptance Criteria فقط یک مصرفکننده تست نیست؛ بلکه میتواند با پرسیدن سؤالهای مناسب و شناسایی ابهامها، در شکلگیری و بهبود معیارهای پذیرش نیز نقش داشته باشد.
در بخش بعدی بررسی میکنیم که چه کسی مسئول تعریف Acceptance Criteria است و چرا پاسخ این سؤال صرفاً «Product Owner» نیست.
چه کسی Acceptance Criteria را تعریف میکند؟
یکی از برداشتهای رایج این است که Acceptance Criteria (معیارهای پذیرش) فقط توسط Product Owner نوشته میشود. در عمل، مسئولیت و نحوه تعریف این معیارها میتواند به ساختار سازمان، روش کاری تیم و نقشهای موجود در پروژه بستگی داشته باشد.
مهمتر از اینکه چه کسی متن نهایی را مینویسد، این است که افراد مرتبط با نیازمندی درباره شرایط پذیرش به درک و توافق مشترک برسند.
نقش Product Owner
در تیمهای Agile، Product Owner معمولاً مسئول نمایندگی نیازهای کسبوکار و بیشینهکردن ارزش محصول است. بنابراین طبیعی است که در تعریف Acceptance Criteria نقش مهمی داشته باشد.
Product Owner میتواند درباره مواردی مانند اینها توضیح دهد:
- کاربر یا کسبوکار چه نتیجهای انتظار دارد؟
- چه رفتارهایی برای پذیرش یک Feature ضروری هستند؟
- چه شرایطی باعث میشوند یک قابلیت از دید محصول قابل قبول باشد؟
با این حال، این موضوع به این معنا نیست که Product Owner باید همه معیارها را بهتنهایی و بدون مشارکت تیم بنویسد.
نقش Business Analyst
در سازمانهایی که نقش Business Analyst (BA) وجود دارد، این فرد نیز میتواند نقش مهمی در تحلیل و مستندسازی معیارهای پذیرش داشته باشد.
Business Analyst میتواند با بررسی نیازهای کسبوکار:
- ابهامهای Requirement را شناسایی کند.
- نیازهای مختلف Stakeholderها را جمعآوری کند.
- شرایط و قوانین کسبوکار را به شکل شفافتر بیان کند.
- به تبدیل نیازهای کلی به معیارهای مشخص و قابل بررسی کمک کند.
بهخصوص در پروژههایی که نیازمندیها پیچیده هستند، مشارکت BA میتواند به افزایش کیفیت Acceptance Criteria کمک کند.
نقش Developer
ممکن است در نگاه اول تصور شود Developer فقط باید Acceptance Criteria را دریافت و بر اساس آن کدنویسی کند؛ اما مشارکت Developer در مرحله تعریف و بررسی معیارها نیز ارزشمند است.
Developer میتواند درباره مواردی مانند موارد زیر بازخورد ارائه کند:
- امکانپذیری فنی
- وابستگی به سایر اجزای سیستم
- محدودیتهای فنی
- شرایط و حالتهای خاصی که ممکن است روی پیادهسازی تأثیر بگذارند
این مشارکت کمک میکند معیارهایی تعریف نشوند که از نظر فنی مبهم، متناقض یا غیرواقعبینانه هستند.
نقش Tester یا QA
Tester نیز میتواند نقش مهمی در تعریف و بازبینی Acceptance Criteria داشته باشد.
از آنجا که Tester باید بتواند بر اساس معیارهای پذیرش، رفتار سیستم را ارزیابی کند، میتواند سؤالهایی مطرح کند که به کشف ابهامها و شرایط فراموششده کمک کنند.
برای مثال، اگر Acceptance Criteria چنین باشد:
«کاربر باید بتواند رمز عبور خود را تغییر دهد.»
Tester ممکن است بپرسد:
- اگر رمز عبور فعلی اشتباه باشد چه اتفاقی رخ میدهد؟
- اگر رمز جدید شرایط لازم را نداشته باشد چه میشود؟
- آیا رمز جدید میتواند با رمز قبلی یکسان باشد؟
- پس از تغییر رمز، Session فعلی کاربر چه وضعیتی خواهد داشت؟
این پرسشها میتوانند به تکمیل Acceptance Criteria و روشنترشدن رفتار مورد انتظار سیستم کمک کنند.
بنابراین مشارکت Tester در این مرحله فقط برای آمادهکردن Test Case نیست؛ بلکه میتواند به بهبود و شفافترشدن Requirement نیز کمک کند.
نقش Stakeholderها و کاربران
در برخی پروژهها، مخصوصاً زمانی که یک Feature مستقیماً با فرایندهای کسبوکار یا نیازهای کاربران نهایی مرتبط است، Stakeholderها یا نمایندگان کاربران نیز ممکن است در مشخصکردن شرایط پذیرش مشارکت داشته باشند.
آنها میتوانند اطلاعاتی درباره موارد زیر ارائه کنند:
- قوانین کسبوکار
- فرایندهای واقعی
- انتظارات کاربران
- محدودیتهای عملیاتی
این اطلاعات در بسیاری از پروژهها برای تعریف معیارهای پذیرش دقیق و واقعبینانه ضروری هستند.
پس مسئول اصلی چه کسی است؟
بهتر است به جای اینکه بگوییم:
«Acceptance Criteria را Product Owner مینویسد.»
بگوییم:
Acceptance Criteria معمولاً با مشارکت افراد مرتبط با محصول و نیازمندی تعریف و درباره آن توافق میشود؛ نقش دقیق هر فرد به ساختار و روش کاری تیم بستگی دارد.
در Scrum، Product Owner مسئول بیشینهکردن ارزش محصول و مدیریت مؤثر Product Backlog است، اما این موضوع به معنای انحصاریبودن نوشتن Acceptance Criteria توسط او نیست.
در یک تیم بالغ، Acceptance Criteria میتواند نتیجه یک گفتوگوی مشترک بین Product Owner، Business Analyst، Developer، Tester و سایر افراد مرتبط باشد.
یک اصل مهم
هدف اصلی این نیست که مشخص کنیم «چه کسی جمله Acceptance Criteria را نوشته است؟»
هدف این است که مشخص کنیم:
«آیا افراد مناسب درباره شرایط قابل پذیرش بودن این قابلیت، درک مشترک و قابل اتکایی دارند؟»
این نگاه باعث میشود Acceptance Criteria از یک متن ساده در کنار User Story، به ابزاری برای همراستاسازی تیم، کاهش ابهام و افزایش کیفیت محصول تبدیل شود.
در بخش بعدی به سراغ یکی از مهمترین موضوعات میرویم: یک Acceptance Criteria خوب چه ویژگیهایی دارد و از کجا بفهمیم معیارهای پذیرش ما واقعاً قابل استفاده و قابل تست هستند؟
ویژگیهای یک Acceptance Criteria خوب
نوشتن Acceptance Criteria صرفاً به معنی اضافهکردن چند جمله به یک User Story نیست. اگر معیارهای پذیرش مبهم، غیرقابل اندازهگیری یا بیش از حد وابسته به جزئیات فنی باشند، نمیتوانند نقش واقعی خود را در ایجاد درک مشترک و ارزیابی نتیجه ایفا کنند.
یک Acceptance Criteria خوب باید به اندازهای واضح و مشخص باشد که Product Owner، Developer و Tester بتوانند برداشت نسبتاً یکسانی از نتیجه مورد انتظار داشته باشند و در نهایت بتوان درباره برآوردهشدن آن تصمیم مشخصی گرفت.
۱. واضح و بدون ابهام باشد
یک معیار پذیرش باید به شکلی نوشته شود که افراد مختلف آن را به شکلهای کاملاً متفاوت تفسیر نکنند.
برای مثال:
❌ نامناسب:
سیستم باید سریع باشد.
عبارت «سریع» برای افراد مختلف میتواند معانی متفاوتی داشته باشد.
✅ بهتر:
نتیجه جستوجوی محصولات باید حداکثر تا ۲ ثانیه پس از ارسال درخواست نمایش داده شود.
در مثال دوم، معیار مشخصتر و قابل بررسی است و احتمال اختلاف برداشت کاهش پیدا میکند.
۲. قابل تست (Testable) باشد
یکی از مهمترین ویژگیهای Acceptance Criteria این است که بتوان بررسی کرد آیا معیار برآورده شده است یا خیر.
برای مثال:
❌
رابط کاربری باید کاربرپسند باشد.
«کاربرپسند بودن» بدون تعریف شرایط مشخص، بهسادگی قابل تست نیست.
اما اگر معیار به رفتار مشخصی اشاره کند، میتوان آن را بهتر ارزیابی کرد:
کاربر باید بتواند بدون نیاز به مشاهده راهنمای جداگانه، فرآیند ثبت سفارش را تکمیل کند.
حتی در این مثال نیز اگر امکان داشته باشد، بهتر است معیار به شرایط دقیقتر و قابل اندازهگیریتری تبدیل شود تا ارزیابی آن وابستگی کمتری به قضاوت شخصی داشته باشد.
۳. مشخص و دقیق باشد
معیار پذیرش نباید بیش از حد کلی باشد.
کاربر باید بتواند سفارش خود را مدیریت کند.
این جمله مشخص نمیکند «مدیریت» دقیقاً شامل چه عملیاتی است.
اما میتوان آن را به شرایط مشخصتری تقسیم کرد:
- کاربر بتواند سفارشهای خود را مشاهده کند.
- کاربر بتواند سفارش قابل لغو را لغو کند.
- کاربر بتواند وضعیت سفارش را مشاهده کند.
هرچه رفتار مورد انتظار مشخصتر باشد، احتمال اختلاف برداشت کمتر میشود.
۴. روی نتیجه و رفتار مورد انتظار تمرکز کند
Acceptance Criteria باید بیشتر روی What تمرکز کند تا How؛ یعنی مشخص کند سیستم چه رفتاری باید داشته باشد، نه اینکه Developer دقیقاً چگونه باید آن را پیادهسازی کند.
برای مثال:
❌
اطلاعات کاربر باید در جدول
Usersدیتابیس با استفاده از Stored Procedure ذخیره شود.
این جمله بیشتر یک تصمیم فنی یا Implementation Detail است.
✅
پس از ثبت موفق اطلاعات، اطلاعات حساب کاربری باید ذخیره شده و در ورود بعدی قابل استفاده باشد.
در این حالت، نتیجه مورد انتظار مشخص شده است، بدون اینکه روش پیادهسازی به Developer تحمیل شود.
۵. قابل دستیابی و واقعبینانه باشد
معیار پذیرش باید با نیاز کسبوکار، محدودیتهای محصول و شرایط واقعی سیستم سازگار باشد.
سیستم باید همیشه در کمتر از ۱۰۰ میلیثانیه پاسخ دهد.
ممکن است چنین معیاری برای برخی عملیات منطقی نباشد یا دستیابی به آن به زیرساخت، معماری یا منابعی نیاز داشته باشد که در Scope فعلی پروژه وجود ندارد.
بنابراین معیارهای پذیرش باید در کنار نیاز کسبوکار و محدودیتهای واقعی محصول بررسی شوند تا اهداف غیرواقعبینانه یا ناسازگار با شرایط پروژه تعریف نشوند.
۶. قابل بررسی و قابل تأیید باشد
معیار پذیرش باید به شکلی نوشته شود که در زمان ارزیابی بتوان درباره وضعیت آن تصمیم گرفت؛ یعنی مشخص باشد که معیار برآورده شده است یا خیر.
برای مثال:
کاربر باید بتواند رمز عبور خود را تغییر دهد.
این معیار قابل بررسی است، اما میتوان آن را دقیقتر کرد:
پس از واردکردن رمز عبور فعلی صحیح و یک رمز عبور جدید معتبر، کاربر باید بتواند رمز عبور خود را با موفقیت تغییر دهد.
در این حالت، شرایط لازم برای پذیرش قابلیت مشخصتر شده است و ارزیابی آن نیز سادهتر خواهد بود.
۷. شرایط مثبت و منفی را در نظر بگیرد
یکی از اشتباهات رایج این است که Acceptance Criteria فقط Happy Path را پوشش دهد.
کاربر با واردکردن اطلاعات صحیح باید با موفقیت وارد سیستم شود.
این معیار فقط رفتار موفق را مشخص میکند؛ در حالی که شرایطی مانند موارد زیر نیز ممکن است برای کسبوکار اهمیت داشته باشند:
- رمز عبور اشتباه
- ایمیل نامعتبر
- فیلدهای خالی
- حساب کاربری غیرفعال
- تعداد زیاد تلاش ناموفق
البته لازم نیست همه این موارد همیشه در یک معیار پذیرش نوشته شوند؛ هدف این است که شرایط مهم و مورد انتظار کسبوکار فراموش نشوند.
۸. برای افراد فنی و غیر فنی قابل فهم باشد
Acceptance Criteria معمولاً نقطه اتصال بین نیاز کسبوکار و پیادهسازی نرمافزار است.
بنابراین بهتر است با زبانی نوشته شود که Product Owner و Stakeholder بتوانند آن را درک کنند و در عین حال برای Developer و Tester نیز به اندازه کافی دقیق باشد.
استفاده بیش از حد از اصطلاحات فنی و جزئیات Implementation میتواند این ویژگی را تضعیف کند.
۹. مستقل از جزئیات غیرضروری باشد
معیار پذیرش نباید با اطلاعاتی که برای پذیرش Feature ضروری نیستند، بیش از حد پیچیده شود.
برای مثال، اگر هدف این است که کاربر بتواند سفارش خود را لغو کند، لازم نیست Acceptance Criteria درباره نام کلاس، نوع Database یا Framework مورد استفاده صحبت کند؛ مگر اینکه این جزئیات واقعاً بخشی از یک الزام مشخص باشند.
۱۰. با نیاز واقعی کسبوکار هماهنگ باشد
در نهایت Acceptance Criteria باید نشان دهد که Feature از دید Business و User چه زمانی ارزش مورد انتظار را ایجاد میکند.
ممکن است یک Feature از نظر فنی کاملاً درست پیادهسازی شده باشد، اما رفتار آن با نیاز واقعی کسبوکار مطابقت نداشته باشد.
بنابراین سؤال اصلی فقط این نیست که:
«آیا سیستم طبق چیزی که Developer پیادهسازی کرده کار میکند؟»
بلکه باید پرسید:
«آیا سیستم همان چیزی را ارائه میدهد که کاربر و کسبوکار انتظار دارند؟»
یک چکلیست ساده برای بررسی Acceptance Criteria
قبل از نهاییکردن معیارهای پذیرش، میتوان این پرسشها را مطرح کرد:
- آیا معیار واضح و بدون ابهام است؟
- آیا میتوان آن را تست کرد؟
- آیا نتیجه مورد انتظار را مشخص میکند؟
- آیا شرایط مهم مثبت و منفی در نظر گرفته شدهاند؟
- آیا به جزئیات غیرضروری پیادهسازی وابسته نیست؟
- آیا برای افراد فنی و غیر فنی قابل فهم است؟
- آیا با نیاز واقعی کاربر و کسبوکار مطابقت دارد؟
- آیا میتوان در پایان درباره برآوردهشدن یا نشدن آن تصمیم مشخصی گرفت؟
اگر پاسخ این پرسشها مثبت باشد، احتمالاً با یک Acceptance Criteria باکیفیت روبهرو هستیم.
در بخش بعدی، انواع رایج Acceptance Criteria را بررسی میکنیم و با دو رویکرد مهم یعنی Rule-Oriented و Scenario-Oriented (Given/When/Then) آشنا میشویم.
انواع Acceptance Criteria
Acceptance Criteria را میتوان به روشهای مختلفی نوشت. انتخاب روش مناسب به نوع نیازمندی، پیچیدگی Feature و شیوه کاری تیم بستگی دارد.
بهطور کلی، دو رویکرد رایج برای نوشتن معیارهای پذیرش عبارتاند از:
- Rule-Oriented Acceptance Criteria یا معیارهای مبتنی بر قانون
- Scenario-Oriented Acceptance Criteria یا معیارهای مبتنی بر سناریو
این دو رویکرد رقیب یکدیگر نیستند و هر دو میتوانند برای یک User Story مفید باشند. انتخاب بین آنها به ماهیت Requirement و نوع رفتاری که میخواهیم توصیف کنیم بستگی دارد.
۱. Rule-Oriented Acceptance Criteria
در این روش، معیارهای پذیرش بهصورت مجموعهای از قوانین، شرایط و نتایج مورد انتظار نوشته میشوند.
این روش زمانی مناسب است که بخواهیم قوانین کسبوکار یا شرایط مشخصی را بهصورت خلاصه بیان کنیم.
برای مثال، برای قابلیت ثبتنام کاربر میتوان معیارهای زیر را تعریف کرد:
- ایمیل باید فرمت معتبر داشته باشد.
- رمز عبور باید حداقل ۸ کاراکتر داشته باشد.
- ایمیل تکراری نباید امکان ثبتنام داشته باشد.
- پس از ثبتنام موفق، حساب کاربری باید ایجاد شود.
- در صورت وجود ایمیل تکراری، پیام مناسب به کاربر باید نمایش داده شود.
در این روش تمرکز روی قوانینی است که باید برقرار باشند، بدون اینکه الزاماً هر معیار در قالب یک سناریوی کامل نوشته شود.
مزایای Rule-Oriented Acceptance Criteria
- ساده و سریع برای نوشتن است.
- برای بیان قوانین کسبوکار مناسب است.
- خوانایی خوبی برای Stakeholderها دارد.
- برای User Storyهای ساده میتواند کاملاً کافی باشد.
محدودیت Rule-Oriented Acceptance Criteria
اگر یک Feature رفتارهای پیچیده و حالتهای مختلفی داشته باشد، یک فهرست ساده از قوانین ممکن است ارتباط بین شرایط، اقدامات و نتایج را به اندازه کافی نشان ندهد.
در چنین شرایطی میتوان از رویکرد Scenario-Oriented استفاده کرد.
۲. Scenario-Oriented Acceptance Criteria
در این روش، معیارهای پذیرش به شکل سناریو نوشته میشوند.
یکی از رایجترین قالبها برای این کار، ساختار Given / When / Then است.
این ساختار بهخصوص در BDD (Behavior-Driven Development) بسیار رایج است.
معنای این سه بخش به شکل ساده عبارت است از:
- Given → وضعیت یا شرایط اولیه چیست؟
- When → چه عملی انجام میشود؟
- Then → چه نتیجهای باید اتفاق بیفتد؟
مثال
فرض کنید User Story ما این باشد:
بهعنوان یک کاربر، میخواهم بتوانم با ایمیل و رمز عبور وارد سیستم شوم تا به حساب کاربری خود دسترسی داشته باشم.
یکی از معیارهای پذیرش را میتوان به شکل زیر نوشت:
Given: کاربر در صفحه ورود قرار دارد و حساب کاربری فعال دارد.
When: کاربر ایمیل و رمز عبور صحیح خود را وارد میکند و روی دکمه ورود کلیک میکند.
Then: کاربر باید با موفقیت وارد حساب کاربری خود شود.
برای حالت ناموفق نیز میتوان سناریوی دیگری تعریف کرد:
Given: کاربر در صفحه ورود قرار دارد.
When: کاربر رمز عبور اشتباه وارد میکند.
Then: سیستم باید پیام خطای مناسب نمایش دهد و کاربر نباید وارد حساب کاربری شود.
در این روش، شرایط اولیه، اقدام و نتیجه مورد انتظار به شکل واضح از یکدیگر جدا شدهاند و همین موضوع میتواند درک رفتار سیستم را سادهتر کند.
Rule-Oriented یا Scenario-Oriented؟
انتخاب بین این دو روش به شرایط پروژه، نوع Requirement و پیچیدگی رفتار مورد انتظار بستگی دارد.
| Rule-Oriented | Scenario-Oriented |
|---|---|
| مبتنی بر قوانین و شرایط | مبتنی بر سناریو |
| ساده و خلاصه | ساختاریافتهتر |
| مناسب برای قوانین کسبوکار | مناسب برای رفتارهای چندمرحلهای |
| برای نیازمندیهای ساده مناسب است | برای رفتارهای پیچیدهتر مفید است |
| الزاماً Given/When/Then ندارد | معمولاً از Given/When/Then استفاده میکند |
برای مثال، این معیار:
«رمز عبور باید حداقل ۸ کاراکتر داشته باشد.»
بهخوبی با Rule-Oriented قابل بیان است.
اما برای فرآیندی مانند ورود کاربر که شامل شرایط اولیه، اقدام و نتیجه است، استفاده از یک سناریو میتواند خوانایی بیشتری ایجاد کند.
آیا باید همیشه از Given/When/Then استفاده کنیم؟
خیر. یکی از اشتباهات رایج این است که تصور کنیم هر Acceptance Criteria حتماً باید با Given/When/Then نوشته شود.
این قالب زمانی ارزش بیشتری دارد که رفتار سیستم یا سناریوی موردنظر به چنین ساختاری نیاز داشته باشد.
برای یک قانون ساده مانند:
«حداقل مبلغ سفارش برای ارسال رایگان ۵۰۰ هزار تومان است.»
نوشتن یک جمله ساده ممکن است کاملاً کافی باشد.
اما برای یک رفتار چندمرحلهای، ساختار Given/When/Then میتواند شرایط و نتایج مورد انتظار را شفافتر کند.
بنابراین هدف اصلی Acceptance Criteria، شفافکردن شرایط پذیرش است؛ نه استفاده اجباری از یک قالب خاص.
ارتباط Acceptance Criteria با BDD
ساختار Given/When/Then ارتباط نزدیکی با Behavior-Driven Development (BDD) دارد.
در BDD، رفتار مورد انتظار سیستم به شکلی بیان میشود که افراد فنی و غیر فنی بتوانند آن را درک کنند و در بسیاری از ابزارها، همین سناریوها میتوانند به شکل قابل اجرا نیز مورد استفاده قرار گیرند.
با این حال، باید توجه داشت:
استفاده از Given/When/Then بهتنهایی به معنای اجرای BDD نیست.
این ساختار میتواند صرفاً یک روش مناسب برای بیان Acceptance Criteria نیز باشد.
در بخشهای بعدی مقاله، زمانی که به BDD برسیم، این ارتباط را دقیقتر بررسی خواهیم کرد.
یک نکته مهم درباره تعداد Acceptance Criteria
هیچ عدد ثابتی برای تعداد معیارهای پذیرش یک User Story وجود ندارد.
یک User Story ساده ممکن است فقط چند معیار داشته باشد، در حالی که یک Feature پیچیده ممکن است معیارهای بیشتری نیاز داشته باشد.
با این حال، اگر تعداد معیارها آنقدر زیاد شود که User Story عملاً به مجموعهای از Requirements پیچیده تبدیل شود، ممکن است نشانهای باشد که Story بیش از حد بزرگ است و بهتر است به چند User Story کوچکتر تقسیم شود.
در نتیجه، Acceptance Criteria باید به اندازهای باشد که شرایط پذیرش را شفاف کند، نه اینکه خود به یک سند پیچیده و غیرقابل مدیریت تبدیل شود.
در بخش بعدی به یکی از مهمترین ارتباطها میرسیم: Acceptance Criteria و User Story چه تفاوتی دارند و چگونه در کنار یکدیگر استفاده میشوند؟
Acceptance Criteria و User Story چه تفاوتی دارند؟
User Story و Acceptance Criteria (معیارهای پذیرش) معمولاً در کنار یکدیگر استفاده میشوند، اما نقش یکسانی ندارند.
User Story بیان میکند که کاربر چه نیازی دارد و چرا؛ در حالی که Acceptance Criteria مشخص میکند این نیاز تحت چه شرایطی برآوردهشده در نظر گرفته میشود.
User Story چیست؟
User Story روشی ساده برای بیان یک نیاز از دیدگاه کاربر یا استفادهکننده از محصول است.
یکی از قالبهای رایج آن چنین است:
بهعنوان [نوع کاربر]، میخواهم [هدف یا قابلیت] را داشته باشم تا [دلیل یا ارزش].
برای مثال:
بهعنوان یک مشتری، میخواهم بتوانم محصولی را به سبد خرید اضافه کنم تا بتوانم آن را در ادامه خریداری کنم.
این User Story اطلاعات مهمی درباره چه کسی، چه چیزی و چرا ارائه میدهد؛ اما معمولاً تمام شرایطی را که برای قابل قبول بودن قابلیت لازم است مشخص نمیکند.
Acceptance Criteria چه چیزی به User Story اضافه میکند؟
Acceptance Criteria جزئیات لازم برای مشخصکردن شرایط پذیرش را اضافه میکند.
برای مثال:
User Story:
بهعنوان یک مشتری، میخواهم بتوانم محصولی را به سبد خرید اضافه کنم تا بتوانم آن را خریداری کنم.
Acceptance Criteria:
- محصول موجود باید به سبد خرید اضافه شود.
- پس از افزودن محصول، تعداد اقلام سبد خرید باید بهروزرسانی شود.
- قیمت محصول باید در سبد خرید نمایش داده شود.
- محصول ناموجود نباید به سبد خرید اضافه شود.
- در صورت موفقیت عملیات، محصول باید در سبد خرید قابل مشاهده باشد.
در این مثال، User Story هدف کاربر را بیان میکند و Acceptance Criteria مشخص میکند چه شرایطی باید برقرار باشد تا بتوانیم بگوییم این هدف به شکل مورد انتظار پیادهسازی شده است.
تفاوت User Story و Acceptance Criteria
| User Story | Acceptance Criteria |
|---|---|
| نیاز کاربر را بیان میکند. | شرایط پذیرش نیاز را مشخص میکند. |
| بیشتر روی What و Why تمرکز دارد. | روی شرایط و رفتار مورد انتظار تمرکز دارد. |
| معمولاً کوتاه و سطح بالا است. | میتواند شامل چند شرط یا سناریو باشد. |
| هدف و ارزش Feature را مشخص میکند. | مشخص میکند Feature چه زمانی قابل قبول است. |
| از دید کاربر نوشته میشود. | میتواند جزئیات بیشتری از رفتار مورد انتظار ارائه دهد. |
| بهتنهایی ممکن است برای تست کافی نباشد. | میتواند ورودی مناسبی برای طراحی تست باشد. |
رابطه User Story و Acceptance Criteria چگونه است؟
میتوان رابطه این دو مفهوم را به شکل زیر تصور کرد:
User Story
⬇️
چه کسی چه چیزی میخواهد و چرا؟
⬇️
Acceptance Criteria
⬇️
برای اینکه بگوییم این نیاز برآورده شده، چه شرایطی باید برقرار باشد؟
بنابراین Acceptance Criteria جایگزین User Story نیست، بلکه آن را تکمیل و دقیقتر میکند.
آیا هر User Story باید Acceptance Criteria داشته باشد؟
اگر یک تیم از User Story برای مدیریت نیازمندیها استفاده میکند، داشتن معیارهای پذیرش مشخص برای آن معمولاً بسیار مفید است؛ بهخصوص زمانی که رفتار مورد انتظار Feature به توضیح بیشتری نیاز دارد.
البته میزان جزئیات میتواند متفاوت باشد. یک User Story بسیار ساده ممکن است معیارهای پذیرش کوتاه و محدودی داشته باشد، در حالی که یک Story پیچیده به چندین معیار یا سناریو نیاز داشته باشد.
نکته مهم این است که Acceptance Criteria نباید صرفاً برای تکمیل یک قالب یا Checklist نوشته شود؛ بلکه باید ابهام User Story را کاهش دهد و شرایط موفقیت آن را روشن کند.
Acceptance Criteria چه چیزی نیست؟
برای درک بهتر مفهوم، باید توجه کنیم که Acceptance Criteria:
- خود User Story نیست.
- Test Case نیست.
- الزاماً یک سند جداگانه نیست.
- الزاماً توسط Tester نوشته نمیشود.
- الزاماً با Given/When/Then نوشته نمیشود.
- با Acceptance Testing یکسان نیست.
- با User Acceptance Testing (UAT) یکسان نیست.
- Definition of Done نیست.
این تمایزها در ادامه مقاله اهمیت بیشتری پیدا میکنند؛ بهخصوص هنگام بررسی تفاوت Acceptance Criteria با Test Case و User Acceptance Testing (UAT).
یک مثال مقایسهای
فرض کنید قابلیت موردنظر، تغییر رمز عبور باشد.
User Story:
بهعنوان یک کاربر، میخواهم بتوانم رمز عبور خود را تغییر دهم تا امنیت حساب کاربری خود را حفظ کنم.
Acceptance Criteria:
- کاربر باید رمز عبور فعلی صحیح را وارد کند.
- رمز عبور جدید باید شرایط تعیینشده را داشته باشد.
- رمز عبور جدید و تکرار آن باید یکسان باشند.
- در صورت معتبر بودن اطلاعات، رمز عبور باید با موفقیت تغییر کند.
- در صورت نامعتبر بودن هر یک از اطلاعات، پیام خطای مناسب باید نمایش داده شود.
Test Case:
واردکردن رمز عبور فعلی صحیح، رمز عبور جدید معتبر و تکرار صحیح آن و بررسی موفقیتآمیز بودن تغییر رمز عبور.
در اینجا سه سطح مختلف را میبینیم:
User Story → نیاز و هدف
Acceptance Criteria → شرایط پذیرش
Test Case → روش مشخص بررسی یک حالت
این تفکیک مفهومی درک نقش Acceptance Criteria در فرایند تست نرمافزار را بسیار سادهتر میکند.
در بخش بعدی، همین رابطه را یک مرحله جلوتر میبریم و بررسی میکنیم که Acceptance Criteria چه تفاوتی با Test Case دارد و چگونه میتوان از معیارهای پذیرش برای طراحی تست استفاده کرد.
Acceptance Criteria و Test Case چه تفاوتی دارند؟
یکی از اشتباهات رایج در تیمهای نرمافزاری این است که Acceptance Criteria (معیارهای پذیرش) و Test Case را مفاهیمی یکسان در نظر بگیریم. این دو به یکدیگر مرتبط هستند، اما هدف و سطح جزئیات متفاوتی دارند.
به زبان ساده:
Acceptance Criteria مشخص میکند چه چیزی باید درست باشد؛ Test Case مشخص میکند چگونه آن را بررسی کنیم.
یک مثال ساده
فرض کنید User Story این باشد:
بهعنوان یک مشتری، میخواهم بتوانم محصولی را به سبد خرید اضافه کنم تا بتوانم آن را خریداری کنم.
یکی از Acceptance Criteria میتواند این باشد:
محصول موجود باید با انتخاب گزینه «افزودن به سبد خرید» به سبد خرید کاربر اضافه شود.
این معیار مشخص میکند چه رفتاری مورد انتظار است، اما هنوز یک Test Case کامل نیست.
Tester میتواند بر اساس آن Test Case زیر را طراحی کند:
Test Case: افزودن محصول موجود به سبد خرید
Precondition: کاربر وارد حساب کاربری خود شده و یک محصول موجود در فروشگاه وجود دارد.
Test Steps:
- وارد صفحه محصول شوید.
- گزینه «افزودن به سبد خرید» را انتخاب کنید.
- سبد خرید را باز کنید.
Expected Result:
محصول انتخابشده باید در سبد خرید نمایش داده شود و تعداد اقلام سبد خرید باید بهدرستی بهروزرسانی شود.
در اینجا مشخص است که Acceptance Criteria و Test Case دو نقش متفاوت دارند.
Acceptance Criteria چه چیزی را مشخص میکند؟
معیار پذیرش روی شرایط و نتیجه مورد انتظار تمرکز دارد.
در صورت واردکردن اطلاعات معتبر، کاربر باید بتواند با موفقیت وارد حساب کاربری خود شود.
این معیار به ما میگوید سیستم چه رفتاری باید داشته باشد تا شرط پذیرش برآورده شود.
اما هنوز مشخص نکرده است که Tester دقیقاً:
- با چه دادهای تست کند.
- از چه مراحلی استفاده کند.
- چه Preconditionهایی لازم است.
- چه حالتهای مختلفی را بررسی کند.
- چه شرایط منفی یا مرزی را پوشش دهد.
این جزئیات میتوانند در Test Caseها مشخص شوند.
Test Case چه چیزی را مشخص میکند؟
تست کیس (Test Case) یک روش ساختاریافته برای بررسی یک رفتار، شرط یا سناریوی مشخص است.
یک Test Case میتواند شامل مواردی مانند موارد زیر باشد:
- Test Case ID
- عنوان
- Preconditions
- Test Data
- Test Steps
- Expected Result
- Postconditions
بنابراین Test Case معمولاً نسبت به Acceptance Criteria جزئیات اجرایی بیشتری دارد.
تفاوت اصلی در یک نگاه
| Acceptance Criteria | Test Case |
|---|---|
| شرایط پذیرش را مشخص میکند. | نحوه بررسی یک شرط یا رفتار را مشخص میکند. |
| بیشتر روی What تمرکز دارد. | بیشتر روی How تمرکز دارد. |
| بخشی از تعریف و شفافسازی نیاز است. | یک Artifact تست است. |
| معمولاً سطح بالاتری دارد. | معمولاً جزئیات اجرایی بیشتری دارد. |
| برای ایجاد توافق درباره رفتار مورد انتظار استفاده میشود. | برای اجرا و ثبت یک فعالیت تست استفاده میشود. |
| میتواند مبنای طراحی Test Case باشد. | میتواند برای بررسی برآوردهشدن Acceptance Criteria استفاده شود. |
آیا هر Acceptance Criterion یک Test Case است؟
خیر. این یکی از نکات مهمی است که باید درک شود.
یک Acceptance Criterion ممکن است به یک یا چند Test Scenario و Test Case منجر شود.
برای مثال، معیار زیر را در نظر بگیرید:
کاربر باید بتواند با واردکردن ایمیل و رمز عبور معتبر وارد سیستم شود.
برای بررسی این قابلیت، Tester ممکن است در کنار حالت اصلی، شرایط مختلفی را نیز بر اساس ریسک و نیازمندیها بررسی کند؛ برای مثال:
- ورود با اطلاعات معتبر
- ورود با ایمیل نامعتبر
- ورود با رمز عبور اشتباه
- ورود با ایمیل خالی
- ورود با رمز عبور خالی
- ورود با هر دو فیلد خالی
در نتیجه، یک معیار پذیرش میتواند مبنای طراحی چندین تست قرار بگیرد.
آیا Acceptance Criteria باید تمام Test Caseها را مشخص کند؟
خیر.
Acceptance Criteria قرار نیست جایگزین Test Case شود یا تمام جزئیات تست را در خود جای دهد.
برای مثال، ممکن است Acceptance Criteria فقط بگوید:
«در صورت واردکردن اطلاعات نامعتبر، پیام خطای مناسب باید نمایش داده شود.»
اما Tester باید بر اساس ریسک، تجربه، تکنیکهای تست، Requirementها و سایر اطلاعات موجود تصمیم بگیرد چه حالتهایی باید برای بررسی این معیار تست شوند.
بنابراین Acceptance Criteria میتواند یکی از ورودیهای مهم طراحی تست باشد، اما تنها منبع طراحی Test Case نیست.
ارتباط Acceptance Criteria، Test Scenario و Test Case
میتوان این رابطه را به شکل ساده زیر در نظر گرفت:
User Story
↓
Acceptance Criteria
↓
Test Scenario
↓
Test Case
البته این یک مدل سادهشده است و در پروژههای واقعی همیشه چنین زنجیره خطی و مستقیمی وجود ندارد.
برای مثال:
Acceptance Criteria:
اگر کاربر اطلاعات ورود نامعتبر وارد کند، سیستم باید پیام خطای مناسب نمایش دهد.
Test Scenario:
بررسی رفتار سیستم هنگام ورود با اطلاعات نامعتبر.
Test Caseها:
- ورود با رمز عبور اشتباه
- ورود با ایمیل نامعتبر
- ورود با ایمیل خالی
- ورود با رمز عبور خالی
- ورود با هر دو فیلد خالی
این تفکیک کمک میکند متوجه شویم Acceptance Criteria قرار نیست فهرست Test Caseها باشد.
نقش Tester در تبدیل Acceptance Criteria به تست
Tester نباید Acceptance Criteria را فقط بهعنوان «دستور تست» در نظر بگیرد.
ابتدا باید بررسی کند که آیا معیارها:
- واضح هستند؟
- قابل تست هستند؟
- شرایط مهم را پوشش میدهند؟
- حالتهای منفی و مرزی موردنیاز را در نظر گرفتهاند؟
- با نیاز واقعی کسبوکار مطابقت دارند؟
سپس بر اساس آنها و سایر اطلاعات موجود، Test Scenario و Test Caseهای مناسب طراحی میشوند.
این موضوع نشان میدهد که Acceptance Criteria هم در فعالیتهای Requirements و هم در فعالیتهای Testing نقش دارد.
یک اشتباه رایج
گاهی Tester یا تیم توسعه، Acceptance Criteria را به شکل زیر مینویسد:
- روی دکمه Login کلیک کن.
- ایمیل را وارد کن.
- رمز عبور را وارد کن.
- روی Submit کلیک کن.
- Dashboard را بررسی کن.
این موارد بیشتر شبیه Test Steps هستند تا Acceptance Criteria.
Acceptance Criteria باید مشخص کند چه شرایط و نتیجهای برای پذیرش Feature لازم است، نه اینکه لزوماً Tester را مرحلهبهمرحله راهنمایی کند که چگونه تست را اجرا کند.
در بخش بعدی به سراغ مفهوم Acceptance Testing میرویم؛ سپس در بخش مهم بعد از آن، تفاوت Acceptance Criteria، Acceptance Testing و User Acceptance Testing (UAT) را در کنار یکدیگر بررسی خواهیم کرد.
Acceptance Criteria و Acceptance Testing چه ارتباطی دارند؟
تا اینجا دیدیم که Acceptance Criteria (معیارهای پذیرش) شرایطی را مشخص میکند که یک User Story یا Feature برای قابل قبول بودن باید برآورده کند و Test Case میتواند برای بررسی این شرایط طراحی شود.
اما یک مفهوم مرتبط دیگر نیز وجود دارد:
Acceptance Testing
این دو اصطلاح به یکدیگر ارتباط نزدیکی دارند، اما یکسان نیستند.
به زبان ساده:
Acceptance Criteria مشخص میکند چه شرایطی باید برآورده شود؛ Acceptance Testing بررسی میکند که آیا سیستم یا محصول این شرایط و نیازمندیهای مورد انتظار را برآورده کرده است یا خیر.
Acceptance Testing چیست؟
Acceptance Testing نوعی تست است که با هدف ارزیابی اینکه آیا یک سیستم، Feature یا محصول نیازمندیها و شرایط مورد انتظار برای پذیرش را برآورده میکند یا خیر، انجام میشود.
تمرکز این تست بیشتر روی این سؤال است:
آیا محصولی که ساختهایم، نیاز و هدف مورد انتظار را به اندازه کافی برآورده میکند و میتوان آن را قابل قبول دانست؟
بنابراین Acceptance Testing بیشتر روی رفتار و نتیجه قابل مشاهده سیستم و میزان انطباق آن با نیازمندیهای مورد انتظار تمرکز دارد، نه صرفاً جزئیات داخلی پیادهسازی.
رابطه Acceptance Criteria و Acceptance Testing
یکی از سادهترین روشها برای درک رابطه این دو مفهوم، در نظر گرفتن یک مسیر کلی است:
Requirement / User Story
↓
Acceptance Criteria
↓
Acceptance Testing
ابتدا شرایط و نتیجه مورد انتظار را مشخص میکنیم و سپس با استفاده از تست و ارزیابی، بررسی میکنیم که آیا سیستم واقعاً آن نیاز و شرایط را برآورده کرده است یا خیر.
مثال
فرض کنید User Story مربوط به ورود کاربر باشد:
بهعنوان یک کاربر، میخواهم با ایمیل و رمز عبور وارد سیستم شوم تا به حساب کاربری خود دسترسی داشته باشم.
یکی از معیارهای پذیرش میتواند این باشد:
اگر کاربر اطلاعات ورود معتبر وارد کند، باید با موفقیت وارد حساب کاربری شود.
حالا در Acceptance Testing میتوان این رفتار را بررسی کرد.
شرایط اولیه: یک حساب کاربری فعال با اطلاعات معتبر وجود دارد.
اقدام: کاربر ایمیل و رمز عبور صحیح را وارد میکند و گزینه ورود را انتخاب میکند.
نتیجه مورد انتظار: کاربر باید با موفقیت وارد حساب کاربری شود.
در این مثال:
- Acceptance Criteria → شرط و نتیجه مورد انتظار برای پذیرش را تعریف میکند.
- Acceptance Testing → بررسی میکند که آیا سیستم در عمل آن شرط و نتیجه مورد انتظار را برآورده کرده است یا خیر.
Acceptance Testing فقط بر اساس Acceptance Criteria انجام میشود؟
لزومی ندارد.
Acceptance Criteria یکی از منابع مهم برای طراحی و اجرای Acceptance Testing است، اما ارزیابی پذیرش یک Feature یا محصول میتواند بر اساس سایر اطلاعات مرتبط با نیازمندی و کسبوکار نیز انجام شود.
برای مثال ممکن است موارد زیر نیز در ارزیابی یک قابلیت اهمیت داشته باشند:
- Business Requirements
- Functional Requirements
- قوانین کسبوکار
- قراردادها و توافقهای موجود با مشتری
- نیازهای Stakeholderها
- شرایط استفاده واقعی از سیستم
بنابراین نباید Acceptance Testing را صرفاً اجرای مستقیم Acceptance Criteria در نظر گرفت. معیارهای پذیرش میتوانند یکی از مهمترین مبناهای ارزیابی باشند، اما دامنه Acceptance Testing ممکن است گستردهتر از آنها باشد.
چه کسی Acceptance Testing را انجام میدهد؟
این موضوع به نوع پروژه، محصول و نوع Acceptance Testing بستگی دارد.
بسته به شرایط، افراد مختلفی ممکن است در Acceptance Testing مشارکت داشته باشند، از جمله:
- Tester یا QA
- Product Owner
- Business Analyst
- نماینده مشتری
- End User
- سایر Stakeholderهای مرتبط
بنابراین Acceptance Testing یک عنوان کلی برای فعالیتهای ارزیابی پذیرش است و الزاماً به معنای تستی نیست که فقط توسط کاربر نهایی انجام شود.
این نکته ما را به یکی از مهمترین تفاوتهای این مقاله میرساند:
Acceptance Testing با User Acceptance Testing (UAT) یکسان نیست.
یک تفاوت مفهومی مهم
برای جلوگیری از اشتباه، فعلاً میتوان این سه مفهوم را به شکل زیر در ذهن نگه داشت:
| مفهوم | سؤال اصلی |
|---|---|
| Acceptance Criteria | چه شرایط و نتایجی باید برای پذیرش یک قابلیت یا نیازمندی برقرار باشند؟ |
| Acceptance Testing | آیا سیستم یا محصول نیازمندیها و شرایط مورد انتظار برای پذیرش را برآورده کرده است؟ |
| UAT | آیا محصول از دید کاربر، مشتری یا کسبوکار برای استفاده واقعی قابل قبول است؟ |
البته این جدول یک خلاصه مفهومی است و در پروژههای مختلف ممکن است مرز و نحوه اجرای این فعالیتها متفاوت باشد.
در بخش بعدی این سه مفهوم را دقیقتر از یکدیگر جدا میکنیم و بهطور ویژه بررسی خواهیم کرد که Acceptance Criteria چه تفاوتی با User Acceptance Testing (UAT) دارد؛ تفاوتی که یکی از رایجترین ابهامها در این حوزه است.
تفاوت Acceptance Criteria و User Acceptance Testing (UAT)
یکی از رایجترین اشتباهات در پروژههای نرمافزاری، یکی دانستن Acceptance Criteria (معیارهای پذیرش) با تست پذیرش کاربرUser Acceptance Testing (UAT) است.
این دو مفهوم به یکدیگر مرتبط هستند، اما از نظر ماهیت و کاربرد یکسان نیستند.
به سادهترین شکل:
Acceptance Criteria مشخص میکند چه شرایطی باید برآورده شود؛ UAT فرایندی برای بررسی این است که آیا محصول از دید کاربر، مشتری یا کسبوکار نیاز مورد انتظار را برآورده میکند یا خیر.
Acceptance Criteria چیست؟
Acceptance Criteria مجموعهای از شرایط مشخص برای یک User Story، Feature یا قابلیت است که بیان میکند چه چیزی باید برقرار باشد تا آن قابلیت، مطابق انتظار تعریفشده، قابل قبول در نظر گرفته شود.
برای مثال:
«پس از واردکردن اطلاعات معتبر، کاربر باید بتواند با موفقیت وارد حساب کاربری خود شود.»
این یک معیار پذیرش است.
در اینجا هنوز درباره اینکه چه کسی تست را انجام میدهد یا تست دقیقاً چگونه اجرا میشود صحبت نمیکنیم؛ فقط شرط و نتیجه مورد انتظار برای پذیرش قابلیت را مشخص کردهایم.
User Acceptance Testing چیست؟
User Acceptance Testing (UAT) نوعی Acceptance Testing است که در آن محصول یا قابلیت از منظر کاربر، مشتری یا نماینده کسبوکار بررسی میشود تا مشخص شود آیا سیستم برای نیاز واقعی و استفاده مورد انتظار قابل قبول است یا خیر.
در UAT معمولاً تمرکز روی این سؤال است:
«آیا این سیستم همان چیزی است که کسبوکار و کاربران برای استفاده واقعی نیاز دارند؟»
برای مثال، در یک سیستم فروش آنلاین، ممکن است یک نماینده کسبوکار یا کاربر موردنظر، یک فرایند واقعی خرید را بررسی کند:
- ورود به حساب کاربری
- جستوجوی محصول
- افزودن محصول به سبد خرید
- اعمال تخفیف
- ثبت سفارش
- پرداخت
- دریافت تأییدیه سفارش
هدف این نیست که صرفاً تکتک جزئیات فنی سیستم بررسی شوند؛ بلکه باید مشخص شود فرایند کسبوکار موردنظر از دید کاربر یا کسبوکار به شکل قابل قبول انجام میشود.
تفاوت Acceptance Criteria و UAT در یک نگاه
| Acceptance Criteria | User Acceptance Testing (UAT) |
|---|---|
| مجموعهای از شرایط پذیرش است. | یک فعالیت یا فرایند تست و ارزیابی است. |
| مشخص میکند چه چیزی باید برقرار باشد. | بررسی میکند آیا محصول نیاز مورد انتظار را برآورده میکند یا خیر. |
| معمولاً در سطح User Story یا Feature تعریف میشود. | میتواند یک Feature یا یک فرایند کسبوکار را در سطح گستردهتر ارزیابی کند. |
| میتواند توسط افراد مختلف مرتبط با نیازمندی تعریف و بازبینی شود. | معمولاً با مشارکت کاربر، مشتری یا نماینده کسبوکار انجام یا تأیید میشود. |
| میتواند ورودی طراحی تست باشد. | از نیازمندیها و سایر اطلاعات کسبوکار برای طراحی سناریوهای ارزیابی استفاده میکند. |
| خودش تست نیست. | یک نوع فعالیت تست و ارزیابی پذیرش است. |
یک مثال کامل
فرض کنید یک سیستم بانکی قابلیت انتقال وجه را ارائه میکند.
User Story
بهعنوان مشتری بانک، میخواهم بتوانم مبلغی را به حساب دیگری منتقل کنم تا بتوانم پرداختهای خود را انجام دهم.
Acceptance Criteria
برای این User Story میتوان معیارهای زیر را تعریف کرد:
- کاربر باید بتواند حساب مقصد را وارد کند.
- مبلغ انتقال باید بیشتر از حداقل مبلغ مجاز باشد.
- اگر موجودی حساب کافی نباشد، انتقال نباید انجام شود.
- پس از انتقال موفق، شماره پیگیری باید به کاربر نمایش داده شود.
- مبلغ انتقال باید از موجودی حساب مبدأ کسر شود.
اینها معیارهای پذیرش هستند؛ یعنی شرایطی که برای قابل قبول بودن قابلیت مشخص شدهاند.
Acceptance Testing
در Acceptance Testing، تیم میتواند بررسی کند که آیا شرایط و نیازمندیهای مورد انتظار واقعاً در سیستم برآورده شدهاند یا خیر.
- انتقال با مبلغ مجاز
- انتقال با مبلغ کمتر از حد مجاز
- انتقال با موجودی ناکافی
- بررسی نمایش شماره پیگیری
- بررسی کاهش موجودی حساب
این بخش Acceptance Testing است.
UAT
در UAT ممکن است نماینده کسبوکار یا کاربر موردنظر یک سناریوی واقعی انتقال وجه را اجرا کند و بررسی کند که آیا فرایند انتقال وجه از دید کسبوکار و کاربر قابل قبول است.
ممکن است در این مرحله سؤالاتی مانند این مطرح شوند:
- آیا فرایند انتقال مطابق فرایند کسبوکار است؟
- آیا اطلاعات موردنیاز کاربر به شکل مناسب نمایش داده میشود؟
- آیا رسید و اطلاعات تراکنش برای کاربر کافی است؟
- آیا فرایند برای استفاده واقعی قابل قبول است؟
بنابراین در این مثال:
- Acceptance Criteria → شرایطی را تعریف میکند که Feature باید برآورده کند.
- Acceptance Testing → بررسی میکند که سیستم این شرایط و نیازمندیهای مرتبط را برآورده کرده است.
- UAT → از منظر کاربر یا کسبوکار بررسی میکند که محصول برای استفاده واقعی قابل قبول است.
آیا UAT فقط Acceptance Criteria را تست میکند؟
خیر. این یکی از نکات مهم در درک تفاوت این دو مفهوم است.
ممکن است Acceptance Criteria یک User Story بهطور کامل برآورده شده باشد، اما در UAT مشخص شود که Feature هنوز از دید کسبوکار یا کاربر قابل قبول نیست.
برای مثال، فرض کنید تمام معیارهای پذیرش یک قابلیت پرداخت رعایت شدهاند، اما کاربران هنگام انجام فرایند پرداخت با یک جریان پیچیده و غیرقابل فهم مواجه میشوند.
در چنین شرایطی ممکن است قابلیت از نظر معیارهای پذیرش تعریفشده موفق باشد، اما Stakeholderهای کسبوکار تصمیم بگیرند که Feature هنوز برای استفاده واقعی مناسب نیست.
این مثال نشان میدهد:
پاسشدن Acceptance Criteria لزوماً به معنای موفقیت کامل UAT نیست.
البته در پروژههای مختلف ممکن است Acceptance Criteria مستقیماً بخشی از معیارهای UAT نیز باشند؛ بنابراین رابطه این مفاهیم به فرایند سازمان، نوع محصول و نحوه تعریف پذیرش در پروژه بستگی دارد.
آیا UAT را Tester انجام میدهد؟
الزاماً نه.
Tester میتواند در برنامهریزی، آمادهسازی دادهها، طراحی سناریوها، اجرای بخشی از تستها و پشتیبانی از فرایند UAT نقش داشته باشد؛ اما هدف UAT، ارزیابی محصول از منظر کاربر، مشتری یا کسبوکار است.
به همین دلیل در بسیاری از پروژهها، کاربران نهایی، مشتری یا نمایندگان کسبوکار در اجرای یا تأیید UAT مشارکت دارند.
البته نقش دقیق Tester و سایر افراد در UAT به ساختار سازمان و فرایند پروژه بستگی دارد.
یک اشتباه مهم: Acceptance Criteria = UAT Criteria
این دو عبارت نیز نباید بهصورت خودکار یکسان در نظر گرفته شوند.
Acceptance Criteria معمولاً در سطح یک User Story یا Feature تعریف میشود و شرایط مشخصی را برای پذیرش آن قابلیت بیان میکند.
در مقابل، UAT میتواند در سطح یک قابلیت بزرگتر، یک فرایند کسبوکار یا حتی یک Release انجام شود و هدف آن ارزیابی آمادگی محصول برای استفاده واقعی باشد.
بنابراین ممکن است چند User Story، هرکدام Acceptance Criteria مخصوص خود را داشته باشند، اما در نهایت یک UAT Scenario کل فرایند کسبوکار را از ابتدا تا انتها بررسی کند.
خلاصه تفاوت
اگر بخواهیم این تفاوت را در سه جمله به خاطر بسپاریم:
Acceptance Criteria: چه شرایط و نتایجی باید برای پذیرش یک قابلیت برقرار باشند؟
Acceptance Testing: آیا سیستم این شرایط و نیازمندیهای مورد انتظار را برآورده کرده است؟
UAT: آیا محصول از دید کاربر یا کسبوکار برای استفاده واقعی قابل قبول است؟
این سه مفهوم به یکدیگر مرتبطاند، اما جایگزین یکدیگر نیستند. درک همین تفاوت، بسیاری از ابهامهای رایج درباره «پذیرش» در پروژههای نرمافزاری را برطرف میکند.
در بخش بعدی، سراغ مفهوم دیگری میرویم که معمولاً در کنار Acceptance Criteria قرار میگیرد اما هدف متفاوتی دارد: Definition of Done (DoD).
تفاوت Acceptance Criteria و Definition of Done
یکی دیگر از مفاهیمی که گاهی با Acceptance Criteria (معیارهای پذیرش) اشتباه گرفته میشود، Definition of Done (DoD) است.
هر دو مفهوم میتوانند در تعیین وضعیت نهایی یک User Story یا Product Backlog Item نقش داشته باشند، اما هدف و سطح استفاده از آنها متفاوت است.
به زبان ساده:
Acceptance Criteria مشخص میکند یک User Story یا Feature چه شرایطی را باید برآورده کند؛ Definition of Done مشخص میکند یک آیتم برای اینکه در تیم «Done» در نظر گرفته شود، باید چه شرایط عمومی و توافقشدهای را داشته باشد.
Definition of Done چیست؟
Definition of Done (DoD) مجموعهای از شرایط و الزامات توافقشده است که مشخص میکند چه زمانی یک Product Backlog Item یا Increment با کیفیت مورد انتظار تکمیل شده و میتوان آن را Done در نظر گرفت.
برای مثال، یک تیم ممکن است در Definition of Done خود شرایطی مانند موارد زیر داشته باشد:
- توسعه Feature تکمیل شده باشد.
- Code Review انجام شده باشد.
- تستهای موردنیاز اجرا شده باشند.
- تمام Acceptance Criteria برآورده شده باشند.
- باگهای با اولویت بالا برطرف شده باشند.
- مستندات موردنیاز بهروزرسانی شده باشند.
- سایر الزامات کیفی و فرایندی تعریفشده توسط تیم رعایت شده باشند.
نکته مهم این است که Definition of Done معمولاً یک معیار عمومی و مشترک برای آیتمهایی است که در یک تیم یا محصول توسعه داده میشوند، نه مجموعهای از شرایط اختصاصی برای یک Feature خاص.
Acceptance Criteria چه تفاوتی دارد؟
Acceptance Criteria معمولاً به یک User Story، Feature یا نیازمندی مشخص مربوط میشود و شرایطی را بیان میکند که همان قابلیت باید برای قابل قبول بودن برآورده کند.
برای مثال، فرض کنید User Story مربوط به تغییر رمز عبور باشد:
Acceptance Criteria:
- کاربر باید رمز عبور فعلی صحیح را وارد کند.
- رمز عبور جدید باید حداقل ۸ کاراکتر داشته باشد.
- رمز عبور جدید و تکرار آن باید یکسان باشند.
- پس از تغییر موفق، پیام تأیید به کاربر نمایش داده شود.
این معیارها مشخصاً به رفتار مورد انتظار قابلیت تغییر رمز عبور مربوط هستند.
در مقابل، Definition of Done ممکن است برای User Storyهای مختلف تیم یکسان باشد:
Definition of Done:
- Acceptance Criteria برآورده شده باشند.
- Code Review انجام شده باشد.
- تستهای مرتبط با موفقیت انجام شده باشند.
- Regression Testing موردنیاز انجام شده باشد.
- مستندات مربوط به تغییرات بهروزرسانی شده باشند.
بنابراین یکی از تفاوتهای اصلی را میتوان اینگونه خلاصه کرد:
- Acceptance Criteria: شرایط پذیرش یک Feature یا User Story مشخص.
- Definition of Done: شرایط عمومی و توافقشده برای Done در نظر گرفتن یک آیتم.
تفاوت در یک نگاه
| Acceptance Criteria | Definition of Done |
|---|---|
| معمولاً مربوط به یک User Story یا Feature مشخص است. | معمولاً در سطح تیم، محصول یا مجموعهای از آیتمها تعریف میشود. |
| شرایط و رفتار مورد انتظار Feature را مشخص میکند. | شرایط عمومی لازم برای Done بودن آیتم را مشخص میکند. |
| بیشتر روی نیاز، رفتار و نتیجه مورد انتظار تمرکز دارد. | علاوه بر نتیجه، میتواند الزامات کیفیت و فرایند تکمیل کار را نیز پوشش دهد. |
| میتواند برای هر User Story متفاوت باشد. | معمولاً برای آیتمهای مشمول Definition of Done یکسان است. |
| میتواند مبنایی برای طراحی و اجرای تست باشد. | مشخص میکند چه زمانی تیم میتواند آیتم را Done اعلام کند. |
رابطه Acceptance Criteria و Definition of Done
این دو مفهوم رقیب یکدیگر نیستند و معمولاً میتوانند در کنار هم استفاده شوند.
برای مثال:
User Story: کاربر باید بتواند رمز عبور خود را تغییر دهد.
⬇️
Acceptance Criteria: رمز عبور جدید باید شرایط تعیینشده را داشته باشد و پس از تغییر موفق، پیام تأیید نمایش داده شود.
⬇️
Definition of Done: Acceptance Criteria برآورده شده باشد، تستهای لازم اجرا شده باشند، Code Review انجام شده باشد و سایر شرایط عمومی تیم نیز رعایت شده باشند.
در نتیجه، ممکن است یک User Story تمام Acceptance Criteria خود را برآورده کرده باشد، اما هنوز Done نباشد.
برای مثال، فرض کنید قابلیت بهدرستی کار میکند و تمام معیارهای پذیرش آن Pass شدهاند، اما Code Review انجام نشده یا یکی از الزامات اجباری Definition of Done تکمیل نشده است. در این حالت، ممکن است Acceptance Criteria برآورده شده باشند، اما Story هنوز طبق Definition of Done قابل اعلام بهعنوان Done نباشد.
آیا Acceptance Criteria بخشی از Definition of Done است؟
ممکن است باشد.
برای مثال، یک تیم میتواند در Definition of Done خود صراحتاً مشخص کند:
«تمام Acceptance Criteria باید برآورده شده باشند.»
در این حالت، برآوردهشدن Acceptance Criteria یکی از شرایط لازم برای Done شدن User Story خواهد بود.
اما این موضوع باعث نمیشود این دو مفهوم یکی شوند.
Acceptance Criteria میپرسد:
«این Feature خاص چه شرایطی باید داشته باشد؟»
Definition of Done میپرسد:
«برای اینکه این آیتم را Done اعلام کنیم، چه شرایط عمومی باید برقرار باشد؟»
یک تشبیه ساده
فرض کنید یک خودرو قرار است برای تحویل به مشتری آماده شود.
Acceptance Criteria میتواند مشخص کند:
- خودرو باید روشن شود.
- سیستم ترمز باید درست کار کند.
- چراغها باید فعال باشند.
- سیستم تهویه باید کار کند.
اما Definition of Done میتواند شامل شرایط عمومی دیگری باشد:
- تمام تستهای کنترل کیفیت انجام شده باشد.
- بازرسی نهایی انجام شده باشد.
- مدارک موردنیاز آماده باشد.
- خودرو برای تحویل آماده شده باشد.
- تمام مراحل داخلی فرایند تحویل تکمیل شده باشد.
بنابراین ممکن است خودرو از نظر شرایط عملکردی قابل قبول باشد، اما هنوز تمام مراحل لازم برای تحویل نهایی تکمیل نشده باشد.
از دید Tester
این تفاوت برای Tester اهمیت زیادی دارد. Tester باید بتواند Acceptance Criteria مربوط به یک Feature را بررسی کند، اما در عین حال بداند که برآوردهشدن Acceptance Criteria لزوماً به معنای Done بودن User Story نیست.
ممکن است تمام معیارهای پذیرش Pass شده باشند، اما هنوز فعالیتهایی مانند Regression Testing، بررسیهای غیرعملکردی، مستندسازی یا سایر الزامات Definition of Done باقی مانده باشند.
بنابراین میتوان این تفاوت را در یک جمله خلاصه کرد:
Acceptance Criteria بیشتر پاسخ میدهد «آیا Feature مطابق انتظار کار میکند؟»؛ Definition of Done پاسخ میدهد «آیا تمام شرایط لازم برای اعلام این کار بهعنوان Done رعایت شده است؟»
در بخش بعدی، بررسی میکنیم Acceptance Criteria در Agile و Scrum چه جایگاهی دارد و چگونه در فرآیندهایی مانند Product Backlog، Backlog Refinement و Sprint مورد استفاده قرار میگیرد.
Acceptance Criteria در Agile و Scrum
Acceptance Criteria (معیارهای پذیرش) ارتباط نزدیکی با روشهای توسعه Agile و بهخصوص شیوههای مدیریت و شفافسازی نیازمندیها دارد.
در تیمهای Agile، هدف این نیست که تمام جزئیات محصول از ابتدا برای مدت طولانی مشخص و ثابت شوند. نیازمندیها میتوانند در طول توسعه تکامل پیدا کنند و تیم نیز باید بتواند بر اساس بازخورد، تغییرات کسبوکار و اطلاعات جدید، آنها را بازبینی و اصلاح کند.
Acceptance Criteria در این فرایند کمک میکند مشخص شود هر User Story یا قابلیت چه شرایطی را باید برآورده کند تا بتوان آن را مطابق انتظار قابل قبول دانست.
Acceptance Criteria در Product Backlog
در Scrum، نیازمندیهای محصول در Product Backlog مدیریت میشوند و هر Product Backlog Item (PBI) میتواند اطلاعات مختلفی برای شفافسازی آن نیاز داشته باشد.
در تیمهایی که از Acceptance Criteria استفاده میکنند، این معیارها میتوانند در کنار اطلاعاتی مانند موارد زیر قرار بگیرند:
- شرح نیاز یا قابلیت
- هدف و ارزش مورد انتظار
- Acceptance Criteria
- اطلاعات تکمیلی
- وابستگیها و محدودیتهای مرتبط
برای مثال:
User Story:
بهعنوان یک مشتری، میخواهم بتوانم سفارش خود را لغو کنم تا در صورت تغییر تصمیم، بتوانم خرید خود را متوقف کنم.
Acceptance Criteria:
- سفارش فقط تا قبل از ارسال قابل لغو باشد.
- کاربر باید بتواند گزینه لغو سفارش را در شرایط مجاز مشاهده کند.
- پس از لغو موفق، وضعیت سفارش به «لغوشده» تغییر کند.
- در صورت پرداخت قبلی، فرایند بازپرداخت مطابق قوانین کسبوکار انجام شود.
در این حالت Acceptance Criteria کمک میکند اعضای تیم دقیقتر بدانند این Product Backlog Item چه رفتار و شرایطی باید داشته باشد.
Acceptance Criteria در Backlog Refinement
یکی از زمانهای مناسب برای بررسی و تکمیل معیارهای پذیرش، جلسات Backlog Refinement است.
در این گفتگوها تیم درباره Product Backlog Itemهای آینده صحبت میکند و میتواند مواردی مانند این را بررسی کند:
- آیا User Story واضح است؟
- آیا هدف و ارزش آن مشخص است؟
- آیا Acceptance Criteria کامل و قابل فهم است؟
- آیا شرایط خاص و Edge Caseهای مهم در نظر گرفته شدهاند؟
- آیا Story از نظر فنی قابل اجراست؟
- آیا اندازه و پیچیدگی Story برای انجام در یک Sprint مناسب است؟
در این مرحله Tester میتواند نقش مهمی داشته باشد. برای مثال، ممکن است Product Owner فقط سناریوی موفق را در نظر گرفته باشد، اما Tester درباره شرایطی مانند ورودی نامعتبر، محدودیتها، خطاها و حالتهای مرزی سؤال کند.
این گفتگوها میتوانند باعث شوند Acceptance Criteria قبل از شروع توسعه، شفافتر و قابل تستتر شوند.
Acceptance Criteria و Definition of Ready
در برخی تیمها مفهومی به نام Definition of Ready (DoR) نیز استفاده میشود.
DoR معمولاً مجموعهای از شرایط توافقشده است که مشخص میکند یک Product Backlog Item برای ورود به توسعه به اندازه کافی آماده است.
برای مثال، یک تیم ممکن است در Definition of Ready خود شرایطی مانند موارد زیر داشته باشد:
- User Story قابل فهم باشد.
- Acceptance Criteria مشخص و قابل بررسی باشد.
- وابستگیهای مهم شناسایی شده باشند.
- تیم درباره Scope درک مشترک داشته باشد.
- Story به اندازه کافی برای برآورد آماده باشد.
در این حالت Acceptance Criteria میتواند یکی از عواملی باشد که به آمادهبودن یک Story برای توسعه کمک میکند.
البته Definition of Ready یک الزام رسمی Scrum نیست و استفاده از آن به تصمیم و شیوه کاری خود تیم بستگی دارد.
Acceptance Criteria در Sprint Planning
در Sprint Planning نیز تیم میتواند Product Backlog Itemهای منتخب را بررسی کند و درباره شرایط پذیرش و نحوه رسیدگی به آنها به درک مشترک برسد.
اگر یک Story هنوز معیارهای پذیرش مبهم یا ناقصی داشته باشد، ممکن است تیم نتواند با اطمینان کافی درباره Scope، پیچیدگی و نحوه انجام کار تصمیم بگیرد.
بنابراین Acceptance Criteria واضح میتواند به موارد زیر کمک کند:
- درک بهتر Scope
- شناسایی ابهامات
- شناسایی وابستگیها
- برآورد بهتر کار
- برنامهریزی فعالیتهای تست
Acceptance Criteria در طول Sprint
تعریف Acceptance Criteria به این معنا نیست که بعد از شروع Sprint دیگر نباید درباره آن صحبت کرد.
در Agile ممکن است در طول توسعه اطلاعات جدیدی به دست آید یا مشخص شود که یک بخش از نیازمندی به اندازه کافی شفاف نبوده است. در چنین شرایطی تیم میتواند درباره Requirement و Acceptance Criteria گفتگو کند و در صورت نیاز آنها را اصلاح کند.
اما یک نکته مهم وجود دارد:
تغییر Acceptance Criteria میتواند Scope، پیادهسازی و تستهای موردنیاز را تغییر دهد؛ بنابراین تغییرات باید آگاهانه و با هماهنگی افراد مرتبط انجام شوند.
Acceptance Criteria نباید پس از مشاهده نتیجه تست، صرفاً برای اینکه یک Feature «Pass» شود تغییر کند.
اگر نیاز واقعی تغییر کرده است، اصلاح معیار پذیرش میتواند کاملاً منطقی باشد؛ اما اگر معیار فقط برای پوشاندن یک نقص در پیادهسازی تغییر کند، کیفیت فرایند را کاهش میدهد.
Acceptance Criteria و Sprint Review
در Sprint Review، Increment ایجادشده بررسی میشود و Stakeholderها میتوانند درباره نتیجه کار و مسیر آینده محصول بازخورد ارائه کنند.
Acceptance Criteria میتواند یکی از نقاط مرجع برای بررسی یک Product Backlog Item باشد؛ برای مثال تیم میتواند بررسی کند که آیا قابلیت لغو سفارش مطابق شرایط مورد انتظار عمل میکند یا خیر.
با این حال، Sprint Review را نباید صرفاً یک جلسه برای «اجرای Acceptance Criteria» در نظر گرفت. هدف Sprint Review گستردهتر است و شامل بررسی Increment، دریافت بازخورد Stakeholderها و بررسی تغییرات احتمالی در Product Backlog نیز میشود.
Acceptance Criteria و Scrum Guide
برای جلوگیری از یک برداشت اشتباه، باید توجه داشت که Acceptance Criteria یک Artifact یا الزام رسمی و مستقل در Scrum نیست.
Scrum یک چارچوب برای مدیریت و توسعه محصولات پیچیده ارائه میکند، اما قالب اجباری برای نوشتن User Story یا Acceptance Criteria تعیین نمیکند.
به همین دلیل ممکن است یک تیم Scrum از Acceptance Criteria استفاده کند و تیم دیگری از روش متفاوتی برای شفافکردن شرایط پذیرش Product Backlog Itemها استفاده کند.
بنابراین بهتر است بگوییم:
Acceptance Criteria یک تکنیک رایج و مفید برای شفافسازی شرایط پذیرش نیازمندیها در تیمهای Agile است، نه یک الزام رسمی Scrum.
نقش Tester در این فرایند
Tester میتواند در تمام این مراحل نقش فعالی داشته باشد.
بهجای اینکه Tester فقط در پایان Sprint منتظر دریافت Feature باشد، میتواند از همان مرحله Refinement درباره Acceptance Criteria سؤال کند.
برای مثال:
- اگر کاربر اطلاعات نامعتبر وارد کند، چه اتفاقی باید بیفتد؟
- حداکثر تعداد تلاش ناموفق چقدر است؟
- این پیام خطا دقیقاً چه زمانی باید نمایش داده شود؟
- در شرایط Edge Case چه رفتاری مورد انتظار است؟
این نوع مشارکت باعث میشود تست از ابتدای چرخه توسعه وارد فرایند شود و بسیاری از ابهامها پیش از پیادهسازی شناسایی شوند.
در نتیجه، Acceptance Criteria در Agile فقط ابزاری برای بررسی نتیجه کار نیست؛ بلکه میتواند در درک نیاز، شفافسازی، برنامهریزی، توسعه، تست و ارزیابی Increment نقش داشته باشد.
در بخش بعدی، موضوع را از زاویه تخصصیتر بررسی میکنیم: Acceptance Criteria دقیقاً چه نقشی در تست نرمافزار دارد و Tester چگونه میتواند از آن برای طراحی و اجرای تست استفاده کند؟
نقش Acceptance Criteria در تست نرمافزار
Acceptance Criteria یا معیارهای پذیرش یکی از ورودیهای مهم برای فعالیتهای تست نرمافزار است. Tester با استفاده از این معیارها میتواند درک دقیقتری از رفتار مورد انتظار سیستم به دست آورد و بررسی کند که Feature توسعهیافته تا چه اندازه با نیازمندی تعریفشده مطابقت دارد.
اما یک نکته مهم وجود دارد:
Acceptance Criteria جایگزین Test Strategy، Test Plan یا طراحی تست نیست؛ بلکه یکی از ورودیهای مهم در فرایند تست است.
۱. کمک به درک بهتر نیازمندی
اولین نقش Acceptance Criteria برای Tester، کمک به درک دقیقتر Requirement است.
فرض کنید User Story چنین باشد:
بهعنوان یک مشتری، میخواهم بتوانم سفارش خود را لغو کنم.
این جمله بهتنهایی برای طراحی تست کافی نیست.
اما اگر Acceptance Criteria مشخص کند:
- سفارش فقط قبل از ارسال قابل لغو است.
- پس از لغو، وضعیت سفارش باید تغییر کند.
- مبلغ سفارش باید طبق قوانین بازپرداخت شود.
- سفارش ارسالشده نباید قابل لغو باشد.
Tester دید بسیار دقیقتری نسبت به رفتار مورد انتظار سیستم خواهد داشت.
۲. شناسایی ابهامهای Requirement
Tester نباید Acceptance Criteria را صرفاً دریافت کند و منتظر اجرای تست بماند.
یکی از نقشهای مهم Tester این است که معیارهای پذیرش را از نظر قابلیت تست و کاملبودن بررسی کند.
برای مثال:
«سیستم باید عملکرد خوبی داشته باشد.»
این معیار مبهم است.
Tester میتواند سؤال کند:
- «عملکرد خوب» یعنی چه؟
- زمان پاسخ مورد انتظار چقدر است؟
- برای چه تعداد کاربر؟
- در چه شرایطی؟
- کدام عملیات باید اندازهگیری شود؟
این پرسشها میتوانند باعث شوند Requirement قبل از توسعه دقیقتر شود.
۳. کمک به طراحی Test Scenario
هر Acceptance Criterion میتواند نقطه شروعی برای شناسایی Test Scenarioهای مرتبط باشد.
Acceptance Criteria:
اگر موجودی حساب برای انجام تراکنش کافی نباشد، تراکنش نباید انجام شود.
Tester میتواند سناریوهایی مانند موارد زیر را بررسی کند:
- موجودی کمتر از مبلغ تراکنش
- موجودی دقیقاً برابر مبلغ تراکنش
- موجودی بیشتر از مبلغ تراکنش
- مبلغ نامعتبر
- تغییر موجودی در حین انجام تراکنش
بنابراین Acceptance Criteria به Tester کمک میکند دامنه اولیه تست را مشخص کند.
۴. کمک به طراحی Test Case
پس از شناسایی Test Scenarioها، Tester میتواند Test Caseهای دقیقتری طراحی کند.
Acceptance Criteria:
در صورت واردکردن رمز عبور اشتباه، کاربر نباید وارد حساب شود و باید پیام خطای مناسب نمایش داده شود.
ممکن است Test Caseهای مختلفی طراحی شوند:
| Test Case | ورودی | نتیجه مورد انتظار |
|---|---|---|
| رمز اشتباه | رمز نامعتبر | ورود انجام نشود |
| رمز خالی | مقدار خالی | پیام اعتبارسنجی نمایش داده شود |
| ایمیل نامعتبر | ایمیل نامعتبر + رمز اشتباه | ورود انجام نشود |
| چند تلاش ناموفق | چند بار رمز اشتباه | رفتار سیستم مطابق قوانین امنیتی باشد |
در نتیجه یک Acceptance Criterion میتواند به چند Test Case منجر شود.
۵. بررسی Positive و Negative Scenarioها
Acceptance Criteria به Tester کمک میکند علاوه بر Happy Path، شرایط منفی و Edge Caseها را نیز بررسی کند.
برای مثال:
کاربر باید بتواند یک فایل را آپلود کند.
این معیار میتواند سؤالات مختلفی ایجاد کند:
- اگر فایل بیش از حجم مجاز باشد چه اتفاقی میافتد؟
- اگر فرمت فایل مجاز نباشد چه میشود؟
- اگر کاربر فایل خالی ارسال کند چه اتفاقی رخ میدهد؟
- اگر اتصال هنگام آپلود قطع شود چه میشود؟
- اگر نام فایل شامل کاراکترهای خاص باشد چه اتفاقی رخ میدهد؟
همه این موارد الزاماً نباید در Acceptance Criteria نوشته شوند، اما Tester باید بررسی کند که آیا برای رسیدن به پوشش مناسب تست، نیاز به بررسی آنها وجود دارد یا خیر.
۶. کمک به Traceability
Acceptance Criteria میتواند ارتباط میان Requirement و Test را شفافتر کند.
بهعنوان مثال:
User Story
↓
Acceptance Criteria
↓
Test Scenario
↓
Test Case
↓
Test Result
این ارتباط میتواند به تیم کمک کند بررسی کند که آیا شرایط مهم Requirement واقعاً در تست پوشش داده شدهاند یا خیر.
در پروژههای بزرگتر، چنین ارتباطی میتواند بخشی از Requirements Traceability باشد.
۷. کمک به تعیین Scope تست
Acceptance Criteria میتواند محدوده اولیه تست را مشخص کند.
برای مثال اگر User Story درباره تغییر رمز عبور باشد و Acceptance Criteria فقط رفتار مربوط به تغییر موفق رمز عبور را مشخص کند، Tester میتواند بررسی کند که آیا موارد دیگری مانند:
- اعتبارسنجی رمز عبور
- خطاهای ورودی
- Session
- امنیت
- پیامهای خطا
نیز بر اساس سایر Requirements و ریسکهای سیستم باید تست شوند یا خیر.
بنابراین Acceptance Criteria میتواند Scope اولیه را مشخص کند، اما نباید بهعنوان تنها منبع تعیین Scope تست در نظر گرفته شود.
۸. کمک به Acceptance Testing
Acceptance Criteria میتواند ورودی مهمی برای Acceptance Testing باشد.
اگر معیار پذیرش مشخص کند:
«پس از ثبت موفق سفارش، شماره سفارش باید به کاربر نمایش داده شود.»
میتوان تستی طراحی کرد که بررسی کند:
- سفارش با موفقیت ثبت شده است.
- شماره سفارش تولید شده است.
- شماره سفارش به کاربر نمایش داده شده است.
- شماره نمایشدادهشده با سفارش ثبتشده مطابقت دارد.
در اینجا Acceptance Criteria به تعیین Expected Result کمک میکند.
۹. کمک به Regression Testing
اگر Acceptance Criteria یک Feature بهدرستی تعریف شده باشد، در تغییرات بعدی نیز میتوان از آن برای بررسی رفتار مورد انتظار استفاده کرد.
برای مثال، اگر در Feature پرداخت تغییراتی ایجاد شود، Testهای مرتبط با معیارهای پذیرش قبلی میتوانند در Regression Testing دوباره اجرا شوند تا مشخص شود تغییرات جدید رفتارهای قبلی را خراب نکردهاند.
البته Regression Testing فقط به Acceptance Criteria محدود نمیشود و باید بر اساس ریسک و تأثیر تغییرات برنامهریزی شود.
۱۰. کمک به Shift Left Testing
Acceptance Criteria باعث میشود Tester بتواند زودتر از مرحله اجرای تست در فرایند توسعه مشارکت کند.
بهجای اینکه Tester پس از تکمیل Feature بپرسد:
«این قابلیت دقیقاً باید چه رفتاری داشته باشد؟»
میتواند در زمان Refinement یا قبل از توسعه درباره معیارهای پذیرش سؤال کند.
این رویکرد با مفهوم Shift Left Testing همراستا است؛ یعنی فعالیتهای مرتبط با کیفیت و تست را تا حد امکان به مراحل ابتداییتر چرخه توسعه منتقل کنیم.
Acceptance Criteria تنها منبع طراحی تست نیست
این نکته بسیار مهم است.
Tester نباید تصور کند:
«هر چیزی که در Acceptance Criteria نوشته نشده، نیازی به تست ندارد.»
در یک پروژه واقعی، Tester ممکن است از منابع دیگری نیز برای طراحی تست استفاده کند:
- Requirements
- Business Rules
- Functional Specifications
- Non-functional Requirements
- Risk Analysis
- Design Documents
- Architecture
- قوانین و استانداردهای مرتبط
- تجربه و دانش دامنه
- تغییرات ایجادشده در سیستم
برای مثال، ممکن است Acceptance Criteria یک Login فقط رفتار موفق و ناموفق را مشخص کند، اما Tester بر اساس Security Requirements نیاز به بررسی موارد امنیتی دیگری نیز داشته باشد.
بنابراین Acceptance Criteria یک ورودی مهم برای تست است، نه تمام اطلاعات موردنیاز برای تست.
یک نگاه حرفهایتر به نقش Tester
Tester نباید Acceptance Criteria را فقط به این شکل ببیند:
«اینها مواردی هستند که باید تست کنم.»
نگاه بهتر این است:
«این معیارها بیانگر انتظارات مشخص از Feature هستند؛ آیا این انتظارات واضح، کامل، قابل تست و قابل قبول هستند؟»
این تغییر دیدگاه باعث میشود Tester فقط مجری Test Case نباشد و در بهبود کیفیت Requirement و پیشگیری از Defect نیز نقش داشته باشد.
در نتیجه، Acceptance Criteria میتواند از همان ابتدای چرخه توسعه به Tester کمک کند تا:
ابهام را شناسایی کند → Scope اولیه تست را مشخص کند → سناریوها را شناسایی کند → Test Case طراحی کند → نتایج را ارزیابی کند → و در نهایت درباره برآوردهشدن شرایط پذیرش گزارش دهد.
در بخش بعدی به سراغ اشتباهات رایج در نوشتن Acceptance Criteria میرویم؛ مواردی که باعث میشوند معیارهای پذیرش در عمل نتوانند نقش خود را بهدرستی ایفا کنند.
اشتباهات رایج در نوشتن Acceptance Criteria
داشتن Acceptance Criteria بهتنهایی تضمین نمیکند که Requirement بهاندازه کافی شفاف و قابل تست باشد. اگر معیارهای پذیرش به شکل نامناسب نوشته شوند، ممکن است حتی باعث ایجاد ابهام بیشتر، اختلاف برداشت و طراحی تستهای ناقص شوند.
در ادامه، مهمترین اشتباهات رایج را بررسی میکنیم.
۱. استفاده از عبارات مبهم
یکی از رایجترین مشکلات، استفاده از عباراتی است که تفسیرهای مختلفی دارند.
برای مثال:
«سیستم باید سریع باشد.»
یا:
«رابط کاربری باید ساده و کاربرپسند باشد.»
مشکل این جملات این است که مشخص نمیکنند سریع، ساده یا کاربرپسند دقیقاً یعنی چه.
اگر چنین ویژگیهایی واقعاً برای پذیرش Feature اهمیت دارند، باید تا حد امکان به معیارهای مشخص و قابل ارزیابی تبدیل شوند.
مثلاً به جای:
«صفحه باید سریع باز شود.»
میتوان گفت:
«صفحه نتایج جستوجو باید در شرایط تعریفشده، حداکثر طی ۲ ثانیه نمایش داده شود.»
۲. نوشتن Acceptance Criteria به شکل Test Steps
Acceptance Criteria نباید با Test Case یا Test Steps اشتباه گرفته شود.
برای مثال:
❌ نامناسب:
- وارد صفحه Login شوید.
- ایمیل را وارد کنید.
- رمز عبور را وارد کنید.
- روی Login کلیک کنید.
- Dashboard را بررسی کنید.
این متن بیشتر یک دستورالعمل برای اجرای تست است.
در عوض میتوان گفت:
«کاربر با واردکردن اطلاعات معتبر باید بتواند با موفقیت وارد حساب کاربری خود شود.»
در این حالت شرط پذیرش مشخص شده و Tester میتواند خودش روش مناسب بررسی آن را طراحی کند.
۳. بیش از حد فنیکردن معیارهای پذیرش
Acceptance Criteria معمولاً باید رفتار مورد انتظار سیستم را مشخص کند، نه جزئیات پیادهسازی.
برای مثال:
❌ «اطلاعات کاربر باید در جدول Users با استفاده از Stored Procedure ذخیره شود.»
اگر این موضوع یک الزام واقعی و مشخص فنی نباشد، چنین معیاری برای Acceptance Criteria مناسب نیست.
بهتر است بگوییم:
«پس از ثبت موفق اطلاعات کاربر، حساب کاربری باید ایجاد شده و اطلاعات آن در ورودهای بعدی قابل استفاده باشد.»
در این حالت مشخص شده چه چیزی باید اتفاق بیفتد، بدون اینکه الزاماً مشخص کنیم چگونه باید پیادهسازی شود.
۴. پوشش فقط Happy Path
گاهی تمام Acceptance Criteria فقط سناریوی موفق را پوشش میدهند.
برای مثال:
«کاربر با واردکردن اطلاعات صحیح وارد سیستم میشود.»
اما رفتار سیستم در شرایط نامعتبر مشخص نشده است.
بسته به اهمیت Feature، ممکن است لازم باشد مواردی مانند:
- اطلاعات ناقص
- اطلاعات نامعتبر
- محدودیتها
- خطاهای کسبوکار
- دسترسی غیرمجاز
- Edge Caseها
نیز بررسی شوند.
البته هدف این نیست که Acceptance Criteria به فهرستی عظیم از تمام Test Caseهای ممکن تبدیل شود؛ بلکه باید شرایط مهم کسبوکار و رفتارهای مورد انتظار مشخص شوند.
۵. ترکیب چند Requirement مستقل در یک Criterion
گاهی یک معیار پذیرش بیش از حد بزرگ میشود و چند رفتار مستقل را با هم ترکیب میکند.
مثلاً:
«کاربر بتواند سفارش را ثبت کند، پرداخت را انجام دهد، کد تخفیف وارد کند، آدرس را تغییر دهد و فاکتور دریافت کند.»
این معیار عملاً چند قابلیت متفاوت را در خود ترکیب کرده است.
بهتر است نیازمندی به شکل منطقی تفکیک شود تا هم درک آن آسانتر باشد و هم تست و نگهداری آن سادهتر شود.
۶. بیش از حد زیاد و پیچیدهکردن Acceptance Criteria
از طرف دیگر، نباید برای هر User Story دهها یا صدها معیار پذیرش تعریف کنیم.
اگر Acceptance Criteria بسیار طولانی و پیچیده شود، ممکن است نشانه این باشد که:
- User Story بیش از حد بزرگ است.
- چند Feature مختلف در یک Story قرار گرفتهاند.
- Requirement هنوز بهاندازه کافی تفکیک نشده است.
در چنین شرایطی بهتر است ابتدا Scope و ساختار User Storyها بازبینی شود.
۷. نوشتن معیارهایی که قابل تست نیستند
یک معیار پذیرش باید به شکلی نوشته شود که بتوان مشخص کرد Pass شده یا Fail.
برای مثال:
❌ «سیستم باید تجربه کاربری مناسبی ارائه دهد.»
این عبارت بهتنهایی معیار مشخصی برای تست ایجاد نمیکند.
اگر تجربه کاربری واقعاً بخشی از نیاز است، باید معیارهای مشخصتری برای آن تعریف شود؛ مثلاً بر اساس زمان انجام یک فرایند، تعداد مراحل، الزامات دسترسیپذیری یا سایر معیارهای قابل ارزیابی.
۸. وابستهکردن معیار به یک راهحل خاص
گاهی معیار پذیرش به جای بیان نیاز، راهحل را از قبل تعیین میکند.
برای مثال:
«کاربر باید از طریق یک دکمه آبیرنگ در گوشه بالا سمت راست بتواند سفارش را لغو کند.»
اگر رنگ و محل دکمه واقعاً Requirement طراحی نیست، این معیار بیش از حد وارد جزئیات Solution شده است.
ممکن است بهتر باشد:
«کاربر باید بتواند سفارش واجد شرایط را لغو کند.»
البته اگر رنگ، محل یا نوع کنترل واقعاً بخشی از Requirement یا Design Specification باشد، میتواند بهعنوان یک الزام مشخص مطرح شود.
۹. نادیدهگرفتن شرایط مرزی (Boundary Conditions)
گاهی Acceptance Criteria مقدار عادی را مشخص میکند، اما درباره حدود مجاز چیزی نمیگوید.
مثلاً:
«کاربر میتواند مبلغ سفارش را وارد کند.»
اما مشخص نیست:
- حداقل مبلغ چقدر است؟
- حداکثر مبلغ چقدر است؟
- صفر مجاز است؟
- مقدار اعشاری مجاز است؟
- مقدار منفی چه میشود؟
در چنین مواردی، مشخصکردن Boundaryها میتواند به جلوگیری از ابهام و طراحی تستهای ناقص کمک کند.
۱۰. تغییر Acceptance Criteria برای پاسکردن تست
این یکی از اشتباهات جدی است.
فرض کنید Tester یک Defect پیدا میکند و مشخص میشود سیستم با Acceptance Criteria تعریفشده مطابقت ندارد.
نباید صرفاً برای اینکه Feature Pass شود، معیار پذیرش را تغییر دهیم.
ابتدا باید مشخص شود:
آیا Requirement اشتباه بوده یا Implementation مشکل دارد؟
اگر نیاز کسبوکار واقعاً تغییر کرده باشد، Acceptance Criteria نیز میتواند تغییر کند؛ اما این تغییر باید آگاهانه، مستند و با توافق افراد مرتبط انجام شود.
تغییر معیار صرفاً برای مخفیکردن یک Defect، کیفیت فرایند را کاهش میدهد.
۱۱. نادیدهگرفتن نیازهای غیرعملکردی
Acceptance Criteria گاهی فقط رفتار Functional سیستم را پوشش میدهد.
اما بسته به Feature ممکن است نیازهای Non-functional نیز اهمیت داشته باشند.
برای مثال:
«نتیجه جستوجو باید حداکثر طی ۲ ثانیه نمایش داده شود.»
یا:
«کاربر دارای محدودیت بینایی باید بتواند با استفاده از Keyboard به تمام کنترلهای اصلی فرم دسترسی داشته باشد.»
در چنین شرایطی، Performance، Accessibility، Security یا سایر ویژگیهای کیفی نیز ممکن است در معیارهای پذیرش یا سایر Requirements مرتبط منعکس شوند.
نکته مهم این است که تمام نیازهای غیرعملکردی الزاماً نباید داخل Acceptance Criteria قرار بگیرند؛ بلکه باید مطمئن شویم نیازهای مهم محصول در جای مناسب تعریف و قابل ارزیابی شدهاند.
۱۲. نادیدهگرفتن دیدگاه کاربر و کسبوکار
Acceptance Criteria نباید صرفاً از دید تیم فنی نوشته شود.
اگر معیارها فقط بر اساس اینکه «Developer چگونه میتواند Feature را پیادهسازی کند» تعریف شوند، ممکن است نیاز واقعی کاربر یا کسبوکار نادیده گرفته شود.
معیار پذیرش باید در نهایت به این سؤال پاسخ دهد:
آیا این Feature همان ارزشی را ایجاد میکند که کاربر و کسبوکار انتظار دارند؟
یک چکلیست کوتاه برای بازبینی Acceptance Criteria
قبل از نهاییکردن معیارهای پذیرش میتوان این موارد را بررسی کرد:
- آیا هر معیار واضح و بدون ابهام است؟
- آیا قابل تست و قابل تأیید است؟
- آیا روی رفتار و نتیجه مورد انتظار تمرکز دارد؟
- آیا بیش از حد وارد جزئیات Implementation نشده است؟
- آیا شرایط مهم مثبت و منفی در نظر گرفته شدهاند؟
- آیا Boundary و محدودیتهای مهم مشخص هستند؟
- آیا معیارها با نیاز واقعی کسبوکار هماهنگ هستند؟
- آیا معیارها بیش از حد زیاد یا پیچیده نشدهاند؟
- آیا نیازهای مهم Non-functional نادیده گرفته نشدهاند؟
- آیا تغییرات معیارها به شکل کنترلشده انجام میشوند؟
در نهایت، Acceptance Criteria خوب باید ابهام را کاهش دهد، نه اینکه صرفاً حجم مستندات پروژه را افزایش دهد.
در بخش بعدی، یک مثال کامل را از ابتدا تا انتها بررسی میکنیم؛ از User Story شروع میکنیم، Acceptance Criteria را تعریف میکنیم و سپس نشان میدهیم چگونه میتوان بر اساس آن Test Scenario و Test Case طراحی کرد.
یک مثال کامل از User Story تا Acceptance Criteria و Test Case
برای اینکه مفهوم Acceptance Criteria کاملاً کاربردی شود، بهتر است یک مثال را از ابتدا تا انتها دنبال کنیم.
فرض کنید در یک فروشگاه اینترنتی قرار است قابلیتی ایجاد شود که کاربر بتواند کد تخفیف خود را هنگام ثبت سفارش وارد کند.
۱. User Story
ابتدا نیاز را به شکل یک User Story بیان میکنیم:
بهعنوان یک مشتری، میخواهم بتوانم هنگام ثبت سفارش کد تخفیف وارد کنم تا در صورت معتبر بودن، مبلغ سفارش من کاهش پیدا کند.
این User Story مشخص میکند:
- چه کسی؟ مشتری
- چه چیزی؟ واردکردن کد تخفیف
- چرا؟ کاهش مبلغ سفارش در صورت معتبر بودن کد
اما هنوز مشخص نیست کد تخفیف در چه شرایطی معتبر است و سیستم در حالتهای مختلف چه رفتاری باید داشته باشد.
اینجاست که Acceptance Criteria اهمیت پیدا میکند.
۲. تعریف Acceptance Criteria
برای این User Story میتوان معیارهای پذیرش زیر را تعریف کرد:
- کاربر باید بتواند کد تخفیف را در مرحله ثبت سفارش وارد کند.
- اگر کد تخفیف معتبر باشد، تخفیف باید روی مبلغ سفارش اعمال شود.
- اگر کد تخفیف نامعتبر باشد، تخفیف نباید اعمال شود و پیام مناسب نمایش داده شود.
- اگر کد تخفیف منقضی شده باشد، نباید قابل استفاده باشد.
- اگر حداقل مبلغ لازم برای استفاده از کد تخفیف رعایت نشده باشد، تخفیف نباید اعمال شود.
- پس از اعمال موفق کد تخفیف، مبلغ نهایی سفارش باید بهدرستی محاسبه شود.
در این مرحله هنوز وارد جزئیات Test Case نشدهایم.
ما فقط مشخص کردهایم که چه شرایطی برای پذیرش این قابلیت لازم است.
۳. تبدیل Acceptance Criteria به Test Scenario
حالا Tester میتواند بر اساس معیارهای پذیرش، Test Scenarioهای مختلفی را شناسایی کند.
| Acceptance Criteria | Test Scenario |
|---|---|
| کد معتبر باید اعمال شود | بررسی اعمال کد تخفیف معتبر |
| کد نامعتبر نباید اعمال شود | بررسی واردکردن کد تخفیف نامعتبر |
| کد منقضی نباید اعمال شود | بررسی کد تخفیف منقضیشده |
| حداقل مبلغ باید رعایت شود | بررسی سفارش کمتر از حداقل مبلغ |
| مبلغ نهایی باید درست محاسبه شود | بررسی محاسبه مبلغ پس از تخفیف |
در اینجا مشخص میشود که یک Acceptance Criterion میتواند به یک یا چند Test Scenario منجر شود.
۴. طراحی Test Case
حالا یکی از سناریوها را به یک Test Case دقیق تبدیل میکنیم.
Test Case: اعمال کد تخفیف معتبر
Precondition:
- کاربر وارد حساب خود شده است.
- یک کد تخفیف معتبر در سیستم وجود دارد.
- مبلغ سفارش شرایط استفاده از کد را دارد.
Test Steps:
- یک محصول به سبد خرید اضافه کنید.
- وارد صفحه ثبت سفارش شوید.
- کد تخفیف معتبر را وارد کنید.
- گزینه اعمال کد تخفیف را انتخاب کنید.
Expected Result:
تخفیف باید با موفقیت اعمال شود و مبلغ نهایی سفارش به میزان صحیح کاهش پیدا کند.
در اینجا Acceptance Criteria به ما گفته بود چه چیزی باید اتفاق بیفتد و Test Case مشخص کرده است چگونه آن را بررسی کنیم.
۵. تست حالت منفی
حالا یک حالت منفی را بررسی کنیم.
Test Case: استفاده از کد تخفیف نامعتبر
Precondition:
کاربر در صفحه ثبت سفارش قرار دارد.
Test Steps:
- یک محصول به سبد خرید اضافه کنید.
- وارد صفحه ثبت سفارش شوید.
- یک کد تخفیف نامعتبر وارد کنید.
- گزینه اعمال کد را انتخاب کنید.
Expected Result:
کد تخفیف نباید اعمال شود و پیام خطای مناسب باید به کاربر نمایش داده شود.
این Test Case از این Acceptance Criterion استخراج شده است:
اگر کد تخفیف نامعتبر باشد، تخفیف نباید اعمال شود و پیام مناسب نمایش داده شود.
۶. بررسی Boundary
حالا فرض کنیم Acceptance Criteria میگوید:
برای استفاده از کد تخفیف، مبلغ سفارش باید حداقل ۵۰۰ هزار تومان باشد.
Tester نباید فقط یک مقدار کمتر و یک مقدار بیشتر را بررسی کند.
میتوان حالتهای مرزی را نیز بررسی کرد:
| مبلغ سفارش | انتظار |
|---|---|
| ۴۹۹٬۹۹۹ تومان | تخفیف اعمال نشود |
| ۵۰۰٬۰۰۰ تومان | تخفیف اعمال شود |
| ۵۰۰٬۰۰۱ تومان | تخفیف اعمال شود |
این مثال نشان میدهد Acceptance Criteria میتواند نقطه شروع مناسبی برای استفاده از تکنیکهای طراحی تست مانند Boundary Value Analysis باشد.
۷. یک Acceptance Criterion میتواند چند Test Case داشته باشد
برای مثال، این معیار را در نظر بگیرید:
اگر کد تخفیف نامعتبر باشد، تخفیف نباید اعمال شود.
این معیار میتواند Test Caseهای مختلفی داشته باشد:
- کد کاملاً نامعتبر
- کد خالی
- کد با فرمت نامعتبر
- کد منقضیشده
- کد مربوط به کمپین دیگری
- کدی که قبلاً استفاده شده است
بنابراین رابطه بین Acceptance Criteria و Test Case الزاماً یکبهیک نیست.
بهتر است آن را اینگونه تصور کنیم:
یک User Story
⬇️
چند Acceptance Criteria
⬇️
چند Test Scenario
⬇️
چندین Test Case
۸. آیا همه Test Caseها باید مستقیماً در Acceptance Criteria نوشته شده باشند؟
خیر.
این نکته برای Tester بسیار مهم است.
Acceptance Criteria باید شرایط مهم پذیرش Feature را مشخص کند، اما Test Design میتواند جزئیات بسیار بیشتری داشته باشد.
برای مثال، Acceptance Criteria میگوید:
کد تخفیف معتبر باید اعمال شود.
Tester ممکن است بر اساس تجربه و تکنیکهای طراحی تست، موارد زیر را نیز بررسی کند:
- کد با حروف کوچک و بزرگ
- فاصله قبل یا بعد از کد
- کد با طول غیرمجاز
- کاراکترهای خاص
- چند بار اعمالکردن یک کد
- تغییر تعداد محصولات پس از اعمال تخفیف
- حذف محصول پس از اعمال تخفیف
- Refresh کردن صفحه پس از اعمال کد
- استفاده همزمان از چند کد تخفیف
همه این موارد لزوماً نباید در Acceptance Criteria نوشته شوند.
۹. Acceptance Criteria بهعنوان یک توافق مشترک
یکی از ارزشهای مهم Acceptance Criteria این است که فقط برای Tester نوشته نمیشود.
فرض کنید Product Owner، Developer و Tester درباره کد تخفیف صحبت میکنند.
Product Owner میگوید:
«کد تخفیف معتبر باید روی سفارش اعمال شود.»
Tester میپرسد:
«اگر کد منقضی شده باشد چه اتفاقی باید بیفتد؟»
Developer میپرسد:
«اگر سفارش حداقل مبلغ لازم را نداشته باشد، باید کد را قبول کنیم یا رد کنیم؟»
این گفتگوها باعث میشوند ابهامات قبل از پیادهسازی مشخص شوند.
بنابراین Acceptance Criteria میتواند به ایجاد یک درک مشترک (Shared Understanding) بین اعضای تیم کمک کند.
۱۰. Acceptance Criteria و تست پایان کار
پس از توسعه Feature، تیم میتواند بررسی کند که آیا معیارهای پذیرش برآورده شدهاند یا خیر.
| Acceptance Criteria | نتیجه |
|---|---|
| ورود کد تخفیف امکانپذیر باشد | ✅ Pass |
| کد معتبر اعمال شود | ✅ Pass |
| کد نامعتبر رد شود | ✅ Pass |
| کد منقضی رد شود | ✅ Pass |
| حداقل مبلغ رعایت شود | ❌ Fail |
| مبلغ نهایی صحیح محاسبه شود | ✅ Pass |
در این مثال، یکی از Acceptance Criteria هنوز برآورده نشده است.
بنابراین Feature از نظر معیارهای پذیرش کامل نیست و تیم باید وضعیت موردنظر را مطابق فرایند پروژه پیگیری کند.
نکته مهم: Acceptance Criteria، Test Case و Expected Result یکی نیستند
این سه مفهوم ممکن است شبیه به نظر برسند، اما نقش متفاوتی دارند.
Acceptance Criteria:
اگر کد تخفیف معتبر باشد، تخفیف باید روی سفارش اعمال شود.
Test Case:
واردکردن یک کد تخفیف معتبر و انتخاب گزینه «اعمال».
Expected Result:
تخفیف باید اعمال شود و مبلغ سفارش به میزان صحیح کاهش پیدا کند.
پس میتوان گفت:
Acceptance Criteria، Test Case را هدایت میکند؛ اما Test Case جزئیات اجرای تست را مشخص میکند.
این تفاوت بهخصوص برای Testerهایی مهم است که تازه وارد فضای Agile شدهاند و ممکن است Acceptance Criteria را با Test Case اشتباه بگیرند.
جمعبندی مثال
در مثال کد تخفیف، مسیر به شکل زیر بود:
User Story
مشتری میخواهد بتواند کد تخفیف وارد کند.
⬇️
Acceptance Criteria
کد معتبر اعمال شود، کد نامعتبر رد شود، شرایط استفاده رعایت شود و مبلغ نهایی صحیح باشد.
⬇️
Test Scenario
بررسی کد معتبر، کد نامعتبر، کد منقضی، حداقل مبلغ و محاسبه مبلغ نهایی.
⬇️
Test Case
دادهها، Preconditions، Test Steps و Expected Results مشخص میشوند.
⬇️
Test Execution
تست اجرا میشود و نتیجه Pass یا Fail ثبت میشود.
این زنجیره نشان میدهد Acceptance Criteria دقیقاً در کجای فرایند قرار میگیرد و چرا برای Tester اهمیت دارد.
ویژگیهای یک Acceptance Criteria خوب
یک Acceptance Criteria خوب باید به اندازهای واضح باشد که اعضای مختلف تیم، بدون نیاز به حدس و تفسیر شخصی، برداشت تقریباً یکسانی از آن داشته باشند.
معیارهای پذیرش قرار است مشخص کنند یک User Story یا Feature تحت چه شرایطی قابل قبول است؛ بنابراین کیفیت خود Acceptance Criteria میتواند مستقیماً روی کیفیت توسعه و تست تأثیر بگذارد.
۱. واضح و بدون ابهام باشد
اولین ویژگی یک معیار پذیرش خوب، واضح بودن آن است.
برای مثال:
❌ «سیستم باید سریع باشد.»
این عبارت مشخص نمیکند منظور از «سریع» چیست.
اما:
✅ «نتایج جستوجو باید حداکثر طی ۲ ثانیه نمایش داده شوند.»
معیار مشخصتری ایجاد میکند.
در حالت دوم میتوان بررسی کرد که آیا شرط موردنظر برآورده شده است یا خیر.
۲. قابل تست (Testable) باشد
هر Acceptance Criterion باید به شکلی نوشته شود که بتوان آن را بررسی و درباره برآوردهشدن یا نشدن آن تصمیم گرفت.
برای مثال:
❌ «کاربر باید تجربه خوبی از فرایند خرید داشته باشد.»
این عبارت بهتنهایی معیار مشخصی برای تست ایجاد نمیکند.
اما اگر نیاز واقعی کسبوکار این باشد که کاربر بتواند خرید را در حداکثر چند مرحله مشخص انجام دهد، میتوان معیار را دقیقتر کرد.
برای مثال:
«کاربر باید بتواند بدون ورود مجدد اطلاعات، سفارش خود را از سبد خرید تا صفحه پرداخت تکمیل کند.»
البته این مثال زمانی مناسب است که واقعاً چنین شرطی بخشی از نیاز محصول باشد.
۳. قابل اندازهگیری یا قابل ارزیابی باشد
هر Acceptance Criteria الزاماً نباید یک عدد داشته باشد، اما باید بتوانیم به شکل مشخصی تشخیص دهیم که آیا شرط برآورده شده است یا خیر.
برای مثال:
«کاربر باید بتواند فایل PDF را با موفقیت بارگذاری کند.»
قابل ارزیابی است؛ زیرا میتوان فایل را بارگذاری کرد و نتیجه را بررسی کرد.
در مقابل:
«سیستم باید عملکرد بسیار خوبی داشته باشد.»
بدون تعریف «عملکرد خوب»، قابل ارزیابی دقیق نیست.
۴. روی نتیجه مورد انتظار تمرکز کند
Acceptance Criteria بهتر است بیشتر روی رفتار و نتیجه مورد انتظار سیستم تمرکز داشته باشد، نه جزئیات پیادهسازی.
برای مثال:
❌ «اطلاعات کاربر باید در جدول Users دیتابیس ذخیره شود.»
اگر نحوه ذخیرهسازی یک الزام واقعی نباشد، این معیار بیش از حد وارد Implementation شده است.
بهتر است گفته شود:
«پس از ثبت موفقنام، اطلاعات کاربر باید برای ورودهای بعدی قابل استفاده باشد.»
در این حالت مشخص شده سیستم چه رفتاری باید داشته باشد، بدون اینکه راهحل فنی از قبل تحمیل شود.
۵. با User Story و نیاز کسبوکار هماهنگ باشد
Acceptance Criteria نباید جدا از هدف User Story نوشته شود.
برای مثال اگر User Story این باشد:
بهعنوان مشتری، میخواهم بتوانم سفارش خود را لغو کنم تا در صورت تغییر تصمیم، خرید خود را متوقف کنم.
معیارهای پذیرش باید به همین هدف مرتبط باشند.
- سفارش واجد شرایط باید قابل لغو باشد.
- سفارش ارسالشده نباید قابل لغو باشد.
- پس از لغو، وضعیت سفارش باید تغییر کند.
- در صورت پرداخت قبلی، بازپرداخت باید مطابق قوانین کسبوکار انجام شود.
اگر معیارهایی مانند «رنگ دکمه باید آبی باشد» اضافه کنیم، در صورتی که چنین الزامی در نیاز محصول وجود نداشته باشد، معیار از هدف اصلی User Story فاصله گرفته است.
۶. شرایط مهم را پوشش دهد
Acceptance Criteria خوب باید شرایط مهم و معنادار Feature را پوشش دهد.
این موضوع فقط به Happy Path محدود نمیشود.
برای مثال در قابلیت Login، میتوان شرایطی مانند موارد زیر را در نظر گرفت:
- ورود با اطلاعات معتبر
- ورود با رمز عبور اشتباه
- ورود با اطلاعات ناقص
- حساب کاربری غیرفعال
- محدودیت تعداد تلاشهای ناموفق
البته قرار نیست Acceptance Criteria تمام Test Caseهای ممکن را شامل شود.
هدف این است که شرایط مهم کسبوکار و رفتار مورد انتظار مشخص شوند.
۷. بیش از حد بزرگ و پیچیده نباشد
اگر یک Acceptance Criterion چندین رفتار مستقل را در خود جای دهد، ممکن است بررسی و نگهداری آن دشوار شود.
برای مثال:
«کاربر باید بتواند سفارش ایجاد کند، کد تخفیف وارد کند، پرداخت انجام دهد، آدرس را تغییر دهد و فاکتور دریافت کند.»
این معیار بیش از حد گسترده است.
بهتر است رفتارهای مستقل به شکل منطقی تفکیک شوند.
Acceptance Criteria باید به اندازهای جزئی باشد که یک شرط مشخص را روشن کند، اما آنقدر ریز نشود که عملاً به مجموعهای از Test Steps تبدیل شود.
۸. قابل فهم برای افراد فنی و غیر فنی باشد
یکی از مزایای مهم Acceptance Criteria این است که میتواند به ایجاد یک درک مشترک بین اعضای تیم کمک کند.
بنابراین بهتر است تا حد امکان از زبان ساده و قابل فهم استفاده شود.
Product Owner، Business Analyst، Developer و Tester باید بتوانند درباره یک معیار پذیرش برداشت مشترکی داشته باشند.
برای مثال:
❌ «در صورت دریافت HTTP 401 از سرویس Authentication، سیستم باید Exception مربوطه را Handle کند.»
اگر این موضوع یک الزام فنی خاص نباشد، برای Acceptance Criteria سطح بالایی از جزئیات فنی دارد.
ممکن است بهتر باشد:
«اگر اعتبار کاربر منقضی شده باشد، سیستم باید کاربر را به فرایند ورود مجدد هدایت کند.»
۹. شرایط مرزی مهم را مشخص کند
در برخی Featureها، Boundaryها بخش مهمی از Requirement هستند.
برای مثال:
«کاربر میتواند فایلی با حداکثر حجم ۱۰ مگابایت بارگذاری کند.»
این معیار، یک Boundary مشخص ایجاد میکند.
در نتیجه میتوان انتظار داشت:
- فایل ۹ مگابایتی → مجاز
- فایل ۱۰ مگابایتی → مجاز
- فایل ۱۰.۱ مگابایتی → غیرمجاز
مشخصکردن چنین محدودیتهایی میتواند از اختلاف برداشت بین تیم جلوگیری کند.
۱۰. مستقل از Test Case باشد
Acceptance Criteria باید شرایط پذیرش را مشخص کند، نه اینکه تمام جزئیات اجرای تست را در خود جای دهد.
برای مثال:
❌ «وارد صفحه Login شوید، ایمیل test@example.com را وارد کنید، رمز 123456 را وارد کنید و روی Login کلیک کنید.»
این متن بیشتر Test Steps است.
بهتر است Acceptance Criteria چنین باشد:
«کاربر با واردکردن اطلاعات معتبر باید بتواند با موفقیت وارد حساب کاربری شود.»
سپس Tester میتواند Test Data و Test Steps مناسب را طراحی کند.
۱۱. امکان بررسی آن توسط تیم وجود داشته باشد
Acceptance Criteria باید به شکلی نوشته شود که در پایان بتوان درباره وضعیت آن تصمیم گرفت:
Pass یا Fail
برای مثال:
«اگر موجودی حساب برای انجام تراکنش کافی نباشد، تراکنش نباید انجام شود.»
پس از اجرای تست میتوان مشخص کرد که این شرط برآورده شده یا خیر.
این ویژگی باعث میشود Acceptance Criteria بتواند نقش مهمی در Acceptance Testing و ارزیابی Feature داشته باشد.
۱۲. با Definition of Done اشتباه نشود
Acceptance Criteria باید روی شرایط پذیرش Feature تمرکز کند.
Definition of Done معمولاً شرایط عمومیتری را برای Done شدن یک آیتم مشخص میکند.
برای مثال:
Acceptance Criteria:
«پس از ثبت سفارش موفق، شماره سفارش باید به کاربر نمایش داده شود.»
Definition of Done:
«Acceptance Criteria پاس شده باشد، Code Review انجام شده باشد، تستهای لازم اجرا شده باشند و سایر شرایط عمومی تیم رعایت شده باشند.»
بنابراین این دو مفهوم میتوانند در کنار هم استفاده شوند، اما یکسان نیستند.
یک چکلیست برای Acceptance Criteria خوب
قبل از نهاییکردن معیارهای پذیرش، میتوانیم چند سؤال ساده از خودمان بپرسیم:
- آیا این معیار واضح است؟
- آیا ابهام قابل توجهی دارد؟
- آیا قابل تست است؟
- آیا میتوان Pass یا Fail بودن آن را مشخص کرد؟
- آیا با هدف User Story هماهنگ است؟
- آیا نیاز واقعی کاربر یا کسبوکار را پوشش میدهد؟
- آیا شرایط مهم مثبت و منفی در نظر گرفته شدهاند؟
- آیا Boundaryهای مهم مشخص شدهاند؟
- آیا بیش از حد وارد جزئیات Implementation نشده است؟
- آیا با Test Case اشتباه نشده است؟
- آیا بیش از حد بزرگ یا پیچیده نیست؟
- آیا افراد فنی و غیر فنی میتوانند آن را درک کنند؟
در نهایت، میتوان گفت یک Acceptance Criteria خوب باید سه ویژگی اصلی داشته باشد:
واضح باشد، قابل تست باشد و درباره شرایط پذیرش ابهام ایجاد نکند.
در بخش بعدی، روشهای مختلف نوشتن Acceptance Criteria را بررسی میکنیم و میبینیم چه زمانی استفاده از قالب ساده، Rule-Based یا Given/When/Then مناسبتر است.
چگونه Acceptance Criteria بنویسیم؟ راهنمای گامبهگام
نوشتن Acceptance Criteria (معیارهای پذیرش) فقط به این معنا نیست که چند شرط را زیر یک User Story قرار دهیم. برای اینکه معیارهای پذیرش واقعاً مفید باشند، باید ابتدا نیاز را درک کنیم، رفتارهای مهم را شناسایی کنیم و سپس شرایط پذیرش را به شکلی واضح و قابل تست بیان کنیم.
در ادامه یک فرایند عملی را مرحلهبهمرحله بررسی میکنیم.
گام ۱: ابتدا User Story را بهخوبی درک کنید
قبل از نوشتن Acceptance Criteria باید مشخص باشد:
- چه کسی از قابلیت استفاده میکند؟
- چه نیازی دارد؟
- چه هدفی را دنبال میکند؟
- این Feature چه ارزشی ایجاد میکند؟
برای مثال:
بهعنوان یک مشتری، میخواهم بتوانم سفارش خود را لغو کنم تا در صورت تغییر تصمیم، خرید خود را متوقف کنم.
در این مرحله هنوز Acceptance Criteria ننوشتهایم؛ ابتدا باید هدف User Story را درک کنیم.
گام ۲: رفتار مورد انتظار را مشخص کنید
حالا باید ببینیم سیستم برای برآوردهکردن این نیاز چه رفتاری باید داشته باشد.
در مثال لغو سفارش، ممکن است سؤالاتی مانند این مطرح شوند:
- چه سفارشهایی قابل لغو هستند؟
- آیا سفارش ارسالشده قابل لغو است؟
- بعد از لغو چه اتفاقی برای وضعیت سفارش میافتد؟
- اگر سفارش قبلاً پرداخت شده باشد چه میشود؟
- آیا مبلغ باید بازپرداخت شود؟
- آیا کاربر باید پیام تأیید دریافت کند؟
این مرحله اهمیت زیادی دارد، زیرا بسیاری از ابهامهای Requirement در همین گفتگوها مشخص میشوند.
گام ۳: شرایط پذیرش را از قوانین کسبوکار جدا کنید
گاهی یک Feature تحت تأثیر قوانین مختلف کسبوکار قرار دارد.
برای مثال:
سفارش فقط قبل از ارسال قابل لغو است.
یا:
مبلغ سفارش پس از لغو، طبق روش پرداخت اولیه بازپرداخت میشود.
این قوانین باید در Acceptance Criteria یا Requirementهای مرتبط به شکلی روشن منعکس شوند.
هدف این نیست که تمام قوانین سازمان را داخل Acceptance Criteria قرار دهیم؛ فقط قوانینی که برای پذیرش این Feature ضروری هستند باید مشخص شوند.
گام ۴: Happy Path را مشخص کنید
ابتدا سناریوی اصلی و موفق را مشخص کنید.
اگر سفارش هنوز ارسال نشده باشد، کاربر باید بتواند آن را لغو کند.
این همان Happy Path است؛ یعنی حالتی که همه شرایط لازم برقرار هستند و عملیات باید با موفقیت انجام شود.
مشخصکردن Happy Path کمک میکند رفتار اصلی Feature واضح شود.
گام ۵: حالتهای منفی و استثناها را بررسی کنید
بعد از مشخصکردن سناریوی موفق، باید ببینیم در شرایط غیرعادی چه اتفاقی باید بیفتد.
برای مثال:
- اگر سفارش قبلاً ارسال شده باشد چه میشود؟
- اگر سفارش قبلاً لغو شده باشد چه میشود؟
- اگر عملیات بازپرداخت با خطا مواجه شود چه میشود؟
- اگر کاربر اجازه لغو سفارش را نداشته باشد چه اتفاقی میافتد؟
ممکن است همه این موارد به Acceptance Criteria تبدیل نشوند، اما باید مشخص شود که آیا برای این Feature اهمیت دارند یا خیر.
گام ۶: Boundaryها و محدودیتها را مشخص کنید
اگر Feature دارای محدودیت عددی یا زمانی است، باید حدود آن مشخص شود.
«سفارش تا ۳۰ دقیقه پس از ثبت قابل لغو است.»
در این حالت باید مشخص شود:
- ۲۹ دقیقه → قابل لغو
- ۳۰ دقیقه → آیا قابل لغو است؟
- ۳۱ دقیقه → غیرقابل لغو
اگر این Boundary مشخص نباشد، ممکن است Developer، Tester و Product Owner برداشتهای متفاوتی داشته باشند.
گام ۷: Acceptance Criteria را به زبان ساده بنویسید
بعد از مشخصشدن رفتارها، معیارها را با زبانی بنویسید که برای اعضای مختلف تیم قابل درک باشد.
«اگر سفارش ارسال شده باشد، گزینه لغو سفارش نباید در دسترس کاربر باشد.»
این جمله نسبت به یک توضیح فنی درباره وضعیت داخلی Order Service، واضحتر و قابل فهمتر است.
گام ۸: در صورت نیاز از Given / When / Then استفاده کنید
اگر رفتار Feature پیچیده است یا چند سناریوی مشخص دارد، میتوان Acceptance Criteria را با ساختار Given / When / Then نوشت.
برای مثال:
Given: سفارش هنوز ارسال نشده است.
When: کاربر گزینه «لغو سفارش» را انتخاب میکند.
Then: سفارش باید لغو شود و وضعیت آن به «لغوشده» تغییر کند.
این ساختار کمک میکند ارتباط بین شرایط اولیه، اقدام و نتیجه واضح باشد.
گام ۹: معیارها را قابل تست کنید
حالا هر Criterion را بررسی کنید و از خود بپرسید:
«آیا Tester میتواند بر اساس این جمله یک تست طراحی کند و مشخص کند Pass شده یا Fail؟»
برای مثال:
❌ «سیستم باید پیام مناسبی نمایش دهد.»
مشکل این است که «مناسب» تعریف نشده است.
در صورت امکان باید مشخص شود چه پیامی یا چه نوع اطلاعاتی باید نمایش داده شود.
البته در برخی پروژهها متن دقیق پیام ممکن است در یک Requirement یا Design Specification جداگانه تعریف شود. در این حالت لازم نیست همان جزئیات دوباره در Acceptance Criteria تکرار شوند.
گام ۱۰: Acceptance Criteria را با تیم Review کنید
Acceptance Criteria نباید الزاماً توسط یک نفر نوشته و بدون بررسی وارد توسعه شود.
در تیمهای Agile، میتوان آن را با افراد مرتبط بررسی کرد:
- Product Owner
- Business Analyst
- Developer
- Tester
- سایر Stakeholderهای مرتبط
هر کدام میتوانند از زاویه متفاوتی ابهامها را شناسایی کنند.
برای مثال:
- Product Owner: آیا رفتار با نیاز کسبوکار مطابقت دارد؟
- Developer: آیا Requirement از نظر فنی قابل پیادهسازی است؟
- Tester: آیا Requirement قابل تست است و شرایط مهم را پوشش میدهد؟
این همکاری میتواند قبل از شروع توسعه، بسیاری از مشکلات را آشکار کند.
گام ۱۱: بررسی کنید آیا Story بیش از حد بزرگ نشده است
اگر برای یک User Story تعداد بسیار زیادی Acceptance Criteria لازم باشد، ممکن است مشکل از خود Story باشد.
برای مثال:
«کاربر بتواند حساب کاربری ایجاد کند، پروفایل را تکمیل کند، رمز عبور را تغییر دهد، سفارش ثبت کند و پرداخت انجام دهد.»
این User Story بیش از حد گسترده است.
در چنین شرایطی بهتر است ابتدا Story به چند بخش منطقی تقسیم شود.
Acceptance Criteria باید به شفافسازی یک Feature کمک کند، نه اینکه ضعف در تفکیک نیازمندیها را پنهان کند.
گام ۱۲: معیارهای پذیرش نهایی را بررسی کنید
در پایان، قبل از نهاییکردن Acceptance Criteria، یک Review کوتاه انجام دهید.
برای هر معیار بپرسید:
- آیا واضح است؟
- آیا قابل تست است؟
- آیا با هدف User Story مرتبط است؟
- آیا نتیجه مورد انتظار را مشخص میکند؟
- آیا ابهام مهمی باقی مانده است؟
- آیا بیش از حد وارد جزئیات Implementation شده است؟
- آیا شرایط مهم منفی یا Boundaryها نادیده گرفته نشدهاند؟
اگر پاسخها مناسب باشند، Acceptance Criteria احتمالاً آماده ورود به فرایند توسعه و تست است.
یک مثال کامل از این فرایند
فرض کنیم User Story ما این باشد:
بهعنوان یک مشتری، میخواهم بتوانم سفارش خود را لغو کنم تا در صورت تغییر تصمیم، خرید خود را متوقف کنم.
بعد از بررسی Requirement، مشخص میشود:
- سفارش فقط قبل از ارسال قابل لغو است.
- سفارش پرداختشده پس از لغو باید وارد فرایند بازپرداخت شود.
- سفارش ارسالشده قابل لغو نیست.
حالا میتوان Acceptance Criteria را چنین نوشت:
Acceptance Criteria 1
اگر سفارش هنوز ارسال نشده باشد، کاربر باید بتواند آن را لغو کند.
Acceptance Criteria 2
پس از لغو موفق سفارش، وضعیت آن باید به «لغوشده» تغییر کند.
Acceptance Criteria 3
اگر سفارش قبلاً ارسال شده باشد، کاربر نباید بتواند آن را لغو کند.
Acceptance Criteria 4
در صورت لغو سفارش پرداختشده، مبلغ باید مطابق قوانین بازپرداخت به فرایند Refund منتقل شود.
اکنون Tester میتواند بر اساس این معیارها Test Scenario و Test Case طراحی کند.
نکته مهم: Acceptance Criteria حاصل یک گفتوگو است
یکی از بهترین نگاهها به Acceptance Criteria این است که آن را صرفاً یک لیست نوشتهشده توسط Product Owner ندانیم.
Acceptance Criteria میتواند نتیجه یک گفتوگوی مشترک بین افراد مختلف تیم باشد.
در این گفتوگو:
- Product Owner نیاز و ارزش کسبوکار را توضیح میدهد.
- Developer درباره امکان پیادهسازی و محدودیتهای فنی سؤال میکند.
- Tester درباره قابلیت تست، شرایط منفی، Edge Caseها و ابهامات سؤال میکند.
در نتیجه، Acceptance Criteria میتواند به یک توافق مشترک درباره رفتار مورد انتظار Feature تبدیل شود.
این رویکرد با فلسفه Agile نیز همراستاست؛ زیرا به جای اینکه Requirement صرفاً بهعنوان یک سند از یک بخش به بخش دیگر منتقل شود، افراد مختلف درباره آن گفتگو میکنند.
یک فرمول ساده برای به خاطر سپردن فرایند
میتوان فرایند نوشتن Acceptance Criteria را به شکل زیر خلاصه کرد:
- User Story را درک کن
- هدف و رفتار مورد انتظار را مشخص کن
- قوانین کسبوکار و محدودیتها را بررسی کن
- Happy Path را مشخص کن
- Negative Scenario و Edge Caseهای مهم را بررسی کن
- معیارهای واضح و قابل تست بنویس
- در صورت نیاز از Given / When / Then استفاده کن
- با تیم Review کن
- معیارهای نهایی را تأیید کن
این فرایند باعث میشود Acceptance Criteria از یک فهرست ساده به یک ابزار واقعی برای ایجاد Shared Understanding، توسعه و تست باکیفیتتر تبدیل شود.
Acceptance Criteria از دید Tester
Acceptance Criteria برای Tester فقط یک فهرست از مواردی نیست که باید در پایان توسعه بررسی شوند. Tester میتواند از همان زمان تعریف و Review معیارهای پذیرش، در شناسایی ابهامها، ریسکها و شرایط قابل تست مشارکت کند.
به همین دلیل، نقش Tester در Acceptance Criteria را میتوان در سه مرحله دید:
قبل از توسعه → هنگام طراحی تست → هنگام اجرای تست
۱. بررسی Acceptance Criteria قبل از شروع توسعه
یکی از بهترین زمانها برای مشارکت Tester، قبل از شروع توسعه Feature است.
Tester باید Acceptance Criteria را بخواند و از خود بپرسد:
«آیا اگر این Feature همین امروز در اختیار من قرار بگیرد، دقیقاً میدانم چه چیزهایی را باید بررسی کنم؟»
اگر پاسخ منفی باشد، احتمالاً هنوز ابهامهایی در Requirement وجود دارد.
برای مثال:
«کاربر باید بتواند فایل خود را آپلود کند.»
Tester میتواند سؤال کند:
- چه فرمتهایی مجاز هستند؟
- حداکثر حجم فایل چقدر است؟
- اگر فایل نامعتبر باشد چه اتفاقی میافتد؟
- آیا آپلود چند فایل همزمان مجاز است؟
- اگر اتصال قطع شود چه اتفاقی میافتد؟
- آیا کاربر مهمان نیز میتواند فایل آپلود کند؟
هدف Tester این نیست که تمام این موارد را الزاماً به Acceptance Criteria اضافه کند؛ بلکه باید مشخص شود کدامیک واقعاً بخشی از نیاز محصول هستند.
۲. بررسی قابل تست بودن معیارها
Tester باید بررسی کند که هر معیار پذیرش واقعاً قابل تست باشد.
برای مثال:
❌ «سیستم باید تجربه کاربری خوبی داشته باشد.»
این جمله بهتنهایی معیار مناسبی برای تست نیست.
اما اگر Requirement مشخص کند:
«کاربر باید بتواند فرایند ثبت سفارش را بدون واردکردن مجدد اطلاعات آدرس در یک مرحله تکمیل کند.»
اکنون میتوان یک سناریوی مشخص برای بررسی آن طراحی کرد.
بنابراین Tester باید نسبت به عباراتی مانند موارد زیر حساس باشد:
- مناسب
- سریع
- آسان
- کاربرپسند
- بهینه
- قابل اعتماد
- امن
این واژهها لزوماً اشتباه نیستند، اما اگر معیار مشخصی برای ارزیابی آنها وجود نداشته باشد، میتوانند باعث ابهام شوند.
۳. بررسی Happy Path و Negative Path
Tester نباید فقط سناریوی موفق را بررسی کند.
فرض کنید Acceptance Criteria این باشد:
«کاربر با واردکردن اطلاعات صحیح باید بتواند وارد حساب شود.»
این معیار Happy Path را مشخص میکند.
اما Tester باید بپرسد:
«در صورت واردکردن اطلاعات اشتباه چه اتفاقی باید بیفتد؟»
ممکن است Requirement دیگری برای این موضوع وجود داشته باشد، یا لازم باشد در Acceptance Criteria مشخص شود.
مواردی مانند:
- رمز عبور اشتباه
- ایمیل نامعتبر
- فیلد خالی
- حساب غیرفعال
- تعداد تلاش ناموفق
- کاربر بدون دسترسی
ممکن است بر اساس Business Rule یا Risk Analysis نیاز به تست داشته باشند.
۴. بررسی Boundaryها
Tester یکی از اعضای مهم تیم برای شناسایی Boundaryها است.
فرض کنید معیار پذیرش میگوید:
«رمز عبور باید بین ۸ تا ۲۰ کاراکتر باشد.»
Tester میتواند فوراً محدودههای مهم را شناسایی کند:
- ۷ کاراکتر → نامعتبر
- ۸ کاراکتر → معتبر
- ۹ کاراکتر → معتبر
- ۱۹ کاراکتر → معتبر
- ۲۰ کاراکتر → معتبر
- ۲۱ کاراکتر → نامعتبر
در اینجا Acceptance Criteria یک Requirement مشخص ایجاد کرده و Tester میتواند از آن برای استفاده از تکنیک Boundary Value Analysis استفاده کند.
۵. بررسی Edge Caseها
Edge Caseها شرایطی هستند که ممکن است در مسیرهای معمول کمتر اتفاق بیفتند، اما میتوانند رفتار سیستم را تحت تأثیر قرار دهند.
برای مثال:
«کاربر میتواند سفارش خود را لغو کند.»
Tester ممکن است درباره این موارد سؤال کند:
- اگر دو درخواست لغو همزمان ارسال شود چه میشود؟
- اگر سفارش درست در لحظه ارسال لغو شود چه اتفاقی میافتد؟
- اگر عملیات لغو با خطای شبکه مواجه شود چه میشود؟
- اگر کاربر صفحه را Refresh کند چه وضعیتی نمایش داده میشود؟
البته همه Edge Caseها الزاماً باید داخل Acceptance Criteria نوشته شوند.
Tester باید ابتدا بر اساس Risk، Business Impact و رفتار مورد انتظار سیستم تشخیص دهد کدام موارد اهمیت دارند.
۶. بررسی Testability
گاهی Requirement از نظر کسبوکار قابل فهم است، اما از نظر تستپذیری مشکلاتی دارد.
«پس از ثبت سفارش، سیستم باید اطلاعات سفارش را بهدرستی پردازش کند.»
Tester ممکن است بپرسد:
«بهدرستی یعنی چه؟»
آیا باید:
- Order ID ایجاد شود؟
- وضعیت سفارش تغییر کند؟
- مبلغ درست محاسبه شود؟
- موجودی کالا کم شود؟
- پیام تأیید نمایش داده شود؟
- Notification ارسال شود؟
Tester باید کمک کند این رفتارها به اندازهای مشخص شوند که بتوان آنها را ارزیابی کرد.
۷. بررسی Consistency
اگر چند Acceptance Criteria برای یک Feature وجود دارد، نباید با یکدیگر تناقض داشته باشند.
Criterion 1:
کاربر میتواند سفارش را تا قبل از ارسال لغو کند.
Criterion 2:
سفارش پس از ثبت، قابل لغو نیست.
این دو معیار با یکدیگر تناقض دارند.
Tester میتواند چنین تناقضهایی را زودتر شناسایی کند؛ پیش از اینکه Developer بر اساس Requirement اشتباه Feature را پیادهسازی کند.
۸. بررسی ارتباط Acceptance Criteria با Business Rules
گاهی Acceptance Criteria فقط رفتار ظاهری سیستم را بیان میکند، اما یک Business Rule مهم پشت آن وجود دارد.
«کاربر باید بتواند کد تخفیف را اعمال کند.»
Tester میتواند بررسی کند:
- آیا کد تاریخ انقضا دارد؟
- آیا فقط برای بعضی محصولات قابل استفاده است؟
- آیا حداقل مبلغ سفارش وجود دارد؟
- آیا هر کاربر فقط یک بار میتواند از آن استفاده کند؟
- آیا امکان استفاده همزمان چند کد وجود دارد؟
این سؤالات کمک میکنند مشخص شود Acceptance Criteria با Business Rules هماهنگ است.
۹. استفاده از Acceptance Criteria برای طراحی تست
پس از نهاییشدن معیارهای پذیرش، Tester میتواند از آنها بهعنوان یکی از ورودیهای طراحی تست استفاده کند.
برای مثال:
Acceptance Criteria:
اگر مبلغ سفارش حداقل ۵۰۰ هزار تومان باشد، ارسال رایگان اعمال شود.
Tester میتواند Test Scenarioهایی مانند اینها ایجاد کند:
| مبلغ سفارش | انتظار |
|---|---|
| ۴۹۹٬۹۹۹ | ارسال رایگان اعمال نشود |
| ۵۰۰٬۰۰۰ | ارسال رایگان اعمال شود |
| ۵۰۰٬۰۰۱ | ارسال رایگان اعمال شود |
سپس میتوان Test Caseهای دقیقتر را بر اساس شرایط سیستم طراحی کرد.
۱۰. Acceptance Criteria نباید Tester را محدود کند
یک اشتباه رایج این است که Tester تصور کند:
«هر چیزی که در Acceptance Criteria نوشته نشده، نباید تست شود.»
این دیدگاه درست نیست.
Acceptance Criteria یکی از منابع مهم برای طراحی تست است، اما تنها منبع نیست.
Tester ممکن است بر اساس موارد زیر Testهای دیگری نیز طراحی کند:
- Functional Requirements
- Non-functional Requirements
- Business Rules
- Risk
- Security Requirements
- Architecture
- تغییرات اخیر سیستم
- Defectهای قبلی
- تجربه و دانش Domain
برای مثال، ممکن است Acceptance Criteria مربوط به Login فقط ورود موفق و ناموفق را مشخص کند، اما Tester بر اساس ریسک امنیتی نیاز داشته باشد موارد دیگری را نیز بررسی کند.
Tester هنگام Review چه سؤالهایی بپرسد؟
درباره Requirement
- آیا دقیقاً میدانم Feature چه کاری باید انجام دهد؟
- آیا هدف Business مشخص است؟
- آیا Scope مشخص است؟
درباره شرایط پذیرش
- آیا هر Criterion واضح است؟
- آیا قابل تست است؟
- آیا میتوان Pass یا Fail بودن آن را مشخص کرد؟
- آیا معیارها با یکدیگر سازگار هستند؟
درباره سناریوها
- آیا Happy Path مشخص است؟
- آیا Negative Scenarioهای مهم مشخص هستند؟
- آیا Edge Caseهای مهم در نظر گرفته شدهاند؟
- آیا Boundaryهای مهم مشخص هستند؟
درباره کیفیت
- آیا Requirement بیش از حد وارد Implementation شده است؟
- آیا عبارت مبهمی وجود دارد؟
- آیا نیازهای مهم Non-functional نادیده گرفته شدهاند؟
- آیا Acceptance Criteria بیش از حد بزرگ و پیچیده شده است؟
یک نکته مهم برای حرفهایتر شدن Tester
نقش Tester در Acceptance Criteria فقط پیدا کردن «موارد قابل تست» نیست.
یک Tester باتجربه تلاش میکند Defect را قبل از اینکه وارد کد شود پیدا کند.
اگر Tester در مرحله Requirement متوجه شود که یک شرط مبهم است و آن را قبل از توسعه مشخص کند، در واقع از ایجاد یک Defect بالقوه جلوگیری کرده است.
مثلاً اگر Requirement میگوید:
«کاربر میتواند فایل تا حجم ۱۰ MB آپلود کند.»
Tester میپرسد:
«فایل دقیقاً ۱۰ MB مجاز است؟»
اگر این سؤال قبل از توسعه پاسخ داده شود، Developer و Tester هر دو یک انتظار مشخص خواهند داشت.
اما اگر این سؤال بعد از توسعه مطرح شود، ممکن است Developer یک رفتار و Tester رفتار دیگری را انتظار داشته باشند و در نهایت یک اختلاف Requirement به شکل Defect ظاهر شود.
بنابراین:
یکی از ارزشهای اصلی Tester در کار با Acceptance Criteria، کشف ابهامها و ریسکها قبل از اجرای تست است.
در بخش بعدی، سراغ یکی از مهمترین بخشهای این مقاله میرویم: تفاوت Acceptance Criteria با User Acceptance Testing (UAT) و بررسی میکنیم چرا این دو مفهوم با وجود شباهت اسمی، یکسان نیستند.
تفاوت Acceptance Criteria و User Acceptance Testing (UAT)
یکی از رایجترین اشتباهات در بحث Acceptance Criteria این است که آن را با User Acceptance Testing (UAT) یا تست پذیرش کاربر یکی بدانیم.
این دو مفهوم به یکدیگر ارتباط دارند، اما یکسان نیستند.
به زبان ساده:
Acceptance Criteria مشخص میکند یک Feature چه شرایطی باید داشته باشد تا قابل پذیرش باشد؛ UAT فرایندی از تست و ارزیابی است که بررسی میکند محصول یا Feature در شرایط واقعی مورد انتظار کاربر و کسبوکار قابل قبول است یا خیر.
بنابراین یکی بیشتر به شرایط پذیرش مربوط است و دیگری به فعالیت تست و ارزیابی پذیرش.
Acceptance Criteria چیست؟
Acceptance Criteria یا معیارهای پذیرش مجموعهای از شرایط مشخصی است که برای یک User Story، Feature یا Requirement تعریف میشود.
برای مثال:
User Story:
بهعنوان یک مشتری، میخواهم بتوانم سفارش خود را لغو کنم تا در صورت تغییر تصمیم، خرید خود را متوقف کنم.
Acceptance Criteria:
- سفارش قبل از ارسال قابل لغو باشد.
- پس از لغو، وضعیت سفارش به «لغوشده» تغییر کند.
- سفارش ارسالشده قابل لغو نباشد.
- در صورت پرداخت قبلی، بازپرداخت مطابق قوانین کسبوکار انجام شود.
در اینجا هنوز درباره اجرای تست صحبت نمیکنیم.
این موارد فقط مشخص میکنند Feature چه شرایطی باید داشته باشد.
User Acceptance Testing چیست؟
User Acceptance Testing (UAT) یا تست پذیرش کاربر فرایندی است که طی آن محصول یا Feature از دیدگاه کاربر، مشتری یا کسبوکار بررسی میشود تا مشخص شود آیا برای استفاده واقعی و رسیدن به هدف موردنظر قابل قبول است یا خیر.
در UAT سؤال اصلی این است:
آیا این محصول واقعاً نیاز کسبوکار و کاربر را برآورده میکند؟
برای مثال، در همان قابلیت لغو سفارش، در UAT ممکن است نماینده کسبوکار یا کاربران منتخب سناریوهای واقعی را اجرا کنند:
- یک سفارش ایجاد کنند.
- سفارش را تا مرحله موردنظر پیش ببرند.
- درخواست لغو بدهند.
- وضعیت سفارش را بررسی کنند.
- در صورت پرداخت، فرایند بازپرداخت را بررسی کنند.
سپس مشخص میشود آیا Feature برای پذیرش کسبوکار مناسب است یا خیر.
تفاوت اصلی در یک نگاه
| Acceptance Criteria | User Acceptance Testing |
|---|---|
| شرایط پذیرش را تعریف میکند | پذیرش Feature یا محصول را ارزیابی میکند |
| یک Requirement یا User Story را توصیف میکند | یک فعالیت یا فرایند تست است |
| معمولاً قبل از توسعه یا در طول Refinement تعریف میشود | معمولاً پس از آمادهشدن Feature یا محصول انجام میشود |
| مشخص میکند «چه چیزی باید برقرار باشد» | بررسی میکند «آیا واقعاً قابل قبول است؟» |
| میتواند توسط Product Owner، Business Analyst، تیم و سایر افراد مرتبط تعریف شود | معمولاً با مشارکت Business User، Customer یا نماینده کسبوکار انجام میشود |
| میتواند ورودی طراحی تست باشد | یکی از مراحل ارزیابی نهایی محصول است |
رابطه Acceptance Criteria و UAT
این دو مفهوم از یکدیگر جدا هستند، اما میتوانند ارتباط نزدیکی داشته باشند.
میتوان رابطه آنها را به شکل زیر تصور کرد:
Business Requirement
↓
User Story
↓
Acceptance Criteria
↓
Development
↓
Testing
↓
User Acceptance Testing
در این فرایند، Acceptance Criteria میتواند به عنوان یکی از ورودیهای مهم برای طراحی UAT استفاده شود.
برای مثال:
Acceptance Criteria:
سفارش قبل از ارسال باید قابل لغو باشد.
در UAT میتوان سناریویی طراحی کرد که یک کاربر واقعی یا نماینده کسبوکار سفارش را قبل از ارسال لغو کند و بررسی کند که رفتار سیستم با انتظار کسبوکار مطابقت دارد.
آیا UAT همان تست Acceptance Criteria است؟
نه دقیقاً.
ممکن است در UAT برخی از Acceptance Criteria بررسی شوند، اما UAT فقط به اجرای آنها محدود نمیشود.
فرض کنید تمام Acceptance Criteria زیر Pass شدهاند:
- سفارش قابل لغو است.
- وضعیت سفارش تغییر میکند.
- پیام مناسب نمایش داده میشود.
- بازپرداخت انجام میشود.
اما در UAT مشخص شود که فرایند لغو سفارش برای کاربران واقعی بسیار پیچیده است یا با فرایند کاری سازمان سازگاری ندارد.
در این حالت ممکن است Feature از نظر Acceptance Criteria موفق باشد، اما هنوز از دید کسبوکار برای پذیرش نهایی مناسب نباشد.
این مثال نشان میدهد UAT میتواند نگاه گستردهتری نسبت به صرفاً بررسی Acceptance Criteria داشته باشد.
آیا Tester انجامدهنده UAT است؟
لزوماً نه.
در بسیاری از تیمها Tester در آمادهسازی، هماهنگی یا اجرای بخشی از UAT مشارکت میکند، اما مالک اصلی پذیرش کسبوکار معمولاً Business یا نماینده Customer است.
برای مثال:
- Tester: محیط و داده تست را آماده میکند و به اجرای سناریوها کمک میکند.
- Product Owner: بررسی میکند Feature با نیاز محصول مطابقت دارد.
- Business User: قابلیت را از دید فرایند واقعی کسبوکار ارزیابی میکند.
- Customer: در صورت نیاز محصول را از دید استفاده واقعی بررسی میکند.
بنابراین نباید این تصور ایجاد شود که:
«چون Tester Acceptance Criteria را تست کرده، پس UAT هم انجام شده است.»
این دو فعالیت میتوانند همپوشانی داشته باشند، اما هدف و مسئولیت یکسانی ندارند.
یک مثال سادهتر
فرض کنید یک رستوران سیستم سفارش آنلاین خود را توسعه داده است.
Acceptance Criteria
برای Feature «ثبت سفارش»:
- کاربر باید بتواند محصول را به سبد خرید اضافه کند.
- کاربر باید بتواند آدرس تحویل را وارد کند.
- مبلغ نهایی باید صحیح محاسبه شود.
- پس از پرداخت موفق، سفارش باید ثبت شود.
- شماره سفارش باید نمایش داده شود.
اینها شرایط پذیرش Feature هستند.
UAT
حالا نماینده رستوران با یک سناریوی واقعی وارد سیستم میشود:
«میخواهم یک سفارش واقعی برای مشتری ثبت کنم، آدرس را وارد کنم، هزینه را ببینم، پرداخت را انجام دهم و مطمئن شوم سفارش در سیستم رستوران دریافت شده است.»
در اینجا هدف فقط بررسی تکتک Acceptance Criteria نیست؛ بلکه بررسی میشود:
آیا این قابلیت در فرایند واقعی کسبوکار قابل استفاده است؟
تفاوت Acceptance Testing و UAT
یک نکته دیگر نیز باید در نظر گرفته شود.
Acceptance Testing مفهومی گستردهتر از UAT است.
Acceptance Testing میتواند به روشهای مختلفی انجام شود و هدف آن بررسی پذیرش سیستم بر اساس معیارهای تعریفشده باشد.
اما UAT مشخصاً روی پذیرش از دید User یا Business تمرکز دارد.
بنابراین میتوان گفت:
UAT یکی از شکلهای Acceptance Testing است که تمرکز آن بر نیاز و پذیرش کاربر یا کسبوکار است.
البته در پروژههای مختلف ممکن است اصطلاحات Acceptance Testing، Business Acceptance Testing و UAT با تعاریف یا مرزبندیهای کمی متفاوت استفاده شوند؛ بنابراین همیشه باید اصطلاحات مورد توافق همان پروژه را نیز در نظر گرفت.
یک اشتباه رایج
گاهی گفته میشود:
«Acceptance Criteria همان Test Caseهایی هستند که در UAT اجرا میشوند.»
این عبارت دقیق نیست.
Acceptance Criteria شرایط پذیرش هستند.
Test Case روش مشخص بررسی یک رفتار است.
UAT فرایند ارزیابی پذیرش توسط کاربر یا کسبوکار است.
برای مثال:
Acceptance Criteria:
سفارش قبل از ارسال باید قابل لغو باشد.
Test Case:
یک سفارش ارسالنشده ایجاد کنید و گزینه لغو را انتخاب کنید.
UAT:
نماینده کسبوکار سناریوی واقعی لغو یک سفارش را اجرا میکند و تأیید میکند که فرایند لغو و پیامدهای آن با فرایند کسبوکار مطابقت دارد.
پس این سه مفهوم را نباید با یکدیگر یکی دانست.
خلاصه تفاوت
اگر بخواهیم کل بحث را در سه سؤال خلاصه کنیم:
Acceptance Criteria میپرسد:
چه شرایطی باید برقرار باشد تا Feature قابل پذیرش باشد؟
Test Case میپرسد:
چگونه این شرط را بررسی کنیم؟
UAT میپرسد:
آیا این Feature در شرایط واقعی برای کاربر یا کسبوکار قابل قبول است؟
این تفکیک برای Tester بسیار مهم است، زیرا نشان میدهد Acceptance Criteria، Test Case و UAT سه مفهوم متفاوت در مسیر رسیدن از Requirement به پذیرش محصول هستند.
در بخش بعدی، به سراغ یک موضوع کاربردی میرویم: رابطه Acceptance Criteria با Acceptance Testing و انواع تست پذیرش و بررسی میکنیم که Acceptance Criteria در چه نوع تستهایی میتواند مورد استفاده قرار گیرد.
Acceptance Criteria و Acceptance Testing
تا اینجا دیدیم که Acceptance Criteria (معیارهای پذیرش) مشخص میکند یک Feature یا Product Backlog Item برای پذیرفتهشدن چه شرایطی باید داشته باشد و Acceptance Testing (تست پذیرش) فرایندی است که بررسی میکند آیا این شرایط و سایر نیازهای مرتبط واقعاً برآورده شدهاند یا خیر.
در تعریف ISTQB، Acceptance Criteria شرایطی هستند که یک Component یا System برای پذیرفتهشدن باید برآورده کند. Acceptance Testing نیز تستی است که با توجه به نیازهای کاربر، Requirements و فرایندهای کسبوکار انجام میشود تا مشخص شود سیستم معیارهای پذیرش را برآورده میکند یا خیر.
رابطه Acceptance Criteria و Acceptance Testing
میتوان رابطه این دو را بسیار ساده در نظر گرفت:
Acceptance Criteria
چه شرایطی باید برقرار باشد؟
⬇️
Acceptance Testing
آیا این شرایط واقعاً برقرار هستند؟
برای مثال، فرض کنید Acceptance Criteria یک فروشگاه اینترنتی چنین باشد:
«اگر مبلغ سفارش حداقل ۵۰۰ هزار تومان باشد، هزینه ارسال باید رایگان شود.»
در Acceptance Testing میتوان سناریوهایی را اجرا کرد تا بررسی شود:
- سفارش کمتر از ۵۰۰ هزار تومان → ارسال رایگان نباشد.
- سفارش دقیقاً ۵۰۰ هزار تومان → ارسال رایگان باشد.
- سفارش بیشتر از ۵۰۰ هزار تومان → ارسال رایگان باشد.
در اینجا Acceptance Criteria، انتظار را مشخص کرده و Acceptance Testing، برآوردهشدن آن انتظار را بررسی میکند.
Acceptance Testing فقط بررسی Acceptance Criteria نیست
یک نکته مهم این است که Acceptance Testing را نباید صرفاً به اجرای Acceptance Criteria محدود کنیم.
طبق تعریف ISTQB، Acceptance Testing با User Needs، Requirements و Business Processes نیز ارتباط دارد. بنابراین ممکن است در Acceptance Testing علاوه بر معیارهای پذیرش یک Feature، بررسی شود که سیستم در یک فرایند واقعی کسبوکار نیز رفتار مورد انتظار را دارد.
برای مثال ممکن است Acceptance Criteria مربوط به یک قابلیت پرداخت کاملاً Pass شود، اما در Acceptance Testing مشخص شود که فرایند کلی پرداخت با روش کاری سازمان سازگار نیست.
Acceptance Criteria میتواند یکی از مبناهای Acceptance Testing باشد، اما لزوماً تمام دامنه Acceptance Testing را تشکیل نمیدهد.
Acceptance Criteria چه کمکی به Acceptance Testing میکند؟
وجود معیارهای پذیرش مشخص باعث میشود Acceptance Testing هدف روشنتری داشته باشد.
بدون Acceptance Criteria ممکن است تیم هنگام تست با این سؤال مواجه شود:
«از کجا بدانیم این Feature قابل قبول است؟»
اما وقتی معیارها مشخص باشند، میتوان آنها را به Expected Result و سناریوهای تست مرتبط کرد.
Acceptance Criteria:
کاربر باید پس از پرداخت موفق، شماره سفارش دریافت کند.
Acceptance Test:
یک سفارش واقعی یا سناریوی مشابه را ثبت و پرداخت کنید و بررسی کنید که شماره سفارش نمایش داده میشود.
در نتیجه، معیار پذیرش میتواند به ایجاد یک معیار عینیتر برای پذیرش کمک کند.
Acceptance Testing در کجای فرایند قرار میگیرد؟
بسته به روش توسعه و فرایند سازمان، Acceptance Testing میتواند در نقاط مختلف چرخه توسعه انجام شود؛ اما معمولاً زمانی انجام میشود که سیستم یا Feature به اندازه کافی آماده ارزیابی باشد.
یک مسیر ساده میتواند اینگونه باشد:
Requirement
↓
Acceptance Criteria
↓
Development
↓
Functional / System Testing
↓
Acceptance Testing
↓
Acceptance Decision
↓
Release
البته این نمودار نباید به این معنا برداشت شود که Acceptance Testing همیشه یک مرحله کاملاً جدا و فقط در پایان پروژه است. در روشهای Agile، فعالیتهای مرتبط با پذیرش میتوانند در طول توسعه و در سطح هر Feature نیز انجام شوند.
Acceptance Criteria و Acceptance Test Case
این دو نیز نباید با یکدیگر اشتباه گرفته شوند.
Acceptance Criteria:
کاربر باید بتواند سفارش پرداختشده را قبل از ارسال لغو کند.
Acceptance Test Case:
یک سفارش پرداختشده و ارسالنشده ایجاد کنید، گزینه لغو را انتخاب کنید و بررسی کنید که سفارش لغو شده و فرایند بازپرداخت آغاز شود.
در این مثال:
- Acceptance Criteria → شرط پذیرش
- Acceptance Test Case → روش مشخص برای بررسی شرط
بنابراین Acceptance Criteria الزاماً Test Case نیست.
جایگاه UAT در این میان
همانطور که در بخش قبل گفتیم، User Acceptance Testing (UAT) یکی از انواع Acceptance Testing است که تمرکز آن بر پذیرش سیستم از دید کاربران موردنظر است. ISTQB نیز UAT را نوعی Acceptance Testing میداند که برای تعیین پذیرش سیستم توسط کاربران موردنظر انجام میشود.
پس میتوان رابطه را اینگونه خلاصه کرد:
- Acceptance Criteria → شرایط پذیرش را مشخص میکند.
- Acceptance Testing → بررسی میکند سیستم قابل پذیرش است یا خیر.
- UAT → پذیرش سیستم را از دید کاربران موردنظر بررسی میکند.
این تفکیک کمک میکند سه مفهوم متفاوت را با یکدیگر اشتباه نگیریم.
یک نکته مهم درباره Scrum
Acceptance Criteria یک Practice رایج در تیمهای Agile و Scrum است، اما جزو Artifact یا Commitment رسمی Scrum نیست. در مقابل، Definition of Done در Scrum جایگاه رسمی دارد و معیارهای کیفیتی لازم برای Done بودن Increment را مشخص میکند.
بنابراین بهتر است در مقاله از عبارتهایی مانند:
«در Scrum باید برای هر User Story حتماً Acceptance Criteria نوشته شود»
با احتیاط استفاده کنیم.
بیان دقیقتر این است:
Acceptance Criteria یک Practice رایج و مفید برای شفافکردن شرایط پذیرش Product Backlog Itemها در تیمهای Agile است.
جمعبندی
اگر بخواهیم این بخش را در یک جمله خلاصه کنیم:
Acceptance Criteria مشخص میکند چه چیزی باید برای پذیرش برقرار باشد؛ Acceptance Testing بررسی میکند آیا آن شرایط و نیازهای مرتبط واقعاً برآورده شدهاند؛ و UAT پذیرش سیستم را از دید کاربران موردنظر ارزیابی میکند.
این سه مفهوم به هم مرتبط هستند، اما نباید بهعنوان یک مفهوم واحد استفاده شوند.
Acceptance Criteria در یک پروژه واقعی؛ از Requirement تا Release
تا اینجا Acceptance Criteria را از جنبههای مختلف بررسی کردیم. حالا بهتر است همه این مفاهیم را در یک جریان واقعی کنار هم قرار دهیم تا ببینیم معیارهای پذیرش از زمان تعریف نیازمندی تا پذیرش و Release یک Feature چه نقشی دارند.
برای این مثال، یک فروشگاه اینترنتی را در نظر میگیریم.
مرحله ۱: تعریف نیاز کسبوکار
کسبوکار متوجه شده است که بسیاری از کاربران بعد از ثبت سفارش، به دلایل مختلف نیاز دارند سفارش خود را لغو کنند.
بنابراین نیاز کسبوکار به شکل ساده چنین بیان میشود:
«مشتری باید بتواند در شرایط مجاز سفارش خود را لغو کند.»
این جمله هنوز برای توسعه و تست کافی نیست.
مشخص نیست:
- چه سفارشهایی قابل لغو هستند؟
- تا چه زمانی امکان لغو وجود دارد؟
- بعد از لغو چه اتفاقی میافتد؟
- اگر سفارش پرداخت شده باشد چه میشود؟
- اگر سفارش ارسال شده باشد چه میشود؟
مرحله ۲: تبدیل Requirement به User Story
این نیاز میتواند به شکل User Story بیان شود:
بهعنوان یک مشتری، میخواهم بتوانم سفارش خود را لغو کنم تا در صورت تغییر تصمیم، بتوانم خرید خود را متوقف کنم.
حالا هدف کاربر مشخصتر شده است، اما هنوز شرایط پذیرش Feature مشخص نیست.
مرحله ۳: تعریف Acceptance Criteria
تیم در جلسه Refinement درباره این User Story گفتگو میکند.
Product Owner قوانین کسبوکار را توضیح میدهد و Tester درباره شرایط مختلف و ابهامهای احتمالی سؤال میکند.
در نهایت Acceptance Criteria میتواند چنین باشد:
- سفارش قبل از ارسال باید قابل لغو باشد.
- سفارش ارسالشده نباید قابل لغو باشد.
- پس از لغو موفق، وضعیت سفارش باید به «لغوشده» تغییر کند.
- اگر سفارش قبلاً پرداخت شده باشد، باید فرایند بازپرداخت آغاز شود.
- پس از لغو موفق، پیام مناسب به کاربر نمایش داده شود.
در این مرحله یک Shared Understanding بین اعضای تیم شکل گرفته است.
این موضوع اهمیت زیادی دارد؛ زیرا Acceptance Criteria صرفاً یک فهرست برای Tester نیست، بلکه میتواند مبنایی مشترک برای Product Owner، Developer و Tester باشد.
مرحله ۴: بررسی Acceptance Criteria قبل از توسعه
قبل از شروع Development، Tester معیارها را Review میکند.
مثلاً میپرسد:
«اگر سفارش دقیقاً در لحظهای که در حال ارسال است لغو شود چه اتفاقی میافتد؟»
یا:
«اگر فرایند Refund با خطا مواجه شود، وضعیت سفارش چه خواهد بود؟»
یا:
«آیا کاربر بعد از لغو باید Notification دریافت کند؟»
ممکن است بعضی از این موارد واقعاً جزو Scope Feature نباشند.
اما همین سؤالها کمک میکنند تیم بفهمد کدام رفتارها نیاز به تصمیمگیری دارند.
در واقع Tester میتواند قبل از نوشتهشدن کد، ابهام Requirement را شناسایی کند.
مرحله ۵: توسعه Feature
Developer بر اساس User Story و Acceptance Criteria، Feature را پیادهسازی میکند.
در این مرحله Acceptance Criteria یک مرجع مشترک برای رفتار مورد انتظار Feature است.
برای مثال Developer میداند:
اگر سفارش ارسال نشده باشد، امکان Cancel باید وجود داشته باشد.
و میداند:
اگر سفارش ارسال شده باشد، نباید امکان Cancel وجود داشته باشد.
مرحله ۶: طراحی تست
حالا Tester میتواند بر اساس Acceptance Criteria، Test Scenario و Test Case طراحی کند.
Acceptance Criteria:
سفارش قبل از ارسال باید قابل لغو باشد.
Test Scenario:
لغو یک سفارش ارسالنشده.
Test Case:
- ایجاد سفارش
- اطمینان از اینکه سفارش ارسال نشده است
- ورود به جزئیات سفارش
- انتخاب گزینه لغو
- تأیید لغو
Expected Result:
سفارش با موفقیت لغو شده و وضعیت آن به «لغوشده» تغییر کند.
مرحله ۷: تست شرایط منفی
Tester فقط Happy Path را بررسی نمیکند.
برای مثال:
Acceptance Criteria:
سفارش ارسالشده نباید قابل لغو باشد.
Test Case:
- یک سفارش ایجاد کنید.
- وضعیت سفارش را به حالت ارسالشده برسانید.
- صفحه جزئیات سفارش را باز کنید.
- گزینههای قابل انجام را بررسی کنید.
Expected Result:
گزینه لغو سفارش نباید در دسترس کاربر باشد یا سیستم باید از لغو سفارش جلوگیری کند.
مرحله ۸: اجرای Acceptance Testing
پس از آمادهشدن Feature، Acceptance Testing انجام میشود.
در این مرحله بررسی میشود که آیا سیستم با نیازهای کاربر، Requirements، Business Processها و Acceptance Criteria مطابقت دارد یا خیر. این همان ارتباطی است که ISTQB بین Acceptance Testing و Acceptance Criteria، User Needs و Business Processes بیان میکند.
ممکن است Testهای قبلی توسط Tester انجام شده باشند، اما در Acceptance Testing سؤال اصلی این است:
آیا Feature از دید پذیرش محصول و کسبوکار آماده است؟
مرحله ۹: User Acceptance Testing
در صورت وجود فرایند UAT، کاربر یا نماینده کسبوکار نیز سناریوهای واقعی را بررسی میکند.
برای مثال نماینده کسبوکار ممکن است سناریوی زیر را اجرا کند:
«یک سفارش پرداختشده را قبل از ارسال لغو میکنم و بررسی میکنم که سفارش لغو شده و مبلغ آن وارد فرایند بازپرداخت شود.»
در این مرحله، تمرکز بیشتر روی قابلقبولبودن Feature از دید کاربر و کسبوکار است.
طبق تعریف ISTQB، UAT نوعی Acceptance Testing است که برای تعیین پذیرش سیستم توسط کاربران موردنظر انجام میشود.
مرحله ۱۰: تصمیم برای Release
پس از تکمیل تستها و پذیرش موردنیاز، Stakeholderهای مسئول میتوانند درباره Release تصمیم بگیرند.
در اینجا ممکن است اطلاعات مختلفی در تصمیمگیری نقش داشته باشند:
- Acceptance Criteria
- نتایج Functional Testing
- نتایج Non-functional Testing
- Defectها
- Riskها
- نتایج Acceptance Testing
- نتیجه UAT
- Definition of Done
- سایر Release Criteriaهای سازمان
بنابراین Acceptance Criteria بهتنهایی تصمیم Release را تعیین نمیکند، اما یکی از ورودیهای مهم برای ارزیابی آمادگی Feature است.
کل فرایند در یک نگاه
میتوانیم مثال خودمان را اینگونه خلاصه کنیم:
Business Need
↓
User Story
↓
Acceptance Criteria
↓
Requirement Review
↓
Development
↓
Test Design
↓
Functional / Non-functional Testing
↓
Acceptance Testing
↓
UAT در صورت نیاز
↓
Acceptance Decision
↓
Release
این جریان نشان میدهد Acceptance Criteria در یک نقطه خاص از پروژه قرار ندارد؛ بلکه میتواند از زمان تعریف Requirement تا ارزیابی نهایی Feature مورد استفاده قرار گیرد.
نکته مهم: Acceptance Criteria یک سند ثابت و جدا از محصول نیست
در پروژههای Agile ممکن است Acceptance Criteria در طول گفتگوهای تیم تکامل پیدا کند.
مثلاً در ابتدا گفته شود:
«سفارش قبل از ارسال قابل لغو است.»
اما در Refinement مشخص شود که:
«سفارش فقط تا قبل از ورود به مرحله آمادهسازی قابل لغو است.»
در چنین شرایطی Acceptance Criteria میتواند بر اساس تصمیم کسبوکار اصلاح شود.
نکته مهم این است که تغییر معیار پذیرش باید آگاهانه و هماهنگ با افراد مسئول Requirement انجام شود، نه اینکه صرفاً برای Pass شدن یک تست تغییر کند.
نقش Acceptance Criteria در پیشگیری از Defect
یکی از ارزشمندترین جنبههای Acceptance Criteria این است که میتواند به کشف مشکلات قبل از مرحله Coding کمک کند.
فرض کنید Tester در زمان Refinement متوجه شود که مشخص نیست سفارش دقیقاً تا چه زمانی قابل لغو است.
اگر این ابهام قبل از توسعه برطرف شود، احتمال اینکه Developer و Tester برداشت متفاوتی داشته باشند کمتر خواهد شد.
Acceptance Criteria فقط ابزاری برای تشخیص درست یا غلط بودن Feature نیست؛ میتواند ابزاری برای جلوگیری از ایجاد برخی Defectها نیز باشد.
این موضوع یکی از دلایلی است که ISTQB در مسیر آموزشی Acceptance Testing نیز روی مشارکت Tester در تعریف Acceptance Criteria و همکاری با Business Analyst و سایر Stakeholderها تأکید میکند.
جمعبندی مثال
در مثال لغو سفارش، Acceptance Criteria به ما کمک کرد از یک جمله کلی:
«کاربر باید بتواند سفارش خود را لغو کند.»
به مجموعهای از انتظارات مشخص برسیم:
«چه زمانی؟»
«تحت چه شرایطی؟»
«با چه نتیجهای؟»
«در شرایط نامعتبر چه اتفاقی میافتد؟»
و سپس همین معیارها به Test Scenario، Test Case و در ادامه Acceptance Testing و UAT مرتبط شدند.
Acceptance Criteria پلی بین نیازمندی و پذیرش Feature است.
این مفهوم بهتنهایی جای Requirement، Test Case، Acceptance Testing یا UAT را نمیگیرد؛ بلکه کمک میکند ارتباط میان این بخشها شفافتر شود.
چکلیست نهایی Acceptance Criteria برای Tester
تا اینجا دیدیم که Tester میتواند از مرحله تعریف Requirement تا Acceptance Testing درگیر Acceptance Criteria باشد. حالا میتوانیم تمام نکات را به یک چکلیست عملی (Practical Checklist) تبدیل کنیم.
این چکلیست میتواند هنگام Backlog Refinement، Sprint Planning، Requirement Review یا Test Planning مورد استفاده قرار گیرد.
۱. بررسی ارتباط با User Story
ابتدا بررسی کنید که هر Acceptance Criteria واقعاً به User Story مربوط باشد.
از خودتان بپرسید:
- آیا این معیار به هدف User Story مرتبط است؟
- آیا ارزش مورد انتظار کاربر را پوشش میدهد؟
- آیا معیار اضافی و غیرضروری وجود دارد؟
- آیا چیزی خارج از Scope وارد معیارها شده است؟
برای مثال اگر User Story درباره لغو سفارش است، معیارهایی درباره تغییر اطلاعات پروفایل کاربر احتمالاً ارتباطی با آن ندارد.
۲. بررسی وضوح (Clarity)
هر معیار باید تا حد امکان واضح و بدون ابهام باشد.
به کلماتی مانند اینها توجه کنید:
- سریع
- آسان
- مناسب
- بهینه
- قابل قبول
- کاربرپسند
- امن
- عملکرد خوب
اگر چنین عبارتی استفاده شده، بپرسید:
«معیار مشخص و قابل اندازهگیری آن چیست؟»
برای مثال:
❌ «صفحه باید سریع باز شود.»
✅ «صفحه باید حداکثر طی ۲ ثانیه پس از درخواست کاربر نمایش داده شود.»
۳. بررسی Testability
برای هر معیار این سؤال را مطرح کنید:
آیا میتوانم بر اساس این معیار یک تست طراحی کنم و Pass یا Fail بودن آن را مشخص کنم؟
اگر پاسخ منفی است، احتمالاً Criterion به اندازه کافی مشخص نیست.
۴. بررسی Expected Result
هر Acceptance Criteria باید مشخص کند که چه نتیجهای انتظار میرود.
برای مثال:
❌ «کاربر رمز عبور اشتباه وارد میکند.»
این فقط یک شرایط را توصیف میکند.
اما:
✅ «اگر کاربر رمز عبور اشتباه وارد کند، سیستم نباید اجازه ورود بدهد و باید پیام خطای مناسب نمایش دهد.»
در اینجا رفتار مورد انتظار مشخص شده است.
۵. بررسی Happy Path
مطمئن شوید سناریوی اصلی و موفق Feature مشخص شده است.
مثلاً برای پرداخت:
کاربر اطلاعات معتبر وارد میکند → پرداخت موفق انجام میشود → سفارش ثبت میشود.
اگر حتی مسیر اصلی Feature مشخص نباشد، طراحی تست نیز دشوار خواهد شد.
۶. بررسی Negative Scenario
فقط به مسیر موفق فکر نکنید.
بررسی کنید آیا شرایط مهم ناموفق نیز مشخص شدهاند.
- اطلاعات نامعتبر
- اطلاعات ناقص
- دسترسی غیرمجاز
- موجودی ناکافی
- خطای سرویس
- Timeout
- عملیات تکراری
البته قرار نیست تمام حالتهای ممکن وارد Acceptance Criteria شوند؛ تمرکز روی رفتارهای مهم و مورد انتظار کسبوکار است.
۷. بررسی Boundaryها
اگر Requirement محدودیت دارد، Boundary آن را بررسی کنید.
برای مثال:
«حداکثر حجم فایل ۱۰MB است.»
سؤالات مهم:
- ۹.۹MB؟
- دقیقاً ۱۰MB؟
- ۱۰.۱MB؟
- فایل صفر بایتی؟
- فایل خالی؟
این موارد میتوانند بعداً مستقیماً به Test Case تبدیل شوند.
۸. بررسی Business Rules
بررسی کنید آیا قوانین مهم کسبوکار در Acceptance Criteria لحاظ شدهاند.
برای مثال در سیستم تخفیف:
- حداقل مبلغ خرید
- تاریخ اعتبار
- تعداد دفعات استفاده
- محصولات مشمول تخفیف
- امکان استفاده همزمان چند تخفیف
عدم توجه به Business Rules میتواند باعث شود Feature از نظر فنی درست باشد اما از نظر کسبوکار اشتباه عمل کند.
۹. بررسی Edge Caseها
از خودتان بپرسید:
«در چه شرایط غیرمعمولی ممکن است رفتار سیستم متفاوت شود؟»
مثلاً:
- درخواست همزمان
- Refresh کردن صفحه
- قطع اتصال
- دوبار کلیک کردن
- تغییر وضعیت همزمان توسط کاربر دیگر
- منقضیشدن Session
هر Edge Caseی لازم نیست Acceptance Criteria شود؛ فقط موارد مهم را شناسایی کنید.
۱۰. بررسی عدم ورود بیش از حد به Implementation
Acceptance Criteria بهتر است What را مشخص کند، نه الزاماً How را.
❌ «سیستم باید دادهها را در جدول Users در PostgreSQL ذخیره کند.»
اگر نوع دیتابیس الزام کسبوکار نیست، این معیار بیش از حد وارد Implementation شده است.
✅ «پس از ثبت موفقنام، اطلاعات حساب کاربر باید برای ورودهای بعدی در دسترس باشد.»
۱۱. بررسی عدم تبدیل Acceptance Criteria به Test Steps
Acceptance Criteria نباید تبدیل به Test Case شود.
❌ «به صفحه Login بروید، ایمیل را وارد کنید، رمز را وارد کنید و روی Login کلیک کنید.»
این بیشتر شبیه Test Steps است.
✅ «کاربر با اطلاعات معتبر باید بتواند وارد حساب کاربری خود شود.»
جزئیات اجرای تست میتواند در Test Case قرار گیرد.
۱۲. بررسی Consistency
Acceptance Criteriaها را در کنار یکدیگر بخوانید.
آیا با هم تناقض دارند؟
مثلاً:
«کاربر میتواند سفارش را تا قبل از ارسال لغو کند.»
و:
«پس از ثبت سفارش امکان لغو وجود ندارد.»
چنین تناقضی باید قبل از توسعه برطرف شود.
۱۳. بررسی وابستگیها
گاهی یک Acceptance Criteria به Feature یا سرویس دیگری وابسته است.
مثلاً:
«پس از پرداخت موفق، سفارش باید ثبت شود.»
در اینجا ممکن است سیستم به Payment Service یا سرویس دیگری وابسته باشد.
Tester باید بررسی کند آیا این Dependency روی تست و پذیرش Feature تأثیر دارد یا خیر.
۱۴. بررسی Non-functional Requirements
Acceptance Criteria همیشه فقط درباره Functional Behavior نیست.
در صورت مرتبطبودن با Feature، ممکن است معیارهایی درباره موارد زیر نیز لازم باشد:
- Performance
- Security
- Accessibility
- Compatibility
- Reliability
- Usability
مثلاً:
«نتایج جستوجو باید حداکثر طی ۲ ثانیه نمایش داده شوند.»
این یک معیار مرتبط با Performance است.
بنابراین Tester نباید فقط به Functional Acceptance Criteria توجه کند.
چکلیست سریع برای استفاده در پروژه
اگر بخواهیم تمام موارد را به یک چکلیست کوتاه تبدیل کنیم، Tester میتواند قبل از شروع Development این موارد را بررسی کند:
- ☐ با User Story مرتبط است؟
- ☐ واضح و بدون ابهام است؟
- ☐ قابل تست است؟
- ☐ Expected Result مشخص است؟
- ☐ Happy Path مشخص است؟
- ☐ Negative Scenarioهای مهم بررسی شدهاند؟
- ☐ Boundaryهای مهم مشخص هستند؟
- ☐ Business Ruleهای مرتبط پوشش داده شدهاند؟
- ☐ Edge Caseهای مهم بررسی شدهاند؟
- ☐ بیش از حد وارد Implementation نشده است؟
- ☐ با Test Case اشتباه نشده است؟
- ☐ با سایر Acceptance Criteria تناقض ندارد؟
- ☐ Dependencyهای مهم مشخص هستند؟
- ☐ در صورت نیاز Non-functional Requirements نیز در نظر گرفته شدهاند؟
آیا اگر همه موارد تیک بخورند، Acceptance Criteria عالی است؟
نه لزوماً.
این چکلیست یک راهنما است، نه یک قانون سخت.
برای یک User Story ساده ممکن است فقط چند معیار کوتاه لازم باشد.
در مقابل، برای یک Feature پیچیده مانند پرداخت آنلاین، معیارهای پذیرش میتوانند شامل سناریوهای متعدد، Business Ruleها، شرایط منفی و الزامات Non-functional باشند.
بنابراین هدف این نیست که همیشه تعداد زیادی Acceptance Criteria ایجاد کنیم.
هدف این است که:
به اندازه کافی جزئیات داشته باشیم تا تیم درباره رفتار مورد انتظار Feature برداشت مشترکی داشته باشد و بتواند پذیرش آن را به شکل قابل اتکا ارزیابی کند.
یک قانون ساده برای Tester
اگر بخواهیم کل این چکلیست را در یک سؤال خلاصه کنیم، Tester میتواند بپرسد:
«آیا این Acceptance Criteria آنقدر واضح است که Product Owner، Developer و Tester بتوانند درباره نتیجه مورد انتظار یک برداشت مشترک داشته باشند؟»
اگر پاسخ مثبت باشد، احتمالاً Criterion مسیر خوبی را طی کرده است.
و اگر پاسخ منفی باشد، بهتر است قبل از شروع توسعه درباره آن صحبت شود.
این همان جایی است که Tester از یک Test Executor صرف فراتر میرود و در Quality Assurance و پیشگیری از Defect نقش فعالتری پیدا میکند.
جمعبندی Acceptance Criteria
Acceptance Criteria یا معیارهای پذیرش یکی از ابزارهای مهم برای ایجاد درک مشترک درباره رفتار مورد انتظار یک Feature یا User Story است.
این معیارها مشخص میکنند که یک قابلیت تحت چه شرایطی باید قابل قبول باشد و کمک میکنند Product Owner، Business Analyst، Developer و Tester درباره نتیجه مورد انتظار برداشت مشترکی داشته باشند.
Acceptance Criteria را نباید صرفاً یک چکلیست برای Tester در نظر گرفت. این معیارها از همان مرحله تعریف و بررسی Requirement میتوانند به تیم کمک کنند تا ابهامها، قوانین کسبوکار و شرایط مهم Feature را شناسایی کند.
Acceptance Criteria چه چیزی را مشخص میکند؟
به زبان ساده:
Acceptance Criteria مشخص میکند یک Feature برای اینکه قابل پذیرش باشد، چه شرایطی باید داشته باشد.
برای مثال:
«اگر سفارش هنوز ارسال نشده باشد، کاربر باید بتواند آن را لغو کند.»
این جمله یک شرط مشخص برای پذیرش Feature ایجاد میکند.
سپس میتوان بر اساس آن Test Scenario و Test Case طراحی کرد و در مراحل بعدی Acceptance Testing یا UAT را انجام داد.
Acceptance Criteria چه چیزی نیست؟
یکی از مهمترین نکات این مقاله، تفکیک Acceptance Criteria از مفاهیم مشابه بود.
Acceptance Criteria ≠ Test Case
Acceptance Criteria شرایط مورد انتظار را مشخص میکند، در حالی که Test Case روش مشخص بررسی آن شرایط است.
Acceptance Criteria ≠ UAT
Acceptance Criteria شرایط پذیرش را تعریف میکند، اما UAT فرایندی برای ارزیابی پذیرش سیستم از دید کاربران یا کسبوکار است.
Acceptance Criteria ≠ Definition of Done
Acceptance Criteria معمولاً به شرایط پذیرش یک User Story یا Feature مربوط است، در حالی که Definition of Done مجموعه شرایط عمومی لازم برای Done شدن یک Product Backlog Item یا Increment را مشخص میکند.
یک Acceptance Criteria خوب چه ویژگیهایی دارد؟
معیارهای پذیرش خوب معمولاً:
- واضح و بدون ابهام هستند.
- قابل تست هستند.
- نتیجه مورد انتظار را مشخص میکنند.
- با User Story و نیاز کسبوکار ارتباط دارند.
- شرایط مهم مثبت و منفی را پوشش میدهند.
- در صورت نیاز Boundaryها و Business Rules را مشخص میکنند.
- بیش از حد وارد جزئیات Implementation نمیشوند.
- با سایر Requirements و Acceptance Criteria تناقض ندارند.
در عین حال، Acceptance Criteria نباید آنقدر جزئی شود که به مجموعهای از Test Steps تبدیل شود.
نقش Tester در Acceptance Criteria
Tester میتواند حتی قبل از نوشتهشدن کد در کیفیت Acceptance Criteria نقش داشته باشد.
سؤالهایی مانند:
- «اگر اطلاعات نامعتبر باشد چه اتفاقی میافتد؟»
- «محدودیت دقیقاً شامل مقدار مرزی هم میشود؟»
- «این Requirement چگونه قابل تست خواهد بود؟»
- «اگر عملیات با خطا مواجه شود چه رفتاری انتظار داریم؟»
میتوانند ابهامهای Requirement را پیش از ورود به مرحله Development آشکار کنند.
به همین دلیل، Acceptance Criteria فقط ابزاری برای Finding Defects نیست؛ بلکه میتواند در Preventing Defects نیز نقش داشته باشد.
Acceptance Criteria و فرایند توسعه و تست
میتوان جایگاه کلی Acceptance Criteria را چنین خلاصه کرد:
Business Need
↓
User Story / Requirement
↓
Acceptance Criteria
↓
Development
↓
Test Design & Testing
↓
Acceptance Testing
↓
UAT در صورت نیاز
↓
Acceptance / Release Decision
در این جریان، Acceptance Criteria مانند یک پل بین Requirement و Testing عمل میکند.
آیا همیشه باید Acceptance Criteria با Given / When / Then نوشته شود؟
خیر.
برای معیارهای ساده، یک فهرست کوتاه میتواند کاملاً مناسب باشد.
برای سناریوهای پیچیدهتر، استفاده از Given / When / Then میتواند ارتباط بین شرایط اولیه، اقدام و نتیجه مورد انتظار را شفافتر کند.
بنابراین:
قالب مهم است، اما کیفیت و شفافیت معیار مهمتر از قالب آن است.
مهمترین نکته
اگر بخواهیم تمام مقاله را در یک جمله خلاصه کنیم:
Acceptance Criteria مشخص میکند «چه چیزی باید برای پذیرش Feature برقرار باشد»، در حالی که Testing بررسی میکند «آیا این شرایط واقعاً برقرار هستند یا خیر».
داشتن معیارهای پذیرش واضح باعث میشود اختلاف برداشت بین افراد تیم کاهش پیدا کند، طراحی تست هدفمندتر شود و برخی ابهامها و مشکلات قبل از شروع Development شناسایی شوند.
در نهایت، Acceptance Criteria زمانی بیشترین ارزش را ایجاد میکند که بهعنوان یک توافق مشترک بین کسبوکار، محصول، توسعه و تست دیده شود؛ نه صرفاً یک فهرست از مواردی که در پایان Sprint باید تیک بخورند.
منابع و مراجع
- Acceptance Criteria – ISTQB Glossary — تعریف رسمی Acceptance Criteria و شرایطی که یک سیستم یا کامپوننت برای پذیرش باید برآورده کند.
- Acceptance Testing – ISTQB Glossary — تعریف Acceptance Testing و ارتباط آن با نیازهای کاربر، Requirements، Business Processes و Acceptance Criteria.
- User Acceptance Testing – ISTQB Glossary — تعریف UAT و نقش آن در بررسی پذیرش سیستم توسط کاربران موردنظر.
- What is the Difference Between the DoD and Acceptance Criteria? – Scrum.org — بررسی تفاوت Definition of Done و Acceptance Criteria و جایگاه هرکدام در Scrum.
- The Definition of Done – Scrum.org — توضیح Definition of Done و نقش آن در تعیین استانداردهای کیفیت Increment.
- What is Acceptance Criteria? Definition, Examples, & Tips – Atlassian — معرفی Acceptance Criteria، مثالهای کاربردی و نکاتی برای نوشتن معیارهای پذیرش.
سوالات متداول درباره Acceptance Criteria
Acceptance Criteria یا معیارهای پذیرش مجموعهای از شرایط مشخص است که تعیین میکند یک User Story، Feature یا نیازمندی چه شرایطی باید داشته باشد تا قابل پذیرش در نظر گرفته شود.
یک پاسخ واحد برای همه تیمها وجود ندارد. بسته به ساختار سازمان، ممکن است Product Owner، Business Analyst یا اعضای تیم بهصورت مشترک در تعریف آن مشارکت کنند.
مهمتر از اینکه چه کسی آن را مینویسد، این است که معیارها با نیاز کسبوکار هماهنگ باشند و تیم درباره آنها درک مشترکی داشته باشد.
لزومی ندارد.
معمولاً Acceptance Criteria توسط Product Owner یا Business Analyst و با همکاری تیم تعریف میشود. با این حال، Tester میتواند نقش مهمی در Review و بهبود معیارهای پذیرش داشته باشد و ابهامها، شرایط منفی، Boundaryها و مشکلات Testability را شناسایی کند.
Acceptance Criteria مشخص میکند چه شرایطی باید برقرار باشد.
Test Case مشخص میکند چگونه آن شرط را بررسی کنیم.
برای مثال:
Acceptance Criteria:
کاربر با اطلاعات معتبر باید بتواند وارد حساب شود.
Test Case:
اطلاعات معتبر وارد کنید، روی Login کلیک کنید و بررسی کنید که کاربر وارد حساب شده است.
بنابراین Acceptance Criteria جایگزین Test Case نیست.
Acceptance Criteria شرایط پذیرش را تعریف میکند.
User Acceptance Testing (UAT) فرایندی است که طی آن سیستم یا Feature از دید کاربران یا کسبوکار ارزیابی میشود تا مشخص شود برای استفاده موردنظر قابل قبول است یا خیر.
بنابراین:
Acceptance Criteria = شرایط پذیرش
UAT = فرایند ارزیابی پذیرش از دید User/Business
Acceptance Criteria معمولاً به شرایط پذیرش یک User Story یا Feature مشخص مربوط است.
Definition of Done مجموعهای از شرایط عمومی است که تیم برای Done بودن یک آیتم یا Increment در نظر میگیرد.
Acceptance Criteria:
پس از ثبت موفق سفارش، شماره سفارش باید به کاربر نمایش داده شود.
Definition of Done:
Acceptance Criteria پاس شده باشد، تستهای لازم انجام شده باشد، Code Review انجام شده باشد و سایر استانداردهای تیم رعایت شده باشند.
در عمل، داشتن Acceptance Criteria برای User Storyهایی که نیاز به شرایط مشخص پذیرش دارند بسیار مفید است.
با این حال، نباید آن را یک قانون مطلق برای تمام تیمها و تمام پروژهها در نظر گرفت.
مهم این است که تیم بتواند شرایط پذیرش و نتیجه مورد انتظار را به شکل واضح مشخص کند.
خیر.
Acceptance Criteria در محیطهای مختلف توسعه نرمافزار قابل استفاده است، اما در Agile و Scrum کاربرد بسیار رایجی دارد؛ زیرا با شفافکردن شرایط پذیرش یک Product Backlog Item میتواند به ایجاد درک مشترک بین اعضای تیم کمک کند.
خیر.
Requirement مشخص میکند چه نیازی وجود دارد یا سیستم چه قابلیتی باید ارائه کند.
Acceptance Criteria مشخص میکند برای پذیرفتهشدن آن قابلیت چه شرایطی باید برقرار باشد.
این دو به یکدیگر مرتبط هستند، اما یکسان نیستند.
خیر.
Given / When / Then یکی از روشهای رایج برای نوشتن Acceptance Criteria است، بهخصوص برای سناریوهای رفتاری.
اما برای Requirementهای ساده، یک فهرست Bullet Point ممکن است خواناتر و مناسبتر باشد.
قالب باید متناسب با پیچیدگی Requirement انتخاب شود.
خیر.
Acceptance Criteria شرایط مهم پذیرش را مشخص میکند و قرار نیست تمام جزئیات تست را شامل شود.
Tester میتواند بر اساس Acceptance Criteria و همچنین Requirements، Business Rules، Riskها و سایر اطلاعات، Test Caseهای لازم را طراحی کند.
خیر.
بسته به نوع Feature، Acceptance Criteria میتواند شامل معیارهای مرتبط با ویژگیهای Non-functional نیز باشد.
برای مثال:
«نتایج جستوجو باید حداکثر طی ۲ ثانیه نمایش داده شوند.»
این معیار به Performance مربوط است.
همچنین در صورت نیاز میتوان معیارهایی مرتبط با Security، Accessibility، Compatibility یا سایر ویژگیهای کیفیت نیز تعریف کرد.
بهتر است Tester ابهام را قبل از شروع تست و ترجیحاً قبل از Development مطرح کند.
برای مثال اگر نوشته شده باشد:
«صفحه باید سریع بارگذاری شود.»
Tester میتواند سؤال کند:
«منظور از سریع دقیقاً چیست؟ آیا زمان مشخصی برای پاسخ وجود دارد؟»
هدف این نیست که Tester شخصاً Requirement را تفسیر کند؛ بلکه باید ابهام را با افراد مسئول Requirement و کسبوکار برطرف کند.
بله، در صورتی که Requirement یا Business Need تغییر کند یا تیم در جریان بررسی Requirement به درک دقیقتری برسد، Acceptance Criteria نیز ممکن است تغییر کند.
اما این تغییر باید شفاف، آگاهانه و هماهنگ با افراد مسئول محصول و کسبوکار انجام شود.
نباید صرفاً برای اینکه یک Test Pass شود، Acceptance Criteria را تغییر داد.
بهتر است Acceptance Criteria قبل از شروع Development یا حداقل پیش از زمانی که User Story وارد مرحله Development شود، تا حد مناسبی مشخص شده باشد.
این کار کمک میکند:
- ابهامها زودتر شناسایی شوند.
- Developer بداند چه چیزی باید پیادهسازی شود.
- Tester بتواند Test Design را بهتر انجام دهد.
- Product Owner بداند چه چیزی قرار است تحویل بگیرد.
در Agile، این موضوع میتواند در فعالیتهایی مانند Backlog Refinement و گفتگوهای مرتبط با User Story انجام شود.
خیر.
هرچند استفاده از Acceptance Criteria در کنار User Story بسیار رایج است، اما میتوان برای Featureها، Product Backlog Itemها و سایر نیازمندیهایی که نیاز به شرایط مشخص پذیرش دارند نیز از آن استفاده کرد.
نه لزوماً.
Acceptance Criteria باید به اندازه کافی دقیق باشد تا رفتار مورد انتظار و شرایط پذیرش مشخص شود، اما نباید آنقدر وارد جزئیات شود که به Test Case یا Implementation تبدیل شود.
یک معیار خوب بین این دو حالت تعادل ایجاد میکند:
نه بیش از حد کلی و مبهم، نه بیش از حد جزئی و فنی.
اگر بخواهیم فقط یک ویژگی را انتخاب کنیم:
قابل فهم و قابل تست بودن.
یعنی اعضای تیم بتوانند درباره معنی آن برداشت مشترکی داشته باشند و Tester نیز بتواند بر اساس آن مشخص کند که Criterion برآورده شده است یا خیر.
