BDD Best Practice

معرفی BDD

BDD یا توسعه رفتار محور یک متدولوژی است برای توسعه نرم افزار که روی ارتباط بین تیم توسعه، تضمین کیفیت و صاحب محصول تمرکز دارد. در این مطلب می خواهیم در مورد بهترین تمرینات یا best practice های مربوط به BDD صحبت کنیم تا بهترین استفاده را از این متدولوژی بکنیم.

بیشتر از هر چیز دیگری، هدف اصلی متدولوژی BDD تشویق به ارتباط بین کسانی که در پیشروی محصول سهیم هستند، می کند تا محتویات ویژگی های محصول یا feature ها به درستی برای همه ی اعضا قابل فهم باشد قبل از اینکه کار توسعه نرم افزار شروع شود. این امکان باعث می شود تا سناریو های کلیدی را برای داستان های کاربر بهتر شناسایی کنیم و همچنین ابهامات در نیازمندی های محصول را رفع کنیم.

در BDD، مثال ها یا Examples به عنوان سناریو شناخته می شوند. سناریو ها در غالب الگوی Context-Action-Outcome شکل گرفته اند و در غالب خاصی به نام Gherkin نوشته شده اند. سناریو ها در واقع یک راهی برای توضیح اینکه ویژگی ها در موقعیت های مختلف یا پارامترهای ورودی مختلف چگونه رفتار کنند، می باشند.

فایل ویژگی یا Feature File چیست؟

فایل های ویژگی، فایل های متنی هستند با پسوند .feature که می توانند با هر ویرایشگر متنی باز شوند و قابل خواندن برای ابزارهای BDD از قبیل Cucumber، JBehave و غیره می باشند. فایل های ویژگی باید با Feature شروع شوند و حداقل یک سناریو با فرمت زیر داشته باشند.

 

Feature: [title]

In order to [context]

As a [role]

I want [benefit]

 

Scenario: [title]

Given some prediction

And some other prediction

When some action by the actor

And some other action

Then some testable outcome is achieved

And something else

سناریو ها در فایل ویژگی باید روی “چه چیزی” تمرکز کنند تا روی “چگونه”. سناریو ها باید مختصر و صریح باشند تا هرکسی آن را می خواند هدف تست را کاملا درک کند بدون آنکه گام های بعدی را مطالعه کند.

چرا فایل ویژگی می سازیم؟

همانطور که قبلا گفتم متدولوژی BDD روی ارتباط بین اعضای تیم تمرکز دارد. هدف از فایل ویژگی مستندسازی سناریوهاست تا بدانیم چه ویژگی هایی را باید پیاده سازی کرد و اینکه چقدر از پیاده سازی یک ویژگی برای ارائه محصول باقی مانده است. فایل های ویژگی در واقع یک تعریفی از تکمیل شدن محصول یا definition of done می باشد یعنی اینکه اگر همه سناریو ها پیاده سازی شوند و همچنین تست را با موفقیت پشت سر بگذارند، می توانیم نتیجه بگیریم که سناریوی مورد نظر تکمیل شده است.

چه کسی باید فایل ویژگی را بنویسد؟

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

چه زمانی باید فایل ویژگی را ساخت؟

فایل های ویژگی باید در جلساتی که داستان های کاربر مشخص می شود و در مورد جزئیات آن بحث می شود، ساخته شوند. فایل های ویژگی باید قبل از شروع توسعه محصول نوشته شود تا تیم توسعه همانند تیم QA درک کاملی روی موضوع داشته باشند. سناریو ها در واقع نیازمندی های محصول هستند که باید توسعه داده شوند.

فایل های ویژگی کجا نگهداری شوند؟

بعد از اینکه فایل ویژگی ساخته یا نوشته شد باید محلی را برای نگهداری آن در نظر بگیریم. چون فایل ویژگی هم برای تیم توسعه و هم برای تیم تست قابل استفاده است پس باید در مکانی باشد تا هرکسی بتواند براحتی به آن دسترسی داشته باشد. مکان ایده ال برای نگهداری این فایل در سیستم کنترل منبع یا source control system مانند Git یا TFS می باشد تا با هربار ویرایش فایل ویژگی، تغییرات روی تست ها اعمال شود.

برای کسانی که تجربه کار یا دانش کافی برای استفاده از Git یا TFS ندارند می توانیم با ابزار Cucumber و گزینه dry-run، لیستی از سناریوهای موجود در فایل ویژگی را استخراج کنیم.

چگونه باید فایل ویژگی را نوشت؟

به طور کلی دو روش برای نوشتن فایل ویژگی وجود دارد: Imperative و Declarative

روش Imperative خیلی پرگو، دارای جزئیات سطح پایین و اطلاعات خیلی زیادی می باشد

مزیت این روش این است که خواننده می تواند با خواندن فایل ویژگی مراحل را گام به گام دنبال کند. عیب این روش این است که چون جزئیات زیاد است فرد هدف اصلی سناریو و تست را فراموش می کند. فایل ویژگی خیلی بزرگ و نگهداری آن سخت می شود.

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

 

برای دنبال کردن مقالات و آموزش تست در تلگرام، عضو کانال زیر شوید:

ُSoftware Testing

مشترک خبرنامه شوید

  • RSS
  • Delicious
  • Digg
  • Facebook
  • Twitter
  • Linkedin
  • Youtube

نقش مدیر تضمین کیفیت

نقش مدیر تضمین کیفیت در چابک چیست؟ آیا ما واقعا ...

چگونه وارد کار تست ن

مثل همه ی کارها، کار تست نرم افزار و انتخاب ...

ابزارهای مفید برای ت

امروزه افراد زیادی هستند که از موبایل خود برای وبگردی ...

BDD Best Practice

معرفی BDD BDD یا توسعه رفتار محور یک متدولوژی است برای ...

Agile Test Strategy

در محیط چابک یا agile، جایی که ما روی اسپرینت ...