تست نرم افزار, سطوح تست

BDD در عمل: نوشتن سناریوهای گرکین قابل فهم برای توسعه‌دهندگان و کسب‌وکار

انتشار در تاریخ توسط محمد عسکری

فهرست مطالب

در دنیای پیچیده و پویای توسعه نرم‌افزار، یکی از بزرگترین چالش‌ها، ایجاد درک مشترک بین ذینفعان مختلف پروژه، به‌ویژه تیم کسب‌وکار و تیم فنی است. توسعه رفتار محور (Behavior-Driven Development یا BDD) به عنوان یک رویکرد قدرتمند برای پر کردن این شکاف ارتباطی ظهور کرده است. قلب تپنده BDD، زبان گرکین (Gherkin) است که به تیم‌ها اجازه می‌دهد نیازمندی‌ها و رفتار سیستم را به زبانی ساده، قابل فهم و قابل اجرا تعریف کنند. این مقاله به بررسی عمیق چگونگی نوشتن سناریوهای گرکین مؤثر می‌پردازد که هم برای توسعه‌دهندگان و هم برای صاحبان کسب‌وکار، شفاف و کاربردی باشد.

BDD چیست؟ فراتر از یک ابزار تست

توسعه رفتار محور (BDD) یک فرآیند توسعه نرم‌افزار چابک است که همکاری بین توسعه‌دهندگان، کارشناسان تضمین کیفیت (QA)، تحلیلگران کسب‌وکار و صاحبان محصول را تشویق می‌کند. BDD از توسعه آزمون محور (Test-Driven Development یا TDD) تکامل یافته و بر تعریف رفتار سیستم از دیدگاه کاربر و کسب‌وکار تمرکز دارد.

اصول کلیدی BDD عبارتند از:

  • همکاری مداوم: ایجاد یک زبان مشترک و درک واحد از نیازمندی‌ها بین تمام اعضای تیم.
  • تمرکز بر رفتار: تعریف چگونگی رفتار نرم‌افزار در شرایط مختلف از دیدگاه کاربر.
  • مثال‌های مشخص: استفاده از مثال‌های واقعی برای توصیف رفتار مورد انتظار.
  • مستندات زنده: سناریوهای BDD به عنوان مستنداتی عمل می‌کنند که همواره با کد همگام هستند.

برخلاف تصور رایج، BDD تنها یک تکنیک تست نویسی نیست، بلکه یک فلسفه برای هدایت فرآیند توسعه از طریق گفتگو و مثال‌های مشخص است. هدف نهایی، تولید نرم‌افزاری است که دقیقاً همان چیزی باشد که کسب‌وکار نیاز دارد و کاربران انتظارش را دارند.

گرکین: زبان مشترک تیم

گرکین یک زبان خاص دامنه (Domain-Specific Language یا DSL) با ساختاری ساده و خوانا است که برای نوشتن سناریوهای BDD استفاده می‌شود. این زبان به گونه‌ای طراحی شده که توسط افراد غیرفنی نیز به راحتی قابل درک باشد. ساختار اصلی یک سناریوی گرکین از کلمات کلیدی خاصی تشکیل شده است:

  • Feature (ویژگی): توصیف کلی یک قابلیت یا ویژگی نرم‌افزار.
  • Scenario (سناریو): توصیف یک رفتار خاص در قالب یک مثال.
  • Given (با فرض این‌که): شرایط اولیه یا پیش‌نیازهای سناریو را مشخص می‌کند.
  • When (هنگامی‌که): اقدام یا عملی که توسط کاربر یا سیستم انجام می‌شود را توصیف می‌کند.
  • Then (آنگاه): نتیجه یا خروجی مورد انتظار پس از انجام عمل را بیان می‌کند.
  • And (و) و But (اما): برای افزودن چندین شرط Given، When یا Then به کار می‌روند و خوانایی را افزایش می‌دهند.
  • Background (پس‌زمینه): مجموعه‌ای از گام‌های Given که برای تمامی سناریوهای یک Feature مشترک هستند.
  • Scenario Outline (طرح کلی سناریو) و Examples (مثال‌ها): برای اجرای یک سناریو با مجموعه‌ای از داده‌های مختلف استفاده می‌شود.

استفاده از گرکین به تیم‌ها کمک می‌کند تا از ابهامات و سوءتفاهم‌های ناشی از تفسیرهای متفاوت نیازمندی‌ها جلوگیری کنند.

