«این دقیقاً همون چیزیه که گفتم می‌خوام… ولی من اینو نمی‌خوام!» این جمله بالا به خلاصه‌ترین شکل ممکن «توسعه رفتار محور یا Behaviour Driven Development» را تعریف میکند. توسعه رفتار محور رویکردی در توسعه نرمافزار است که رفتار نرمافزار را پیش از کدنویسی به زبان ساده تشریح میکند. این روش با اطمینان یافتن از هماهنگی یک فیچر با اهداف تجاری و نیازهای کاربر به توسعه چابک نرمافزار کیفیتی تازه می‌بخشد.
این روش با به‌کارگیری منطق خاص خود - که در ادامه به آن خواهیم پرداخت - شکاف بین توسعهدهندگان، کارشناسان تست و ذینفعان را از میان برمی‌دارد. روش تعاملی BDD، سوءتفاهم‌ها را از بین برده و ارتباط بین اعضای تیم را تقویت میکند.
توسعه رفتار محور همچنین تأکید بسیاری بر اتوماسیون و خودکارسازی فرایند بررسی کارکرد محصول دارد. BDD به تیم‌ها کمک میکند تا محصولاتی توسعه دهند که به شکلی بهینه پاسخگوی نیازهای کاربران بوده و کمترین نقص را داشته باشد.
در این مطلب بهطور کامل به بررسی همه جوانب این روش جذاب توسعه نرمافزار خواهیم پرداخت.
توسعه رفتار محور چیست؟
توسعه رفتار محور یا BDD رویکردی است که بر توصیف «رفتار مورد انتظار نرمافزار» به زبانی ساده و ساختارمند تمرکز دارد. این روش با استفاده از مثال‌ها و نمونههای دنیای واقعی، به توسعه نرم‌افزاری کاربردی کمک میکند.
برخلاف روش‌های سنتی تست که تنها بر کارکرد «تمرکز» دارند، BDD نحوه رفتار نرمافزار را از دید کاربر توصیف میکند. این روش به جای تمرکز بر کدها، سناریوهایی را توصیف میکند که نحوه استفاده از نرمافزار در دنیای واقعی را نشان می‌دهند.
توسعه رفتار محور به این منظور از یک سناریو و زبان ساده و ساختاریافته بهره می‌گیرد؛ سناریویی که به آن فرمت Given-When-Then یا سینتکس Gherkin می‌گویند. این فرمت به شکل زیر استفاده میشود:
-
Given / در یک شرایط مشخص
-
When / وقتی عملی مشخص اتفاق افتاد
-
Then / آنگاه یک خروجی مشخص باید رخ دهد
به عبارت دیگر
-
Given (شرایط اولیه): نقطه شروع را تنظیم میکند.
-
When (اقدام): توصیف میکند که چه اتفاقی می‌افتد.
-
Then (نتیجه مورد انتظار): نتیجه‌ای که باید رخ دهد را مشخص میکند.
مثال:
سناریو: ورود موفق به حساب کاربری
-
Given: کاربر در صفحه ورود است.
-
When: وقتی کاربر اطلاعات ورود معتبر را وارد میکند.
-
Then: کاربر باید وارد حساب کاربری شده و داشبورد را مشاهده کند.
این روش، نیازمندیها را شفاف کرده، ابهام را از بین می‌برد و اطمینان می‌یابد که همه ذینفعان حتی پیش از شروع توسعه نرمافزار با یکدیگر هماهنگ‌اند.
اصول توسعه رفتار محور
همکاری
BDD تأکید بسیاری بر همکاری بین همه اعضای مختلف دخیل در یک پروژه دارد. این روش با توصیف رفتارهای موردانتظار در یک فرمت مشترک، اطمینان می‌یابد که همه اعضای تیم‌های فنی و غیرفنی به میزان کافی در فرایند پروژه دخیل هستند.
مثال: مالک محصول، توسعه‌دهنده و مهندس تضمین کیفیت باید در همکاری با یکدیگر سناریونویسی کنند.
زبان متداول
BDD به زبان ساده، متداول و رایج هر روزه تکیه دارد. زبانی که از اصطلاحات فنی سخت اجتناب کرده و رفتار سیستم را در جمله‌هایی ساده شرح می‌دهد. این امر مانع برداشت‌های متفاوت از نیازمند‌های نرمافزار میشود.
مثال: به جای اینکه بگوییم "توکن JWT را از طریق میانافزار صحت‌سنجی کنیم.»، می‌توانیم به سادگی بگوییم: «اگر یک کاربر لاگین و بر روی دکمه پروفایل کلیک کرد باید بتواند اطلاعات اکانت خود را ببیند.»
این دو عبارت می‌خواهند یک مفهوم را برسانند اما کدام‌یک اثربخش‌تر و قابل‌فهم‌تر است؟
رویکرد مثال-محور
BDD بر نوشتن و توصیف دقیق نیازمندیها با استفاده از مثال‌های واقعی تأکید دارد. همه تلاش این روش بر هرچه بیشتر شفاف کردن فرایندهاست؛ استفاده از سناریوهای متنوع از نحوه رفتار مورد انتظار نرمافزار در موقعیت‌های مختلف کمک میکند تا کار توسعه بر مبنای نحوه تعامل کاربر با نرمافزار پیش برود و نه کارکردهای فنی انتزاعی.
مثال: سناریو باید تا حد امکان واضح نوشته شود؛ «اگر یک کاربر ادمین شود، در زمان بازدید از داشبورد باید بتواند گزینه‌های مدیریت کاربران را ببیند.»
چرخه عمر توسعه رفتار محور
نحوه پیاده‌سازی BDD سه گام کلی دارد:
1. تشریح سناریوها
در قدم اول باید یک رفتار مشخص را با استفاده از فرمت Given-When-Then تعریف کرد.
هر سناریو، یک معیار پذیرش / Acceptance Criteria بسیار شفاف برای توسعه نرمافزار است.
مثال:
سناریوی زیر به شکلی شفاف معیار پذیرش را شرح می‌دهد.
سناریو: اضافه کردن محصول به سبد خرید
اگر کاربر در صفحه محصول باشد.
وقتی بر روی دکمه «افزودن به سبد خرید» کلیک میکند،
محصول باید به سبد خرید او اضافه شود.
2. توصیف گام‌به‌گام
هر مرحله از سناریوی بالا به یک کد متصل میشود که به آن تعریف گام یا Step Definition می‌گویند. هر تعریف گام سناریوهای ساده و قابل فهم را به تست‌اسکریپت‌های قابل اجرا بدل می‌کنند و از این طریق شکاف بین نیازهای تجاری و کار فنی را از میان برمی‌دارند.
مثال بالا در جاوا به شکل زیر خواهد بود:
@Given("the user is on the product page")
public void userOnProductPage() {
driver.get("https://shop.com/product/123");
}
3. تستهای اتوماسیون
سناریوهای BDD به کمک ابزارهایی مانند Cumcumber ،SpecFlow یا JBehave اتوماسیون می‌شوند. این ابزارها سناریوها را بر روی نرمافزار بررسی می‌کنند تا از نحوه عملکرد و رفتار آن اطمینان بیابند. این کار کمک میکند تا نرمافزار به صورت دائمی آزمایش شود.
در این مرحله می‌توان از ابزارهایی مانند Cucumber استفاده کرد تا عملکرد بالا در آن صحت‌سنجی شود.
ابزارهای توسعه رفتار محور
ابزارهای مختلفی برای خودکارسازی سناریوهای BDD و اجرای اسکریپت‌های تست مبتنی بر Gherkin برای تضمین کیفیت نرمافزار / Software QA وجود دارند. محبوب‌ترین آنها عبارتند از:
-
Cucumber: پشتیبانی از چندین زبان برنامه‌نویسی و یکپارچگی با ابزارهایی مانند Selenium
-
SpecFlow: ابزاری مبتنی بر NET. برای نوشتن تست‌ها در C#
-
JBehave: فریمورک BDD برای زبان Java
-
Behat: فریمورک BDD مخصوص PHP برای تست برنامه‌های تحت وب
این ابزارها به تیم‌ها کمک می‌کنند سناریوهای Given-When-Then را خودکارسازی کرده و اعتبارسنجی مداوم رفتار نرمافزار را تضمین کنند.
BBD در برابر TDD: تفاوت‌ها و کاربردها
BBD در واقع از دل TDD یا Test-Driven Development خارج شد؛ روش توسعه تست-محور یا TDD به نوشتن تست پیش از نوشتن کد تأکید دارد. روش TDD اما یک ایراد بزرگ دارد و آن هم وجود تست‌کیس‌های بسیار تکنیکال و فنی است که فهم آن برای غیرتوسعه‌دهندگان آسان نیست. BDD به‌عنوان پاسخی برای این مسئله به‌وجود آمد.
BDD با تمرکز بر تعریف رفتار مورد انتظار به نحوی که همه افراد درگیر در پروژه از جمله توسعهدهندگان، کارشناسان تست و تیم‌های فروش و بازاریابی آن را درک کنند، راهکاری برای حل مسئله TDD ارائه کرد.
توسعه مبتنی بر رفتار / BDD و توسعه مبتنی بر تست / TDD هر دو روش‌هایی برای بهبود کیفیت نرمافزار هستند، اما اهداف و تمرکز آنها متفاوت است.
|
BDD |
TDD |
|
|
تمرکز |
نیازمندی‌های کسب‌وکار و رفتار کاربر |
پیاده‌سازی و منطق کد |
|
نوع تست |
تستهای فیچر (تستهای پذیرش end-to-end) |
تستهای واحد (بررسی اجزای کوچک کد) |
|
هدایت‌شده توسط |
همکاری بین توسعهدهندگان، تسترها و ذینفعان کسب‌وکار |
توسعه‌دهندگانی که روی نوشتن کد تست‌پذیر تمرکز دارند |
|
فرمت تست |
سناریوهای قابل فهم برای انسان (Given-When-Then) |
تستهای واحد در سطح کد که قبل از پیاده‌سازی نوشته می‌شوند |
|
ارتباطات |
استفاده از زبان ساده برای ذینفعان غیر فنی |
نوشته‌شده در زبان‌های برنامه‌نویسی برای توسعهدهندگان |
چه زمانی از هرکدام استفاده کنیم؟
BDD را زمانی استفاده کنید که تمرکز بر نیازهای سطح بالا، رفتار کاربر و اهداف کسب‌وکار باشد. این روش برای تیم‌های چابک که به همکاری بین نقش‌های تجاری و فنی نیاز دارند، ایده‌آل است.
TDD را برای تستهای دقیق در سطح کد به کار ببرید، جایی که توسعهدهندگان نیاز دارند قبل از ادغام بخش‌های مختلف، صحت اجزای کوچک را بررسی کنند.
ترکیب هر دو روش میتواند مؤثر باشد: استفاده از TDD برای نوشتن تستهای واحد قوی و BDD برای تعریف رفتار کلی سیستم و معیارهای پذیرش.
مزیت‌های Behaviour Driven Development
-
ارتباط و هماهنگی بهتر
BDD باعث میشود توسعهدهندگان، تسترها و ذینفعان زبان مشترکی داشته باشند. فرمت Given-When-Then انتظارات را روشن کرده و از سوءتفاهم جلوگیری میکند.
-
پوشش بهتر نیاز کاربران
BDD بر رفتار واقعی کاربران تمرکز دارد؛ این روش تضمین میکند که سناریوهای کلیدی پوشش داده شوند و موارد حیاتی نادیده گرفته نشوند.
-
چرخه‌های توسعه سریعتر
نیازهای شفاف و مورد توافق، از رفت‌و‌برگشت‌های اضافی بین تیم‌ها جلوگیری میکند. تستهای خودکار BDD بازخورد سریع ارائه می‌دهند و توسعه را تسریع می‌کنند.
-
کیفیت بالاتر نرمافزار
BDD با تعریف رفتارهای مورد انتظار از ابتدا، مشکلات را زودتر شناسایی میکند. این امر منجر به کاهش نقصها و بهبود تجربه کاربری میشود.
چالش‌های رایج در BDD و راهکارهای آن
-
نوشتن سناریوهای بیش‌ازحد پیچیده
سناریوهای طولانی و پیچیده، تستهای BDD را دشوار و سخت‌فهم می‌کنند. به جای آن، سناریوها را کوتاه، شفاف و متمرکز بر ارزش کسب‌وکار نگه دارید. هر سناریو باید یک رفتار خاص را آزمایش کند تا خوانایی و کارایی بهتری داشته باشد.
سناریویی که موارد زیادی را به‌صورت هم‌زمان پوشش می‌دهد را به‌‌سختی می‌توان فهمید یا اجرا کرد.
چنین سناریوهایی را به بخش‌های کوچکتر تقسیم کنید؛ هر بخش باید داستان متمرکزی باشد که با ارزش‌های تجاری شما هم‌راستاست.
مثالی از یک سناریوی بد:
«کاربر عضو میشود، ایمیل خود را وریفای میکند، لاگین میکند، پروفایل خود را به‌روزرسانی میکند.»
در حالت استاندارد هر یک از موارد بالا تبدیل به یک سناریوی مجزا میشود.
-
تعریف نامناسب Step Definition
استفاده نامنظم یا تکراری از Step Definitionها میتواند تستهای خودکار را شکننده کند. برای جلوگیری از این مشکل، از واژه‌های استاندارد در گام‌ها استفاده کنید و تعاریف را در سناریوهای مختلف به‌صورت یکپارچه به کار ببرید. نامگذاری مناسب و استفاده از گام‌های ماژولار باعث نگهداری آسان‌تر میشود.
نوشتن Step Definitionهای غیرمنسجم، تکراری یا بسیار وابسته به UI یکی دیگر از چالش‌های رایج در متد BDD است. راهکار آن استفاده Stepهای ماژولار و قابل استفاده مجدد و به‌کارگیری روش‌های نامگذاری رایج است.
«وقتی کاربر بر روی دکمه Submit در فرم صفحه هوم‌پیج کلیک میکند.» یک نمونه بد از Step Definition است؛ نسخه اصلاح‌شده و استاندارد آن به این شکل است: «وقتی کاربر فرم را ثبت میکند.»
-
عدم مشارکت ذینفعان
BDD بر همکاری تأکید دارد، اما اگر ذینفعان کسب‌وکار درگیر نشوند، سناریوها ممکن است نیازهای اصلی را پوشش ندهند. جلسات منظم میان توسعهدهندگان، تستکنندگان و ذینفعان برگزار کنید تا انتظارات مشخص شده و سناریوها بهینه شوند.
عدم حضور فعالانه ذینفعان تجاری در نوشتن سناریوها باعث میشود تا تست‌ها صرفاً بازتابی از ذهنیت توسعه‌دهنده باشند. راه‌حل این مسئله در دخالت دادن مالکین محصول، کارشناسان تست و تحلیل‌گران تجاری پروژه در نوشتن و بازبینی سناریوهاست.
اگر یک توسعه‌دهنده به‌تنهایی مسئول نوشتن سناریو باشد، چیزی شبیه به سناریوی زیر خواهد نوشت: «.Scenario: System returns 200 OK when GET /api/products is called»
در صورتی‌که همین سناریو با حضور تمامی ذینفعان به این شکل در خواهد آمد: «مشتری فهرستی از محصولات در دسترس خواهد دید.» سناریوی دوم با انتظارات کاربر و اهداف تجاری هماهنگ است.
-
اتکای بیش‌ازحد به اتوماسیون
BDD فقط یک ابزار تست خودکار نیست، بلکه یک روش برای بهبود ارتباطات تیمی است. تکیه کامل بر اسکریپت‌های تست بدون درک مشترک، هدف اصلی را از بین می‌برد. تیم‌ها باید ابتدا روی درک مشترک متمرکز شوند و سپس سناریوهای مهم را خودکارسازی کنند.
یکی دیگر از مشکلات رایج این است که تیم‌ها BDD را صرفاً یک تکنیک اتومیشن در نظر گرفته و امکانات برقراری ارتباط آن را نادیده می‌گیرند. از BDD به‌عنوان ابزاری برای ایجاد گفتگو پیش از نوشتن کد بهره بگیرید؛ اتوماسیون باید در مرحله ثانویه اتفاق بیفتد.
در سناریوی خود فقط ننویسید: «کلیک لاگین —--> نمایش داشبورد»؛ ابتدا گفتگو کنید: «اولین چیزی که کاربر نیاز دارد پس از لاگین کردن ببینید، چیست؟ آیا شروطی برای آن وجود دارد؟» صحبت درباره این موارد میتواند شرایط خاص یا قوانین تجاری مهمی را به اعضای تیم یادآور شود.
جمع‌بندی
توسعه رفتار محور باعث بهبود همکاری، افزایش پوشش تست و اطمینان از تطابق نرمافزار با اهداف کسب‌وکار میشود. با تمرکز بر رفتار کاربران و ارتباطات شفاف، BDD به تیم‌های چابک کمک میکند تا محصولات باکیفیت را به‌صورت کارآمد توسعه دهند.
BDD زمانی که به‌درستی استفاده شود، شکاف بین نقش‌های فنی و غیرفنی را پر کرده، توسعه را بهینه کرده و نقصها را کاهش می‌دهد. پذیرش BDD فقط درباره تست نیست، بلکه در مورد ساخت محصولی صحیح، به روش صحیح است.
|
تفکر چابک فقط یک متدولوژی نیست، یک نگاه متفاوت به کار تیمی و حل مسئله است. در اجیلیتی، آموزش Agile با رویکردی عملی، تدریجی و متناسب با فضای کاری تیم‌های ایرانی طراحی شده است.
|