احتمالاً برای شما هم پیش آمده است که پس از ماهها تلاش بیوقفه برای توسعه یک ویژگی جدید در نرمافزار، مدیر محصول یا کارفرما به خروجی نگاهی انداخته و بگوید: «این چیزی نبود که من میخواستم!». این سوءتفاهمهای پرهزینه، کابوس همیشگی و دردناک تیمهای برنامهنویسی هستند. وقتی توسعهدهندگان به زبان کد و متغیرها صحبت میکنند و ذینفعان تجاری به زبان فروش و فرآیندهای کسبوکار، شکاف ارتباطی عمیقی شکل میگیرد که خروجی آن چیزی جز بودجه بر باد رفته نیست.
اینجاست که رویکرد توسعه مبتنی بر رفتار یا BDD (Behavior-Driven Development) و ابزار قدرتمند Cucumber بهعنوان یک فرشته نجات وارد میدان میشوند. این دو با هم عهد بستهاند تا تستها و نیازمندیهای نرمافزار را به زبانی بنویسند که برای انسانها، صرفنظر از میزان دانش برنامهنویسیشان، کاملاً قابل درک باشد. در این مقاله به زبان ساده، نحوه کارکرد این متدولوژی را بررسی خواهیم کرد.
توسعه مبتنی بر رفتار (BDD) چیست؟
توسعه مبتنی بر رفتار (BDD)، یک متدولوژی و رویکرد چابک (Agile) در توسعه نرمافزار است که تمرکز اصلی خود را بر روی «رفتار مورد انتظار سیستم از دید کاربر» قرار میدهد. در فرآیندهای سنتی، برنامهنویسان سریعا شروع به کدنویسی کرده و سپس تستهایی را برای کدهای خود مینویسند؛ اما در BDD، قبل از نوشتن حتی یک خط کد، تمام اعضای تیم روی این موضوع توافق میکنند که نرمافزار در شرایط مختلف دقیقا باید چه رفتاری از خود نشان دهد.
هدف غایی رویکرد BDD، ایجاد یک «زبان مشترک همه جا حاضر» (Ubiquitous Language) است. در این فرآیند مفهومی به نام «سه یار» یا The Three Amigos وجود دارد که شامل توسعهدهنده، تستر (تیم QA) و مدیر محصول است. این سه گروه دور هم جمع میشوند و با زبانی ساده، داستان رفتار نرمافزار را مینویسند.
تفاوتهای بنیادین TDD و BDD در یک نگاه
اگر با دنیای برنامهنویسی آشنا باشید حتماً نام TDD (توسعه مبتنی بر تست) را شنیدهاید. BDD در واقع تکاملیافته همین روش است اما تفاوتهای استراتژیکی با آن دارد:
| معیار تفاوت | رویکرد TDD (Test-Driven Development) | رویکرد BDD (Behavior-Driven Development) |
|---|---|---|
| تمرکز اصلی | تمرکز بر نحوه پیادهسازی فنی و اجرای بدون خطای کدها | تمرکز بر رفتار کسبوکاری سیستم و نیت کاربر نهایی |
| زبان نوشتن تست | زبانهای برنامهنویسی پیچیده (جاوا، سیشارپ، پایتون) | زبان طبیعی و انسانی، خوانا برای همه (فارسی، انگلیسی) |
| مخاطبین | صرفاً برنامهنویسان و توسعهدهندگان سیستم | تمامی اعضای پروژه (توسعهدهندگان، سهامداران، مدیران) |
| ابزارهای مدیریت | ابزارهایی نظیر NUnit, PyTest, JUnit | فریمورکهایی نظیر Cucumber, SpecFlow, Behave |
ابزار Cucumber چیست و چه معجزهای میکند؟
کیوکامبر (Cucumber) محبوبترین فریمورک متنباز (Open-Source) است که از متدولوژی BDD در پروژههای نرمافزاری پشتیبانی میکند. وظیفه اصلی این ابزار، خواندن مشخصات و رفتارهایی است که به زبان ساده انسانی نوشته شدهاند و سپس، اجرای خودکار آنها بهعنوان تستهای نرمافزاری است!
کیوکامبر این امکان بینظیر را فراهم میکند که مستندات و نیازمندیهای پروژه شما دقیقا همان کدهای تست شما باشند. این بدان معناست که وقتی نیازمندی جدیدی اضافه میشود، تست جدیدی نوشته شده و اصطلاحاً «مستندات زنده» (Living Documentation) شکل میگیرد. مستندات زنده هرگز منسوخ نمیشوند، زیرا با هر بار اجرای پروژه، در کنار کدها بررسی میشوند تا صحت ادعای آنها ثابت شود.
زبان گرکین (Gherkin): جادوی نوشتن تست به زبان انسان
قلب تپنده ابزار Cucumber، زبانی به نام Gherkin است. گرکین یک زبان ساختاریافته اما بسیار راحت است که با استفاده از چند کلمه کلیدی، رفتار نرمافزار را توصیف میکند.
این زبان به قدری شبیه به محاورات روزمره است که تحلیلگران سیستم بدون نیاز به دانش برنامهنویسی، میتوانند سناریوهای تست خودکار را طراحی کنند. ساختار اساسی Gherkin بر پایه سه کلمه کلیدی اصلی استوار است:
- فرض کن (Given): وضعیت اولیه سیستم، پیشنیازها و پیششرطهایی که کاربر قبل از انجام کار دارد را مشخص میکند.
- هنگامی که (When): اکشن، اقدام یا رویدادی که کاربر در سیستم انجام میدهد را توصیف میکند (مثل کلیک کردن).
- آنگاه (Then): نتیجه یا خروجی قطعی مورد انتظار پس از انجام آن اکشن خاص را بیان میکند.
جهت ارتباط دادن شروط مختلف نیز از کلمات تکمیلی And (و) و But (اما) استفاده میشود تا جملات برای خواندن روانتر باشند.
سینتکس عملی: نمونه یک داستان با فرمت Gherkin
فرض کنید در حال طراحی بخش «ورود» یک اپلیکیشن مالی هستیم. فایل Feature (ویژگی) نوشته شده با گرکین، چیزی شبیه به این خواهد بود:
ویژگی (Feature): ورود به حساب کاربری سایتبه عنوان یک کاربر عضو سایت، میخواهم وارد حساب کاربری خود شوم تا بتوانم موجودی حسابم را ببینم.
سناریو (Scenario): ورود موفقیتآمیز به سیستم با اطلاعات معتبرGiven (فرض کن): کاربر روی صفحه لاگین سیستم قرار داردAnd (و): نام کاربری “user@email.com” و رمز عبور “۱۲۳۴۵۶” را در کادرها وارد کرده استWhen (هنگامی که): کاربر روی دکمه “ورود به حساب” کلیک میکندThen (آنگاه): کاربر باید به صفحه داشبورد کاربری منتقل شودAnd (و): پیام “ورود شما موفقیت آمیز بود” را مشاهده کند
میبینید که خواندن این متن برای یک مدیر پروژه، کارشناس فروش، یا توسعهدهنده بکاند دقیقاً معنای یکسانی دارد و جای هیچ ابهامی را باقی نمیگذارد.
Cucumber چگونه جملات انسانی را به کد تبدیل میکند؟ (Step Definitions)
شاید بپرسید سیستم چگونه میفهمد که دکمه “ورود” چیست و کلیک کردن چه معنایی دارد؟ اینجا دقیقا همان جایی است که مهارت برنامهنویسان به کار میآید. پس از نگارش فایل Gherkin، برنامهنویسان باید اتصالی بین خطوط متن و کدهای واقعی برقرار کنند.
این پیوند از طریق مفهومی به نام «تعریف گامها» یا Step Definitions انجام میشود. وقتی Cucumber سناریوی نوشته شده شما را میخواند، در کدهای پروژه به دنبال تابعی میگردد که دقیقاً با عبارت نوشته شده (مثلا: “کاربر روی صفحه لاگین سیستم قرار دارد”) مطابقت داشته باشد.
با پیدا شدن این تطابق، فریمورکهای تست اتوماتیک که پشت پرده قرار دارند (مانند Selenium یا Cypress برای وبسایت، و Appium برای موبایل) مرورگر را باز کرده و دقیقاً همان کارهای انسانی را روی سایت شما شبیهسازی میکنند. اگر فرآیند تا کلمه Then بدون خطا رفت و نتیجه برابر خواستهی مدیر بود، تست پاس میشود (سبز)، وگرنه شکست میخورد (قرمز).
۵ مزیت شگفتانگیز استفاده از BDD و Cucumber
روی آوردن به این ساختار، تنها اضافه کردن یک ابزار فنی جدید نیست؛ بلکه یک تغییر و بلوغ در فرهنگ سازمانی تیم نرمافزاری است. مهمترین مزیتهای آن شامل موارد زیر است:
- وضوح صد درصدی نیازمندیها: قبل از هدر رفتن زمان برنامهنویس، همه میدانند که دقیقاً چه چیزی باید ساخته شود.
- مستندسازی که هرگز دروغ نمیگوید: فایلهای Feature در حقیقت همان مستندات نرمافزار شما هستند که با کدهای واقعی تست میشوند؛ بنابراین امکان ندارد مستندات چیزی بگوید و نرمافزار کار دیگری کند.
- کاهش چشمگیر دوبارهکاری و باگها: وقتی رفتار سیستم بهطور اتوماتیک تست میشود، ریسک بروز باگهای پیچیده در محیط عملیاتی (Production) به شدت افت میکند.
- کدها قابلیت استفاده مجدد دارند: مراحل یا همان Step Definitionها را میتوان در دهها سناریوی مختلف استفاده کرد. (مثلا “ورود به حساب” میتواند در ۱۰۰ تست دیگر به عنوان پیشنیاز استفاده شود).
- تفکر کاربرمحور: به جای تمرکز بر جداول دیتابیس یا سرور، تمام تمرکز تیم معطوف به سفر مشتری (Customer Journey) و تجربه کاربری میشود.
سوالات متداول
۱. آیا یادگیری زبان Gherkin برای مدیران محصول و افراد غیرفنی سخت است؟بههیچوجه. گرکین فاقد متغیر، حلقههای تکرار (Loop) و ساختارهای برنامهنویسی است. این زبان صرفاً از کلمات عادی و قواعد معنایی مشخص پیروی میکند و یادگیری اصول آن برای هرکسی کمتر از چند ساعت زمان میبرد.
۲. آیا Cucumber رقیب Selenium است؟خیر، این دو ابزار مکمل یکدیگرند. Cucumber سناریوهای متنی و انسانی را مدیریت و زمانبندی میکند، در حالی که Selenium وظیفه دارد آن سناریوها را روی مرورگر واقعی (مثل کروم یا فایرفاکس) اجرا کند و دکمهها را به صورت فیزیکی کلیک کند.
۳. تفاوت مهم ابزار Cucumber با SpecFlow در چیست؟هر دو از محبوبترین ابزارهای BDD در جهان خوانده میشوند. تفاوت اصلی در پلتفرم پیادهسازی آنهاست؛ Cucumber در ابتدا برای Ruby ساخته شد و سپس جاوا و جاوا اسکریپت را پوشش داد. اما SpecFlow پیادهسازی رسمی متدولوژی BDD مختص تکنولوژیهای مایکروسافت (C# و داتنت) است.
۴. اجرای BDD و نوشتن تستهای Cucumber زمانبر نیست؟در ابتدای راهاندازی پروژه و به دلیل زمانبر بودن جلسات توافق برای نوشتن سناریوها، ممکن است کند به نظر برسد؛ اما در بلندمدت نرخ بازگشت سرمایه (ROI) فوقالعادهای دارد. رفع اتوماتیک باگها در مراحل اولیه به مراتب ارزانتر از رفع آنها در محصول نهایی است.
۵. آیا میتوان فایلهای سناریو (Gherkin) را کاملاً به زبان فارسی نوشت؟بله، یکی از جذابترین قابلیتهای Cucumber پشتیبانی بومی از بیش از ۷۰ زبان زنده دنیا از جمله فارسی است. با اضافه کردن تگِ # language: fa در ابتدای فایل، میتوانید مستقیماً از عبارات «فرض کن»، «هنگامی که» و «آنگاه» استفاده کنید که برای تیمهای ایرانی فوقالعاده کاربردی است.
نتیجهگیری
شکست پروژههای نرمافزاری بیشتر از آنکه به دلیل معماریهای ضعیف برنامهنویسی باشد، به دلیل ضعف در ارتباطات انسانی بین تیمهاست. متدولوژی BDD و ابزار منحصربهفرد Cucumber این چالش دیرینه را از بین بردهاند. با قابلیت جذاب نوشتن تستهای اتوماتیک به زبان ساده انسانها با استفاده از Gherkin، مرز بین کارفرمای غیرفنی و برنامهنویسانِ کدمحور به طور کامل برداشته میشود و محصولی متولد خواهد شد که دقیقاً پاسخگوی نیاز بازار است.
اگر شما هم در پروژههای توسعه نرمافزاری خود چالش درک نشدن نیازمندیها و بازنویسی کدهای تکراری را تجربه کردهاید، پیادهسازی گام به گام Cucumber در سازمانتان میتواند بهترین سرمایهگذاری امسال شما باشد. آیا تاکنون از رویکرد BDD در تیم خود استفاده کردهاید؟ دستاوردها یا موانع خود را در بخش نظرات با ما در میان بگذارید تا سایر کاربران نیز از تجربیات ارزشمند شما بهرهمند شوند.
