مقدمه
در توسعه نرمافزار مدرن شفافیت، همکاری و کارایی از اهمیت بالایی برخوردارند. یکی از روشهایی که این جنبهها را تقویت میکند، استفاده از روش گرکین(Gherkin) برای نوشتن داستانهای کاربری و تعریف معیارهای پذیرش به روشی ساختارمند و قابل خواندن برای همه است. Gherkin به عنوان بخشی از توسعه مبتنی بر رفتار (BDD) به تیمهای محصول، توسعهدهندگان، تستکنندگان و ذینفعان کمک میکند تا تعاملات سیستم را بهوضوح درک کنند.
این مقاله ساختار داستانهای کاربری Gherkin، بهترین روشهای نگارش و یکپارچهسازی با تستهای خودکار را بررسی میکند تا به بهینهسازی فرآیند توسعه و تضمین کیفیت محصولات کمک کند.
گرکین چیست؟
گرکین یک زبان خاص دامنه (DSL) است که برای توصیف رفتار تستشدهی سیستم به زبانی ساده و ساختاریافته استفاده میشود. این زبان معمولاً با فریمورکهای BDD مانند Cucumber و SpecFlow برای نوشتن تستهای قابل اجرا و بررسی رفتار محصول ترکیب میشود.
ساختار داستانهای کاربری گرکین
هر داستان کاربری در گرکین از فرمت Given-When-Then پیروی میکند که پذیرش را واضحتر میکند:
💡 مثال داستان کاربری گرکین:
Scenario: ورود موفق کاربر به سیستم Given کاربر در صفحه ورود قرار دارد When او نام کاربری و رمز عبور صحیح را وارد کند Then باید به داشبورد هدایت شود
✅ این فرمت اطمینان میدهد که هر سناریوی تست بهوضوح تعریف شده است و اتوماسیون تست آسانتر میشود.
1. نگارش سناریوهای ساده و مشخص
هر سناریو باید یک رفتار خاص را توصیف کند تا از پیچیدگی جلوگیری شود.
❌ مثال نامناسب:
Scenario: ورود و مشاهده پروفایل Given کاربر در صفحه ورود است When او اطلاعات ورود را وارد کند Then به داشبورد هدایت شود And به بخش پروفایل برود And اطلاعات پروفایل خود را ویرایش کند
🚫 این سناریو چندین اقدام را ترکیب کرده که تست آن دشوارتر میشود.
✅ مثال بهتر (تفکیک مراحل):
Scenario: ورود موفق به سیستم Given کاربر در صفحه ورود قرار دارد When او نام کاربری و رمز عبور صحیح را وارد کند Then باید به داشبورد هدایت شود
✅ این سبک نوشتار وضوح و قابلیت تست را افزایش میدهد.
2. داستانهای کاربری بر اساس رفتار واقعی کاربران
سناریوها باید نمایانگر تعاملات واقعی کاربران باشند، نه فرآیندهای فنی داخلی.
💡 نمونه مناسب:
Scenario: افزودن محصول به سبد خرید Given کاربر در صفحه محصول قرار دارد When روی دکمه “افزودن به سبد خرید” کلیک کند Then محصول باید در سبد خرید نمایش داده شود
✅ این سناریو رفتار کاربر را بازتاب میدهد و از اصطلاحات فنی اجتناب میکند.
❌ نمونه نامناسب (تمرکز بر منطق داخلی):
Scenario: ثبت محصول در پایگاه داده Given کاربر روی “افزودن به سبد خرید” کلیک کند When سیستم درخواست را پردازش کند Then اطلاعات محصول در پایگاه داده ذخیره شود
🚫 این روایت بیشتر به فرآیندهای داخلی سیستم میپردازد و تجربه کاربری را نشان نمیدهد.
3. تعریف معیارهای پذیرش قابل اندازهگیری
✅ هر Then باید نتیجهای مشخص و قابل تست را تعیین کند.
💡 مثال مناسب:
Scenario: ورود ایمیل نامعتبر در صفحه ثبتنام Given کاربر در صفحه ثبتنام است When یک ایمیل نامعتبر وارد کند Then باید پیام خطا "فرمت ایمیل نامعتبر است" نمایش داده شود
🚀 این روش نتیجه قابل اندازهگیری و تست خودکار را تضمین میکند.
❌ مثال نامناسب (توصیف مبهم):
Scenario: ورود ایمیل نامعتبر Given کاربر در صفحه ثبتنام است When یک ایمیل نامعتبر وارد کند Then باید اطلاعرسانی شود
🚫 "باید اطلاعرسانی شود" نامشخص است—آیا پیام خطایی نمایش داده میشود؟ آیا اعلان ارسال خواهد شد؟
1. نحوه اجرای تستهای خودکار با گرکین
گرکین با فریمورکهای تست BDD ادغام میشود:
✅ Cucumber (برای Java، JavaScript، Ruby و...)
✅ SpecFlow (برای برنامههای .NET)
✅ Behave (برای Python)
💡 مثال پیادهسازی تست خودکار با Cucumber (Java):
@Given("کاربر در صفحه ورود قرار دارد") public void user_on_login_page() { driver.get("https://example.com/login"); } @When("او نام کاربری و رمز عبور صحیح را وارد کند") public void user_enters_credentials() { driver.findElement(By.id("username")).sendKeys("user123"); driver.findElement(By.id("password")).sendKeys("password123"); driver.findElement(By.id("loginButton")).click(); } @Then("باید به داشبورد هدایت شود") public void user_redirected_to_dashboard() { assertEquals(driver.getCurrentUrl(), "https://example.com/dashboard"); }
✅ این روش تضمین میکند که رفتار سیستم بهطور خودکار بررسی میشود.
2. اجرای تستها در فرآیند توسعه
✅ اجرای تستهای موازی برای کاهش زمان
✅ ادغام با CI/CD برای بررسی خودکار هر تغییر کد
✅ ایجاد تستهای منفی و سناریوهای استثنا برای یافتن مشکلات پنهان
🚀 نمونه جریان CI/CD با تست گرکین:
1️⃣ توسعهدهنده سناریوهای جدید را اضافه میکند
2️⃣ سیستم CI/CD (مانند GitHub Actions، Jenkins) تستها را اجرا میکند
3️⃣ تستهای خودکار از طریق Cucumber اجرا میشوند
4️⃣ در صورت موفقیت، محصول به مرحله انتشار میرود
استفاده از داستانهای کاربری گرکین سبب شفافیت، تستپذیری و همکاری بهتر بین تیمها میشود. با رعایت بهترین روشها—مانند تفکیک سناریوها، تمرکز بر رفتار کاربر، و تعریف نتایج قابل تست—سازمانها میتوانند توسعه نرمافزار را کارآمدتر و محصولات را با کیفیت بالا عرضه کنند.
همچنین ادغام تست خودکار با داستانهای گرکین تضمین میکند که رفتار سیستم بهصورت مداوم و بدون خطا بررسی شود، که منجر به انتشار محصولی مطمئنتر و بدون باگ خواهد شد.