چرا سناریوهای گرکین برای همه مهم هستند؟

نوشتن سناریوهای گرکین که به خوبی طراحی شده باشند، مزایای متعددی برای تمام اعضای تیم به همراه دارد:

  • برای تحلیلگران کسب‌وکار و صاحبان محصول:
    • شفافیت نیازمندی‌ها: تبدیل نیازمندی‌های پیچیده به مثال‌های قابل فهم.
    • اعتبارسنجی سریع: امکان بررسی و تأیید صحت رفتار مورد انتظار قبل از شروع کدنویسی.
    • کاهش دوباره‌کاری: اطمینان از اینکه محصول نهایی با اهداف کسب‌وکار همسو است.
  • برای توسعه‌دهندگان:
    • درک واضح از نیازمندی‌ها: دقیقاً می‌دانند چه چیزی باید ساخته شود.
    • راهنمای پیاده‌سازی: سناریوها به عنوان مشخصات قابل اجرا عمل می‌کنند.
    • تسهیل تست واحد و یکپارچه‌سازی: چارچوبی برای نوشتن تست‌های خودکار فراهم می‌کند.
  • برای مهندسان تضمین کیفیت (QA):
    • مبنای تست‌های پذیرش: سناریوها مستقیماً به موارد تست قابل خودکارسازی تبدیل می‌شوند.
    • پوشش جامع تست: اطمینان از اینکه تمام رفتارهای کلیدی سیستم تست شده‌اند.
    • ارتباط مؤثرتر با تیم: درک مشترک از معیارهای پذیرش.
  • برای کل تیم:
    • زبان مشترک (Ubiquitous Language): ایجاد یک واژگان مشترک که توسط همه اعضای تیم درک می‌شود.
    • مستندات زنده و پویا: سناریوها همواره به‌روز هستند و وضعیت فعلی سیستم را منعکس می‌کنند.
    • افزایش کیفیت نرم‌افزار: با تمرکز بر رفتار و تست مداوم.

اصول نوشتن سناریوهای گرکین مؤثر

نوشتن سناریوهای گرکین که هم برای کسب‌وکار قابل فهم باشد و هم برای توسعه‌دهندگان مبنای کار فنی قرار گیرد، نیازمند رعایت اصولی خاص است. در ادامه به مهم‌ترین این اصول می‌پردازیم:

  1. تمرکز بر رفتار، نه پیاده‌سازی (Focus on Behavior, Not Implementation):
    • سناریوها باید توصیف کنند که سیستم چه کاری انجام می‌دهد، نه اینکه چگونه آن کار را انجام می‌دهد. از ذکر جزئیات فنی، نام کنترل‌های رابط کاربری (مانند “روی دکمه آبی کلیک کن”) یا ساختار پایگاه داده خودداری کنید.
    • مثال بد:
Given کاربر در صفحه "login.aspx" است
When کاربر نام کاربری را در تکست باکس "txtUsername" وارد می‌کند
And کاربر رمز عبور را در تکست باکس "txtPassword" وارد می‌کند
And کاربر روی دکمه "btnLogin" کلیک می‌کند
Then کاربر به صفحه "dashboard.aspx" هدایت می‌شود
  1. مثال خوب:
