توسعه رفتار محور (BDD) چیست ؟
behavior-driven development (BDD) یا توسعه رفتار محور یک روش برای پروژه‌های نرم‌افزاری سطح بالا است که در آن از تکنیک ”outside-in” یا “بیرون-درون” استفاده می‌شود.
یعنی ابتدا لایه بیرونی که نیازهای تجاری است بررسی می‌شود، سپس موارد مورد نیاز و قابلیت‌ها مشخص می‌شود و درنهایت شاخص‌ها برآورده می‌شوند تا برنامه کار کند.
در این مقاله به بررسی و کاربرد BDDمی پردازیم.
توسعه رفتار محور (BDD) چیست ؟
توسعه نرم‌افزار یا کالای دیجیتال بدون شک یکی از حیاتی‌ترین بخش‌های هر تجارتی است. تکنیک‌هایی وجود دارند که این پروسه را با تقسیم کردن کار به بخش‌های کوچکتر و یافتن راه حل آنها آسان‌تر می‌کنند.
در این فاز، بیشتر تیم‌ها یکی از عناصر کلیدی موفقیت پروژه که برآورده کردن نیازهای تجاری است را فراموش می‌کنند.
یک ایده تجاری می‌تواند عملی نشده باشد، بنابراین می‌تواند یافتن یک راه حل خوب را سخت کند. برای غلبه کردن بر چنین مشکلاتی همیشه پروسه توسعه با یک ایده شروع می‌شود چنین ایده‌هایی نمایانگر هدف اصلی ما هستند و چرخه توسعه نرم‌افزار را قوی‌تر می‌کنند.
در توسعه رفتار محور، قدم اول ما تبدیل ایده‌ها به نیازهای بین لایه بیرونی و درونی است. (که معمولاً از آن با عنوان سطح میانی یاد می‌شود)
برای مثال اگر یک تحلیلگر تجاری می‌گوید که باید ارتباط کاربر با محصول در یک مورد خاص بیشتر شود، نیاز ما ساختن سرویسی است که کاربر به وسیله آن بتواند بعد از ورود به وب سایت، بازخورد خود را ارائه دهد.
پس در اینجا دو نیاز مشخص می‌شود :
- سیستم هویت سنجی کاربر – کاربر باید بتواند وارد سیستم شود.
۲. بازخورد در مورد هر محصول – کاربر باید بتواند بازخورد خود را ارائه دهد.
همچنین ما در اینجا نیازها را به صورتی که برای همه قابل فهم باشد مشخص می‌کنیم . برای رسیدن به چنین انعطاف پذیری از یک پیاده سازی گزارش محور استفاده می‌کنیم. گزارش مانند یک زبان طبیعی که برای همه قابل فهم است عمل می‌کند و با یک نتیجه پیش‌بینی شده توصیف می‌شود و این به برنامه نویس کمک می‌کند تا مشکل واقعی را پیدا کند.
توسعه رفتار محور شبیه به توسعه تست محور (TTD) می‌باشد ولی به بحث‌های بین اعضای گروه توجه دارد.
نقش مشخصات نرم‌افزار در توسعه رفتار محور
در قبل بیان کردیم که گزارش، نقش حیاتی در چرخه توسعه نرم‌افزار ایفا می‌کند. ولی بخش دیگری از توسعه رفتار محور وجود دارد که در آن از مشخصات بیشتر از گزارش استفاده می‌شود.
به همراه مشخصات، بیشتر از “مورد استفاده” یک مشکل خاص به “عملکرد” آن توجه می‌کنیم. که به دلایل روشن تکنیکی‌تر است و کارکنان تجاری کمتر از آن استفاده می کنند.
اگر در مورد هویت سنجی کاربر کار کنیم، در مورد مشخصات می‌توان به موارد مورد نیاز برای وارد شدن کاربر اشاره کرد. این مشخصات می‌توانند نام، رمز عبور، ایمیل و … باشند. سپس بررسی می‌کنیم که نشانه‌ها چگونه باید ساخته شوند و چگونه اعتبار سنجی شوند تا هویت‌سنجی انجام شود.
اما در هنگام نوشتن این مشخصات باید مراقب بود. آنها باید به آسانی قابل خواندن باشند و تست‌های شما باید کوچک باشند و نه کل برنامه بلکه یک بخش را مورد امتحان قرار دهند.
تست‌ها باید جملات ساده و در چارچوب‌های تستی باشند که این کار را اتوماتیک برای شما انجام دهند.
برای چه باید از گزارش‌ها در توسعه رفتار محور استفاده کرد؟
در توسعه رفتار محور موضوع و هدف اصلی ما برقرای ارتباط بین علایق تجاری و فهم تکنیک هاست.
بنابراین نیازها از یک دیدگاه تجاری ایجاد می شوند و با راه حل های تکنیکی برطرف می‌شوند. برای برطرف کردن نیازها یک فهم درست از آنها وجود دارد بنابراین یک سناریو ایجاد می‌شود که در آن عمل و نقش را مشخص می‌شود و بر پایه آن نتیجه پیش‌بینی می‌شود. به طور خلاصه، یک گزارش کاربر با عمل‌ها و نتیجه‌های پیش‌بینی شده ایجاد می‌شود.
گزارش کاربر از جهت‌های بسیاری به شما کمک می‌کند:
به نهایی کردن نیازهای کارکرد یک برنامه کمک می‌کند.
قابلیت‌هایی که به رسیدن به هدف کمک می‌کنند را مشخص می‌کند.
مثال‌های واقعی ایراد‌ها و موارد غیر متمرکز کار را از بین می‌برند.
به توسعه موارد امتحانی برای نرم‌افزار کمک می‌کند.
چگونگی استفاده از گزارش کاربر در توسعه رفتار محور
هنگام پیاده‌سازی توسعه رفتار محور، از قوانین از قبل تعریف شده پیروی می‌شود. بنابراین برای نوشتن گزارش خود سناریوهای خاصی را تعریف می‌کنیم و بر پایه آنها، از قالبی به نام Gherkin language برای توسعه قابلیت‌ها استفاده می‌شود.
چگونگی استفاده از گزارش کاربر در توسعه رفتار محور
برای مثال :
قابلیت : ارائه بازخورد
سناریو : کاربر بتواند وارد برنامه بشود.
ارائه شده : جدول “کاربر‌ها” خالی می‌شود.
و کاربر‌های داخل تصویر زیر تعریف می‌شوند و وقتی از نام کاربری و رمز عبور فوق استفاده می‌شود کاربر وارد شده است.
یک مثال معمول از قالب گزارش کاربر:
برای فهم مثال‌های قبل به مثال‌های گذشته توجه می‌کنیم. هدف ما افزایش ارتباط کاربر با نرم‌افزار است. بنابراین این قابلیت را “بازخورد” می‌نامیم و بعد از تعریف کردن قابلیت در مورد سناریوهای خود صحبت می‌کنیم. سناریوها بخشی از گزارش هستند که عمل را مشخص می‌کنند و انتظار یک خروجی را دارند.
برای هر سناریو احتیاج به تعریف کردن موارد زیر داریم :
“scenario” : مشخص کردن عمل
“given” : مشخص کردن نقش
“And” : هر متنی
“when” : هر رویدادی
“then” : هر نتیجه‌ای
موارد بالا مروری بر نحوه تعریف کردن یک سناریو بود .
برای یک قابلیت چند سناریو می‌تواند موجود باشد. دستورالعمل نشان داده شده یک نمونه از قابلیت “cucumber” است که یک ابزار توسعه رفتار محور بر پایه “Gherkin” برای JavaScript می‌باشد. مانند این ابزار، ابزارهای دیگر برای زبان‌های مختلف وجود دارند.
برای مثال “Jasmine” برای زبان برنامه‌نویسی JavaScript وجود دارد. اگر کد شما باید به نحوه مشخصی کار کند “Jasmine” به شما کمک می کند تا هدف را در کد خود بیان کنید. “Jasmine” قابلیت‌های کاربردی زیادی مانند “nested suits” ،”matching class names” و… دارد.
چه چیزی باعث می‌شود که گزارش کاربر خوب باشد؟
یک گزارش کاربری تا زمانی خوب است که سناریوهای دقیق و پر جزئیات دارد و باید همه سناریوهای ممکن را پوشش دهد تا فهم بهتری از کارکرد نرم‌افزار وجود داشته باشد. این شامل همه موارد و ایراد‌های غیرمتمرکز است.
نکته اصلی دیگر این است که گزارش باید به حدی کوچک باشد که در اصل تکراری جلوه دهد و این بدین معناست که بتوانیم مشکل بزرگتر را به مشکل‌های کوچکتر تقسیم کنیم و سپس تمام مشکل‌های کوچکتر را با سناریوها حل کنیم تا نیازها تامین شوند.
در نتیجه، یک تیم تجاری می‌تواند کار را درک کند و به آسانی پیشرفت و بازده آن را در توسعه حس کند.
زمانی که گزارش کاربر تمام می‌شود
زمانی که گزارش کاربر وسناریوهای ممکن را نهایی می‌کنیم، پروسه توسعه نرم‌افزارمان را با تکرار سناریوها و تحقق یک به یک آنها شروع می‌کنیم.
به بیان دیگر، نرم‌افزار ارائه شده باید تمامی آزمون‌های نوشته شده توسط خودمان به عنوان قابلیت‌ها وسناریو‌ها را با موفقیت پشت سر بگذارد.
شاید تجعب کنید که برنامه‌نویس‌ها چگونه این قابلیت‌ها و سناریوها را به تست‌ها تبدیل می‌کنند؟ در بیشتر مواقع این جمله‌ها دریافت و تبدیل به عملکردهای نقشه‌برداری شده می‌کنند. بنابراین زمانی که آزمون‌ها شروع می‌شوند، عملکردهای نقشه برداری شده راه اندازی می‌شوند و باعث شروع نرم‌افزار با آزمون‌های ارائه شده می‌شوند.