توسعه مبتنی بر رفتار با کشف نیازهای از دست رفته بر اساس مثالهای مشخص ، درک مشترکی از نحوه رفتار یک برنامه را ایجاد می کند و از اشکالات و سو تفاهم ها جلوگیری می کند.
همچنین چارچوب BDD یک رویکرد توسعه نرم افزار است که به کیو ای / پروداکت اونر اجازه می دهد موارد آزمایشی را به زبان متن ساده ایجاد کنند. این کار به تیم QA کمک میکند تا تست اتومات (automated testing) را سریعتر و آسان تر ، به دست آورد.
زبان ساده مورد استفاده در سناریوها حتی به اعضای تیم غیرفنی نیز کمک می کند تا بفهمند در پروژه نرم افزار چه می گذرد. این به ارتباطات بین تیم های فنی و غیرفنی ، مدیران و استکهولدرها کمک می کند.
نحوه نوشتن BDD:
با استفاده از BDD ، آزمون ها با استفاده از زبان gherkin Given-When-then ایجاد می شوند.
قسمت When فقط باید حاوی یک Trigger باشد ، و قسمت Given باید تمام شرایطی را که بر آن Trigger تأثیر دارند ، فهرست کند.
مثلا:
-(GIVEN) در فرم ثبت نام هستم و تمام قسمت های اجباری پرشده است
(نام کوچک،نام خانوادگی،پست الکترونیک،کلمه عبور)
-(WHEN)وقتی فرم را ارسال می کنم
-(THEN) یک حساب کاربری ایجاد می شود و یک ایمیل تایید برای من ارسال میشود
پیش شرط و توالی وقایع:
در حالی که هدف ما این است که هنگام نوشتن داستان های کاربر بدون ابهام باشیم ، اما ممکن است از حد بگذریم و در دام توضیح بیش از حد بیفتیم.
سناریو: تأیید مجدد انتخاب صندلی پرواز:
(GIVEN)من یک پرواز را در صفحه انتخاب پرواز انتخاب کرده ام
AND من ترجیح دادم از انتخاب صندلی در صفحه انتخاب صندلی بگذرم
AND من یک وعده غذایی را در صفحه انتخاب غذا انتخاب کردم
(WHEN) جزئیاتم را در صفحه تأیید جزئیات تأیید می کنم
(THEN)باید یک پیام هشدار "صندلی به طور تصادفی اختصاص داده می شود ، ادامه دهید" ظاهر شود
باز هم ، در نگاه اول ، این به نظر درست می رسد و صادقانه بگویم ، نوشتن تست های قبولی برای این کار دشوار نیست. با این وجود ، یک روش ساده تر و بهتر برای نوشتن همان سناریو وجود دارد:
(GIVEN) من در صفحه تأیید جزئیات هستم
AND من ترجیح داده ام از انتخاب صندلی بگذرم
(WHEN)جزئیاتم را در صفحه تأیید جزئیات تأیید می کنم
(THEN)یک پیام هشدار دهنده باید نمایش داده شود "صندلی به طور تصادفی اختصاص داده می شود ، ادامه دهید"
در این مثال ، بخش پیش شرط ابتدا زمینه را تنظیم می کند ، سپس تنها پیش شرط مهم در این سناریو را ذکر می کند.
در این حالت ، این موارد مهم نیستند:
- جریان و ترتیب ورود کاربر به صفحه تأیید جزئیات
- اقدامات و پارامترهایی (غیر از پرش از انتخاب صندلی) که کاربر قبل از این انجام داده است
با در نظر گرفتن این سناریو یا آزمایش خاص در حداقل مراحل ممکن ، آن را نسبت به تغییرات شکننده تر می کند و اغلب برای آزمایش همه سناریوها به آزمایشات کمتری نیاز دارد.
برگرفته از سایت:
https://www.thoughtworks.com/insights/blog/applying-bdd-acceptance-criteria-user-stories
--------------------------------------------------------------