Given کاربر در صفحه ورود قرار دارد
When کاربر با مشخصات معتبر خود وارد سیستم می‌شود
Then کاربر باید به داشبورد شخصی خود دسترسی پیدا کند
  1. استفاده از زبان کسب‌وکار (Use Business Language / Ubiquitous Language):
    • سناریوها باید با استفاده از واژگان و اصطلاحاتی نوشته شوند که برای تمام ذینفعان، به‌ویژه افراد غیرفنی، قابل درک باشد. این همان “زبان مشترک” است که در Domain-Driven Design (DDD) نیز بر آن تأکید می‌شود.
    • از اصطلاحات فنی و تخصصی که تنها برای توسعه‌دهندگان مفهوم دارد، پرهیز کنید.
  2. یک سناریو، یک رفتار (One Scenario, One Behavior):
    • هر سناریو باید تنها یک قانون کسب‌وکار یا یک رفتار خاص را پوشش دهد. این کار باعث می‌شود سناریوها کوتاه‌تر، متمرکزتر و قابل مدیریت‌تر باشند.
    • اگر یک سناریو چندین “Then” با منطق‌های متفاوت دارد، احتمالاً بهتر است به چند سناریوی مجزا شکسته شود.
  3. قانون اول شخص و دیدگاه کاربر (First Person Rule and User Perspective):
    • سناریوها را از دیدگاه کاربر یا یک نقش خاص در سیستم بنویسید. استفاده از عباراتی مانند “کاربر می‌خواهد…” یا توصیف اقدامات از دیدگاه یک پرسونای مشخص، به درک بهتر زمینه کمک می‌کند.
    • اگرچه گرکین به طور ذاتی اول شخص نیست، اما تفکر از منظر کاربر به نوشتن سناریوهای بهتر کمک می‌کند.
  4. واضح و بدون ابهام (Clear and Unambiguous):
    • از کلمات و عباراتی استفاده کنید که تفسیر دوگانه‌ای نداشته باشند. هر گام در سناریو باید به طور دقیق و شفاف بیان شود.
    • از ضمایر مبهم (مانند “آن”، “این”) که مشخص نیست به چه چیزی اشاره دارند، خودداری کنید.
  5. استفاده از مثال‌های واقعی (Use Real Examples – Scenario Outlines):
    • هنگامی که یک رفتار باید با داده‌های ورودی مختلف تست شود، از Scenario Outline به همراه جدول Examples استفاده کنید. این کار از تکرار سناریوهای مشابه جلوگیری کرده و خوانایی را افزایش می‌دهد.
    • مثال:
Feature: برداشت از حساب بانکی
  Scenario Outline: برداشت موفق از حساب با موجودی کافی
    Given موجودی اولیه حساب <account_type> من <initial_balance> ریال است
    When من درخواست برداشت <withdrawal_amount> ریال از حسابم را ثبت می‌کنم
    Then موجودی نهایی حساب من باید <final_balance> ریال باشد
    And پیام "<message>" باید نمایش داده شود

    Examples:
      | account_type | initial_balance | withdrawal_amount | final_balance | message                |
      | "جاری"       | 1000000         | 200000            | 800000        | "برداشت با موفقیت انجام شد" |
      | "پس‌انداز"    | 500000          | 500000            | 0             | "برداشت با موفقیت انجام شد" |
  1. قابل تست بودن (Testability):
    • هر گام در سناریو، به‌ویژه عبارت Then، باید به گونه‌ای نوشته شود که قابل تأیید و تست خودکار باشد. یعنی بتوان به طور قطعی مشخص کرد که آیا نتیجه مورد انتظار رخ داده است یا خیر.
  2. نقش Background:
    • اگر مجموعه‌ای از گام‌های Given در تمامی یا اکثر سناریوهای یک Feature تکرار می‌شوند، آن‌ها را در بخش Background قرار دهید. این کار از تکرار جلوگیری کرده و سناریوها را کوتاه‌تر می‌کند.
    • مثال:
Feature: مدیریت سبد خرید

  Background:
    Given کاربر وارد سیستم شده است
    And کاربر یک محصول به سبد خرید خود اضافه کرده است

  Scenario: مشاهده سبد خرید
    When کاربر به صفحه سبد خرید می‌رود
    Then کاربر باید محصول اضافه شده را در سبد خرید مشاهده کند

  Scenario: حذف محصول از سبد خرید
    When کاربر محصول را از سبد خرید حذف می‌کند
    Then سبد خرید کاربر باید خالی باشد

مثال‌های عملی از سناریوهای گرکین

مثال ۱: ورود کاربر (ساده)

Feature: ورود کاربر به سیستم

  Scenario: ورود موفق کاربر با اطلاعات صحیح
    Given کاربر در صفحه ورود قرار دارد
    When کاربر نام کاربری "testuser" و رمز عبور "P@ssword123" را وارد می‌کند
    And بر روی دکمه "ورود" کلیک می‌کند
    Then کاربر باید به صفحه اصلی هدایت شود
    And پیام خوش‌آمدگویی "خوش آمدید, testuser!" نمایش داده شود

  Scenario: ورود ناموفق کاربر با رمز عبور اشتباه
    Given کاربر در صفحه ورود قرار دارد
    When کاربر نام کاربری "testuser" و رمز عبور "WrongPassword" را وارد می‌کند
    And بر روی دکمه "ورود" کلیک می‌کند
    Then کاربر باید در همان صفحه ورود باقی بماند
    And پیام خطا "نام کاربری یا رمز عبور اشتباه است." نمایش داده شود

