اشتراک گذاری:
تصور کنید که از تیم توسعه خود بخواهید تا کاربران را قادر سازد تا محصولی را در یک کتابفروشی آنلاین بر اساس دسته بندی جستجو کنند. شما انتظار دارید که یک رابط واضح با پیوندهای دسته بندی داشته باشید تا روی آنها کلیک کنید (به عنوان مثال، فانتزی، غیرداستانی، تاریخی، و غیره) پس از دو هفته توسعه، یک ویژگی نوار جستجو دریافت می کنید که در آن کاربران باید دسته مورد علاقه خود را تایپ کنند.، به جای مرور دسته های از پیش فهرست شده. در حالی که این نیز کار می کند، هدف اولیه شما این بود که همه دسته های موجود را در معرض دید قرار دهید و به کاربران اجازه دهید بیشتر کاوش کنند.
برای جلوگیری از وقوع چنین مسائلی و ارائه راه حلی که نیازهای مشتری را برآورده می کند و متناسب با نیازهای بازار باشد، باید اسناد نرم افزاری با کیفیت بالا وجود داشته باشد. در اینجا زمانی است که داستان های کاربر و معیارهای پذیرش (AC) وارد عمل می شوند زیرا آنها قالب های اصلی مستندسازی الزامات هستند.
در حالی که هدف داستان های کاربر توصیف آنچه کاربر دقیقاً می خواهد سیستم انجام دهد، است، هدف معیارهای پذیرش توضیح شرایطی است که یک داستان کاربر خاص باید برآورده شود. در این پست، ما بر معیارهای پذیرش تمرکز خواهیم کرد: اهداف، انواع و نحوه نگارش آنها را روشن خواهیم کرد (با ارائه مثال).
معیارهای پذیرش، توضیح داده شده است
معیارهای پذیرش و نقش آنها در پروژه ها چیست؟
معیارهای پذیرش (AC) شرایطی هستند که یک محصول نرم افزاری برای پذیرفته شدن توسط کاربر، مشتری یا سایر سیستم ها باید رعایت کند. آنها برای هر داستان کاربر منحصر به فرد هستند و رفتار ویژگی را از دیدگاه کاربر نهایی تعریف می کنند.
معیارهای پذیرش به خوبی نوشته شده به جلوگیری از نتایج غیرمنتظره در پایان مرحله توسعه کمک می کند و تضمین می کند که همه ذینفعان و کاربران از آنچه به دست می آورند راضی هستند.
یک جنبه مهم در رابطه با معیارهای پذیرش این است که آنها باید قبل از شروع کار تیم توسعه بر روی یک داستان کاربر خاص، تعریف شوند. در غیر این صورت، این احتمال وجود دارد که محصولات قابل تحویل نیازها و انتظارات مشتری را برآورده نکنند.
معیارهای پذیرش اهداف اصلی
شفاف سازی نیازهای ذینفعان یک هدف سطح بالا است. برای اینکه اهداف AC واضح تر شود، اجازه دهید آنها را تجزیه کنیم.
با جزئیات بیشتر دامنه ویژگی. AC مرزهای داستان های کاربر را مشخص می کند. آنها جزئیات دقیقی در مورد عملکرد ارائه می دهند که به تیم کمک می کند تا بفهمد آیا داستان کامل شده است و همانطور که انتظار می رود کار می کند.
توصیف سناریوهای منفی. AC شما ممکن است از سیستم بخواهد ورودی های رمز عبور ناامن را تشخیص دهد و از ادامه کار کاربر جلوگیری کند. فرمت رمز عبور نامعتبر نمونه ای از به اصطلاح سناریوی منفی است که کاربر ورودی های نامعتبر یا رفتار غیر منتظره ای را انجام می دهد. AC این سناریوها را تعریف می کند و توضیح می دهد که چگونه سیستم باید نسبت به آنها واکنش نشان دهد.
برقراری ارتباطمعیارهای پذیرش همگام سازی چشم انداز مشتری و تیم توسعه. آنها اطمینان می دهند که هر کس درک مشترکی از الزامات دارد: توسعه دهندگان دقیقاً می دانند که چه نوع رفتاری باید نشان دهد ، در حالی که ذینفعان و مشتری می دانند که از این ویژگی چه چیزی انتظار می رود.
آزمایش پذیرش ساده. AC اساس تست پذیرش داستان کاربر است. هر معیار پذیرش باید به طور مستقل قابل آزمایش باشد و بنابراین سناریوهای پاس یا ناکامی روشن داشته باشد. همچنین می توان از آنها برای تأیید داستان از طریق تست های خودکار استفاده کرد.
انجام ارزیابی های ویژگی. معیارهای پذیرش مشخص می کند که دقیقاً چه چیزی باید توسط تیم توسعه یابد. هنگامی که تیم نیازهای دقیقی داشته باشد ، می توانند داستان های کاربر را به کارهایی تقسیم کنند که به درستی تخمین زده شود.
از آنجا که افراد مختلف می توانند دیدگاه های مختلف و ایده های راه حل در مورد یک مشکل داشته باشند ، ایجاد یک دیدگاه یکپارچه در مورد چگونگی اجرای عملکرد ، ضروری است. این دقیقاً همان کاری است که معیارهای پذیرش به روشنی انجام می دهد.
معیارهای پذیرش انواع و ساختارها
بر اساس کار اولیه و پیچیدگی الزامات ، معیارهای پذیرش را می توان در قالب های مختلف نوشت ، یعنی:
- سناریو گرا (الگوی داده شده/چه زمانی/سپس) ؛
- قاعده گرا (الگوی لیست چک) ؛وت
- قالب های سفارشی
متداول ترین آنها ، قالب های اول و دوم ساختارهای بسیار خاصی دارند ، بنابراین ما عمدتاً روی آنها تمرکز خواهیم کرد. با این حال ، ممکن است متوجه شوید که قالب های دیگر با محصول شما بهتر متناسب هستند ، بنابراین ما به طور خلاصه به آنها نیز لمس خواهیم کرد.
معیارهای پذیرش سناریو گرا
همانطور که از نام آن پیداست ، قالب سناریو گرا نوع معیارهای پذیرش است که به شکل سناریو می آید و هر معیار را نشان می دهد. از طریق دنباله داده شده/چه زمانی/سپس (GWT) که به نظر می رسد نزدیک می شود:
- با توجه به پیش شرط
- وقتی من برخی از اقدامات را انجام می دهم
- سپس من انتظار نتیجه ای دارم
این رویکرد از توسعه رفتار محور (BDD) به ارث رسیده و یک ساختار ثابت را فراهم می کند که به آزمایش کنندگان کمک می کند تا چه زمانی شروع و پایان آزمایش یک ویژگی خاص را تعریف کنند. همچنین زمان صرف شده برای نوشتن موارد آزمون را کاهش می دهد زیرا رفتار سیستم به صورت مقدماتی شرح داده شده است.
الگوی معیارهای پذیرش در این قالب شامل گفته های زیر است:
- سناریو - نام رفتاری که توصیف خواهد شد
- داده شده - وضعیت آغاز سناریو
- چه موقع - اقدام خاصی که کاربر انجام می دهد
- سپس - نتیجه عمل در "چه زمانی"
- و - برای ادامه هر سه بیانیه قبلی استفاده می شود
الگوی معیارهای پذیرش در قالب داده شده/چه زمانی/سپس
این بیانیه ها هنگام ترکیب ، تمام اقداماتی را که کاربر برای انجام یک کار انجام می دهد و نتیجه را تجربه می کند ، پوشش می دهد.
بیایید به چند نمونه نگاه کنیم.
مثال 1
داستان کاربر: من به عنوان یک کاربر ، می خواهم بتوانم رمز ورود را به حساب خود بازیابی کنم ، تا در صورت فراموش کردن رمز عبور ، بتوانم به حساب خود دسترسی پیدا کنم.
بازیابی مثال معیارهای پذیرش رمز عبور
سناریو: رمز عبور را فراموش کرده اید
- با توجه به: کاربر به صفحه ورود به سیستم منتقل می شود
- When : The user selects forgot password>گزینه
- و: برای دریافت پیوندی برای بازیابی رمز عبور ، یک ایمیل معتبر وارد می کند
- سپس: سیستم پیوند را به ایمیل وارد شده ارسال می کند
- با توجه به: کاربر پیوند را از طریق ایمیل دریافت می کند
- چه زمانی: کاربر از طریق لینک دریافت شده در ایمیل حرکت می کند
- سپس: سیستم کاربر را قادر می سازد رمزعبور جدیدی را تنظیم کند
مثال 2
داستان کاربر: من به عنوان یک کاربر ، می خواهم بتوانم پول نقد را از حساب خود در دستگاه خودپرداز درخواست کنم تا بتوانم به سرعت و در مکان های مختلف پول را از حساب خود دریافت کنم.
"درخواست پول از حساب در دستگاه خودپرداز" مثال معیارهای پذیرش ، سناریو 1
سناریو 1: درخواست پول نقد از یک حساب معتبر
- با توجه به: این حساب قابل اعتبار است
- و: کارت معتبر است
- و: توزیع کننده حاوی پول نقد است
- چه زمانی: مشتری درخواست پول نقد را می دهد
- سپس: اطمینان حاصل کنید که حساب کاربری پرداخت شده است
- و: اطمینان حاصل کنید که پول نقد توزیع شده است
- و: اطمینان حاصل کنید که کارت بازگردانده شده است
"درخواست پول از حساب در دستگاه خودپرداز" مثال معیارهای پذیرش ، سناریو 2
سناریو 2: درخواست پول نقد از یک حساب بیش از حد تهیه شده
- با توجه به: این حساب بیش از حد تصویب شده است
- و: کارت معتبر است
- چه زمانی: مشتری درخواست پول نقد را می دهد
- سپس: اطمینان حاصل کنید که پیام رد نمایش داده شده است
- و: اطمینان حاصل کنید که پول نقد توزیع نشده است
همانطور که از مثال‌ها می‌بینید، معیارهای پذیرش سناریو محور می‌توانند در موقعیت‌های مختلف کاملاً مؤثر باشند. اما آنها را نمی توان یک راه حل جهانی در نظر گرفت.
قالب معیارهای پذیرش قانون مدار
در برخی موارد، تطبیق معیارهای پذیرش در ساختار Given/When/Then دشوار است. به عنوان مثال، GWT به سختی برای موارد زیر مفید خواهد بود:
- شما در حال کار با داستان های کاربری هستید که عملکردی در سطح سیستم را توصیف می کند که به روش های دیگر تضمین کیفیت نیاز دارد.
- مخاطبان هدف برای معیارهای پذیرش نیازی به جزئیات دقیق سناریوهای آزمون ندارند.
- سناریوهای GWT با طراحی توصیفی و محدودیت‌های تجربه کاربر یک ویژگی مطابقت ندارند. توسعه دهندگان ممکن است تعدادی از جزئیات مهم را از دست بدهند.
شما می توانید این موارد را با فرمت AC قانون مدار رسیدگی کنید.
فرم قانون مدار مستلزم این است که مجموعه ای از قوانین وجود دارد که رفتار یک سیستم را توصیف می کند. بر اساس این قوانین، می توانید سناریوهای خاصی را ترسیم کنید.
معمولاً معیارهایی که با استفاده از این فرم تهیه می شوند مانند یک لیست ساده به نظر می رسند. بیایید به یک مثال نگاه کنیم.
مثال
داستان کاربر: به عنوان یک کاربر، می‌خواهم از یک فیلد جستجو برای تایپ شهر، نام یا خیابان استفاده کنم تا بتوانم گزینه‌های مطابق با هتل را پیدا کنم.
معیارهای پذیرش رابط جستجوی پایه
- فیلد جستجو در نوار بالا قرار می گیرد
- جستجو زمانی شروع می شود که کاربر روی «جستجو» کلیک کند
- فیلد حاوی یک مکان نگهدار با یک متن خاکستری رنگ است: "کجا می روی؟"
- هنگامی که کاربر شروع به تایپ می کند، مکان نگهدار ناپدید می شود
- جستجو در صورتی انجام می‌شود که کاربر در یک شهر، نام هتل، خیابان یا همه موارد ترکیبی تایپ کند
- جستجو به زبان های انگلیسی، فرانسوی، آلمانی و اوکراینی است
- کاربر نمی تواند بیش از 200 علامت را تایپ کند
- جستجو از نمادهای خاص (شخصیت) پشتیبانی نمی کند. اگر کاربر نماد خاصی را تایپ کرده است، پیام هشدار را نشان دهید: "ورودی جستجو نمی تواند دارای نمادهای خاص باشد."
فرمت های دیگر
اکثر داستان های کاربر را می توان با دو قالب ذکر شده در بالا پوشش داد. با این حال، شما می توانید معیارهای پذیرش خود را ابداع کنید، زیرا آنها اهداف خود را برآورده می کنند، به وضوح به زبان انگلیسی ساده نوشته شده اند و نمی توان آنها را اشتباه تفسیر کرد. برخی از تیم ها حتی از متن ساده استفاده می کنند.
به عنوان مثال، معیارهای شما ممکن است به عنوان نمونه ای از رفتار سیستم مشخص شود:
مجموعه ای ساده از AC برای رمزهای عبور قوی توسط Mark Levison برای agilepainpainrelief. com
این رویکرد دستورالعمل های واضحی را برای آزمایش ویژگی رمز عبور ارائه می دهد.
الگوهای معیارهای پذیرش آماده برای استفاده
همه فرمول های ذکر شده در بالا برای نوشتن معیارهای پذیرش به راحتی قابل پیروی هستند و مهمتر از آن مؤثر هستند. آنها اطمینان حاصل می کنند که تیم توسعه وظیفه را درک کرده و داستان کاربر به درستی پیاده سازی می شود.
در صورتی که برای تکمیل سریع اطلاعات لازم و سازماندهی داستان های کاربری خود به چند الگوی معیار پذیرش قابل دانلود نیاز دارید، منابع زیر مفید خواهند بود.
-
الگوی ثبت معیارهای پذیرش MS Excel را به عنوان بخشی از بسته الگوی تست نرم افزار ارائه می دهد. چند قالب ارائه می دهد که داستان های مختلف کاربر و معیارهای پذیرش را به تصویر می کشد. شامل یک قالب در قالب PPT با شش طرح پویا است که امکان نوشتن جملات ساده داستان کاربر و معیارهای پذیرش را فراهم می کند.
- در نقشه ذینفعان، می‌توانید الگوی الزامات پروژه اکسل کاملاً قابل ویرایش را دانلود کنید که شامل معیارهای پذیرش است.
اکنون که نمونه ها و الگوهای معیارهای پذیرش را در دست دارید، بیایید به این بپردازیم که چه کسی باید مسئول نوشتن این نوع نیازهای نرم افزار باشد.
نقش های مسئول و نحوه ایجاد معیارهای پذیرش
برخی از معیارها توسط مالک محصول زمانی که بک لاگ محصول را ایجاد می کند، تعریف و نوشته می شود. و بقیه را می‌توان در طول بحث‌های مربوط به داستانهای کاربر پس از برنامه‌ریزی اسپرینت توسط تیم مشخص کرد.
این فرآیند با اولویت بندی داستان کاربر شروع می شود و با جزئیات مذاکره با کل تیم به پایان می رسد
هیچ توصیه اکیدی برای انتخاب فرد مسئول برای نوشتن معیارها وجود ندارد. مشتری اگر دانش فنی و مستندات محصول کافی داشته باشد می تواند آنها را مستند کند. در این مورد، مشتری معیارها را با تیم مذاکره می کند تا از سوء تفاهم متقابل جلوگیری شود. در غیر این صورت، معیارها توسط صاحب محصول، تحلیلگر کسب و کار، تحلیلگر نیازمندی ها یا مدیر پروژه ایجاد می شود.
برای کسب اطلاعات بیشتر در مورد برنامه ریزی نرم افزار و مستندسازی، ویدیوی ما را بررسی کنید.
مستندات نرم افزاری، توضیح داده شده است
چالش های اصلی و بهترین شیوه های نوشتن معیارهای پذیرش
معیارهای پذیرش به نظر می رسد که نوشتن آنها بسیار آسان است. علیرغم فرمت های ساده آنها، این نوشتار برای بسیاری از تیم ها چالش برانگیز است. بیایید نگاهی عمیق تر به بهترین شیوه هایی داشته باشیم که به جلوگیری از اشتباهات رایج کمک می کند.
معیارهای سند قبل از توسعه. معیارهای پذیرش قبل از شروع توسعه واقعی باید مستند شوند. به این ترتیب ، تیم احتمالاً تمام نیازهای مشتری را از قبل ضبط می کند. در ابتدا ، کافی است که معیارهایی را برای تعداد کمی از داستانهای کاربر تعیین کنید تا پس زمینه های دو اسپرینت را پر کنید (اگر تمرین می کنید یا یک روش مشابه). آنها باید توسط هر دو طرف توافق شوند. سپس معیارهای پذیرش مستند توسط توسعه دهندگان برای برنامه ریزی فرایند فنی استفاده می شود.
AC را خیلی باریک نکنید. معیارهای پذیرش می تواند بسیار خاص زندگی کمی باشد تا گزینه های مانور برای توسعه دهندگان باشد. برای جلوگیری از این امر ، به یاد داشته باشید که AC باید هدف را منتقل کند اما یک راه حل نهایی نیست. علاوه بر این ، AC باریک ممکن است از رفتارهای مختلف کاربر که تحت پوشش قرار نگرفته اند ، محروم باشد.
معیارهای خود را قابل دستیابی نگه دارید. این نکته از نزدیک با نکته قبلی تقاطع می کند. معیارهای پذیرش مؤثر حداقل عملکرد معقول را که می توانید ارائه دهید تعریف می کند. اما در صورت تسلیم در توصیف همه جزئیات کوچک ، این خطر وجود دارد که تیم شما با صدها کار کوچک گیر بیفتد.
AC قابل اندازه گیری و خیلی گسترده نیست. معیارهای پذیرش گسترده باعث می شود یک داستان کاربر مبهم باشد. معیارهای پذیرش مؤثر باید دامنه کار را تشریح کند تا توسعه دهندگان بتوانند تلاش خود را به درستی برنامه ریزی و تخمین بزنند.
از جزئیات فنی خودداری کنید. همانطور که اشاره کردیم ، معیارهای پذیرش باید به زبان انگلیسی ساده نوشته شود. این باعث می شود آنها برای همه روشن و آسان درک شوند: ذینفعان یا مدیران شما ممکن است سابقه فنی کافی نداشته باشند.
رسیدن به اجماعبسته به نقاط برتری آنها ، همین مشکل ممکن است توسط یک تیم و ذینفعان متفاوت باشد. اطمینان حاصل کنید که AC خود را به ذینفعان ابلاغ کرده اید و به توافق متقابل رسیده اید. همین مورد در مورد اعضای تیم نیز صدق می کند. همه باید AC را مرور کنند و تأیید کنند که آنها با هر خط درک و موافق هستند.
AC قابل آزمایش را بنویسید. این به آزمایش کنندگان اجازه می دهد تا تأیید کنند که تمام شرایط مورد نیاز برآورده شده است. در غیر این صورت ، توسعه دهندگان نمی دانند که آیا داستان کاربر به پایان رسیده است یا خیر.
این نکات را برای راهنمایی در مورد نحوه بیان AC خود دنبال کنید.
با صدای فعال ، شخص اول بنویسید. صدای فعال زمانی است که موضوع یک جمله عمل (فعل) را انجام می دهد. چسبیدن به صدای فعال یک توصیه متداول در روش چابک است. به این ترتیب ، AC کلمات واقعی را که کاربر می گوید منعکس می کند. استفاده از صدای منفعل ممکن است مشخص شود که چه کسی به چه چیزی احتیاج دارد. به جای نوشتن "فیلترها باید در جستجو اعمال شوند" ، سعی کنید توضیحات آموزنده تری را ارائه دهید "کاربر باید بتواند مجموعه ای از فیلترها را برای یافتن موارد خاص اعمال کند".
از جملات منفی خودداری کنید. همیشه ایده خوبی است که از استفاده از ضرب المثل "نه" خودداری کنید ، زیرا اغلب الزامات نامشخص و قابل اثبات است. اگرچه ، استفاده از "نه" در صورت نیاز به ارائه الزامات منحصر به فرد به عملکرد سیستم امکان پذیر است. بگویید ، "وقتی کاربر وارد مقادیر نادرست می شود ، شکل ورود به سیستم نباید به رنگ قرمز برجسته شود."
جملات ساده و مختصر بنویسید. بهتر است به جای یک پیچیده از چندین جمله ساده استفاده کنید. کمتر کلمات و پیوندهای بی نیاز مانند "اما ،" و "" و "" بنابراین "، و" و همچنین "در معیارهای پذیرش شما ، شرایط لازم برای تیم های توسعه است.
حرف آخر
از معیارهای پذیرش غافل نشوید زیرا آنها - ساده و نزدیک بودن - چندین مشکل را به طور همزمان حل می کنند. آنها انتظارات مشتری را مستند می کنند ، دیدگاه کاربر نهایی را ارائه می دهند ، الزامات را روشن می کنند ، از ابهام جلوگیری می کنند و در نهایت به تضمین کیفیت کمک می کنند تا در صورت تحقق اهداف توسعه تأیید شود. صرف نظر از اینکه از روشهای چابک استفاده می کنید یا خیر ، حتماً بهترین قالب را انتخاب کنید یا با روشهای خود آزمایش کنید. انواع مختلف داستانهای کاربر و در نهایت ویژگی ها ممکن است به قالب های مختلفی نیاز داشته باشند و آزمایشات جدیدی را که برای شما کار می کنند آزمایش خوبی باشد.