مثال ۲: جستجوی محصول (با جزئیات بیشتر از دیدگاه کسب‌وکار)

Feature: جستجوی محصول توسط مشتری

  Scenario: مشتری یک محصول موجود را جستجو می‌کند
    Given مشتری در صفحه اصلی فروشگاه قرار دارد
    And محصولی با نام "لپ تاپ مدل X" و برند "ABC" در سیستم موجود است
    When مشتری عبارت "لپ تاپ ABC" را در نوار جستجو وارد می‌کند
    And دکمه جستجو را فشار می‌دهد
    Then نتایج جستجو باید شامل "لپ تاپ مدل X" باشد
    And مشتری باید بتواند جزئیات محصول "لپ تاپ مدل X" را مشاهده کند

  Scenario: مشتری یک محصول ناموجود را جستجو می‌کند
    Given مشتری در صفحه اصلی فروشگاه قرار دارد
    When مشتری عبارت "محصول خیالی ZZZ" را در نوار جستجو وارد می‌کند
    And دکمه جستجو را فشار می‌دهد
    Then پیام "محصولی با این مشخصات یافت نشد." باید نمایش داده شود
    And هیچ محصولی در لیست نتایج جستجو نمایش داده نشود

اشتباهات رایج در نوشتن سناریوهای گرکین

  • بیش از حد فنی بودن: استفاده از جزئیات پیاده‌سازی به جای توصیف رفتار.
  • بیش از حد مبهم بودن: عدم ارائه جزئیات کافی برای درک دقیق سناریو.
  • توصیف چندین رفتار در یک سناریو: هر سناریو باید روی یک جنبه خاص متمرکز باشد.
  • عدم استفاده از زبان کسب‌وکار: استفاده از اصطلاحات فنی که برای ذینفعان غیرفنی نامفهوم است.
  • نوشتن سناریوهای غیرقابل تست: تعریف نتایجی که به طور عینی قابل بررسی نیستند.
  • استفاده بیش از حد از And: گاهی اوقات باعث طولانی شدن بیش از حد گام‌ها و کاهش خوانایی می‌شود. بهتر است گام‌ها کوتاه و متمرکز باشند.
  • تست کردن رابط کاربری به جای رفتار: سناریوهای BDD نباید اسکریپت‌های کلیک کردن روی دکمه‌ها باشند، بلکه باید رفتار کسب‌وکار را تأیید کنند.

BDD و گرکین در چرخه توسعه نرم‌افزار

BDD و گرکین تنها به مرحله تست محدود نمی‌شوند، بلکه در تمام چرخه عمر توسعه نرم‌افزار نقش دارند:

  1. فاز کشف (Discovery): جلسات “سه رفیق” (Three Amigos) – نماینده کسب‌وکار، توسعه‌دهنده و تستر – گرد هم می‌آیند تا با استفاده از مثال‌های مشخص، نیازمندی‌ها را در قالب سناریوهای گرکین تعریف کنند.
  2. فاز توسعه (Development): توسعه‌دهندگان از این سناریوها به عنوان راهنمایی برای پیاده‌سازی قابلیت‌ها و نوشتن تست‌های واحد استفاده می‌کنند.
  3. فاز تست (Testing): تسترها از سناریوهای گرکین برای ایجاد تست‌های پذیرش خودکار استفاده می‌کنند. ابزارهایی مانند Cucumber، SpecFlow، و Behave این سناریوهای متنی را به کدهای قابل اجرا تبدیل می‌کنند.
  4. مستندات زنده (Living Documentation): از آنجایی که این سناریوها به طور مداوم با کد تست و اجرا می‌شوند، همواره وضعیت فعلی و رفتار سیستم را به درستی منعکس می‌کنند و به عنوان مستنداتی قابل اعتماد و به‌روز عمل می‌نمایند.

نتیجه‌گیری

نوشتن سناریوهای گرکین مؤثر، هنری است که نیازمند تمرین، همکاری و درک عمیق از اصول BDD است. با تمرکز بر رفتار سیستم از دیدگاه کسب‌وکار، استفاده از زبان مشترک و مثال‌های واقعی، تیم‌ها می‌توانند شکاف ارتباطی را پر کرده، سوءتفاهم‌ها را کاهش دهند و در نهایت نرم‌افزاری با کیفیت بالاتر تولید کنند که دقیقاً نیازهای کاربران و اهداف کسب‌وکار را برآورده می‌سازد. BDD و گرکین ابزارهایی قدرتمند برای دستیابی به این هدف هستند و سرمایه‌گذاری در یادگیری و به‌کارگیری صحیح آن‌ها، منافع قابل توجهی برای هر پروژه نرم‌افزاری به همراه خواهد داشت.

سوالات متداول (FAQ)

  1. تفاوت اصلی BDD و TDD چیست؟
    • TDD (توسعه آزمون محور) بیشتر بر نوشتن تست‌های واحد توسط توسعه‌دهندگان برای هدایت پیاده‌سازی واحدهای کوچک کد تمرکز دارد. زبان تست‌ها معمولاً فنی است. BDD (توسعه رفتار محور) بر همکاری بین ذینفعان فنی و غیرفنی برای تعریف رفتار سیستم از دیدگاه کاربر با استفاده از زبان طبیعی (مانند گرکین) تمرکز دارد. BDD می‌تواند TDD را در سطح بالاتری در بر بگیرد.
  2. آیا برای استفاده از BDD حتماً باید از گرکین استفاده کنیم؟
    • خیر، گرکین تنها یکی از ابزارهای پیاده‌سازی BDD است، هرچند محبوب‌ترین و رایج‌ترین آن‌هاست. اصل BDD، همکاری و تعریف رفتار از طریق مثال است. برخی تیم‌ها ممکن است از فرمت‌های دیگری برای مستندسازی این رفتارها استفاده کنند، اما گرکین به دلیل ساختار استاندارد و پشتیبانی ابزارهای متعدد، گزینه بسیار مناسبی است.
  3. چه کسانی مسئول نوشتن سناریوهای گرکین هستند؟
    • نوشتن سناریوهای گرکین یک فعالیت تیمی است. در حالت ایده‌آل، این سناریوها در جلسات مشترک (مانند جلسات “سه رفیق”) با حضور نمایندگان کسب‌وکار (مانند مالک محصول یا تحلیلگر کسب‌وکار)، توسعه‌دهندگان و تسترها تهیه و بازبینی می‌شوند. هر یک از این نقش‌ها دیدگاه منحصربه‌فردی را به فرآیند اضافه می‌کند.
  4. آیا سناریوهای گرکین جایگزین مستندات سنتی می‌شوند؟
    • سناریوهای گرکین به عنوان “مستندات زنده” عمل می‌کنند، زیرا مستقیماً با تست‌های خودکار در ارتباط هستند و رفتار واقعی سیستم را منعکس می‌کنند. آن‌ها می‌توانند بخش قابل توجهی از مستندات نیازمندی‌های عملکردی را پوشش دهند. با این حال، ممکن است همچنان به مستندات دیگری برای جنبه‌های غیرعملکردی، معماری سیستم یا راهنماهای کاربر نیاز باشد.
  5. چگونه می‌توانیم اطمینان حاصل کنیم که سناریوهای گرکین ما به خوبی نوشته شده‌اند؟
    • بازبینی تیمی: سناریوها باید توسط تمام اعضای کلیدی تیم (کسب‌وکار، توسعه، تست) بازبینی شوند.
    • شفافیت و عدم ابهام: آیا سناریو برای همه قابل فهم است؟
    • تمرکز بر رفتار: آیا سناریو “چه چیزی” را توصیف می‌کند نه “چگونه”؟
    • یک رفتار در هر سناریو: آیا هر سناریو یک قانون یا رفتار خاص را پوشش می‌دهد؟
    • قابلیت تست خودکار: آیا می‌توان بر اساس سناریو، تست خودکار نوشت؟
    • استفاده از اصول INVEST: سناریوها (به عنوان بخشی از داستان‌های کاربری) باید مستقل، قابل مذاکره، ارزشمند، قابل تخمین، کوچک و قابل تست باشند.

بیشتر بخوانید:

محمد عسکری

محمد هستم، توسعه‌دهنده وب با بیش از ده سال تجربه در برنامه‌نویسی سمت سرور و کاربر. به یادگیری و اشتراک‌گذاری دانش علاقه‌مندم و اخیراً تمرکزم را روی حوزه تست نرم‌افزار گذاشته‌ام تا تجربیاتم را در این زمینه نیز به اشتراک بگذارم و به درک بهتر کیفیت نرم‌افزار کمک کنم.

دیدگاهتان را بنویسید