نادیده گرفتن منطق بیزینس در تست نرم افزار
نادیده گرفتن منطق بیزینس در تست نرمافزار: فاجعهای در لباسِ کدهای سبز!
آیا تستهای شما با موفقیت پاس میشوند، اما کسبوکار همچنان در حال از دست دادن پول است؟ در این مقاله کالبدشکافی میکنیم که چرا تمرکز صرف بر روی سینتکس و ارورهای فنی، بزرگترین توهم در دنیای تضمین کیفیت (QA) است.
وقتی کدها درست کار میکنند، اما بیزینس میسوزد!
بسیاری از مهندسین تست (به خصوص تازهکارها) درگیر یک چرخه باطل میشوند: روی دکمه کلیک کن، چک کن که پاپآپ باز شود، بررسی کن که API کد ۲۰۰ برگرداند. همه چیز سبز است! اما یک فاجعه در جریان است که هیچ ابزار اتومیشنی متوجه آن نشده است.
منطق بیزینس (Business Logic) قلب تپنده نرمافزار است. این منطق مجموعهای از قوانین دنیای واقعی است که نرمافزار باید آنها را اجرا کند. مثلاً: "اگر مشتری سبد خرید بالای ۵ میلیون تومان داشت و کاربر VIP بود، هزینه ارسال رایگان است؛ در غیر این صورت هزینه ارسال باید محاسبه شود." اگر کد شما هزینه ارسال را برای همه رایگان کند، هیچ ارور فنی (مانند 500 Internal Server Error) رخ نمیدهد، اما شرکت روزانه میلیونها تومان ضرر میکند!
قانون بیزینس این است: «کاربر نمیتواند همزمان از کد تخفیف درصدی و کد تخفیف مبلغ ثابت استفاده کند.». در شبیهساز زیر، سعی کنید با استفاده از هر دو کد، سیستم را فریب داده و این باگ منطقی خطرناک را کشف کنید:
منتظر اکشن کاربر...
چگونه منطق بیزینس را تست کنیم؟
برای شکار باگهای منطقی، شما باید از یک «اپراتور نرمافزار» به یک «تحلیلگر دامنه» (Domain Analyst) تبدیل شوید. شما باید قبل از نوشتن یک خط کد تست، با مدیر محصول (Product Manager) جلسه بگذارید و تمام قوانین پنهان سیستم را بیرون بکشید.
۱. توسعه رفتار محور (BDD)
استفاده از سینتکس Gherkin (Given-When-Then) بهترین راه برای مکتوب کردن منطق بیزینس است. این کار باعث میشود تمام تیم (فنی و غیرفنی) روی قوانین تجاری به یک زبان مشترک برسند.
۲. تکنیک Decision Tables
برای قوانینی که متغیرهای زیادی دارند (مثلاً محاسبه مالیات بر اساس استان، نوع کالا و وضعیت کاربر)، استفاده از جدول تصمیمگیری کمک میکند هیچ حالت مرزی (Edge Case) منطقی فراموش نشود.
۳. تست مبتنی بر پرسونا
به جای تست کردن سیستم با یک کاربر فرضی، نقشهای مختلف را بازی کنید. یک کاربر مسدود شده، یک ادمین کل، یک کاربر با موجودی صفر. سیستم باید منطق متفاوتی برای هرکدام داشته باشد.
یک تستر حرفهای به جای تمرکز روی فیلدها، روی «رفتار» تمرکز میکند. سناریوهای زیر را بررسی کنید تا تفاوت تست فنی و تست بیزینسی را در قالب BDD درک کنید:
Scenario: Test transfer money button
Given I am on the dashboard page
When I click on "#transfer-btn"
And I fill "#amount" with "100"
And I click "#submit"
Then I should see a success message in ".alert-success"Scenario: Prevent money transfer exceeding daily limit
Given a user has a "Standard" account with balance "$5000"
And the user's daily transfer limit is "$1000"
When the user attempts to transfer "$1500" to another account
Then the transfer should be "Rejected"
And the account balance should remain "$5000"
And the system should log a "Limit Exceeded" alertکلام آخر: کیفیت، فراتر از کد است
یک نرمافزار بدون باگِ فنی که ارزش بیزینسی اشتباهی تولید میکند، از یک نرمافزار پر از باگ که نیاز مشتری را به درستی هدف گرفته، خطرناکتر است. وظیفه یک مهندس تضمین کیفیت (QA)، محافظت از «قوانین کسبوکار» است، نه فقط محافظت از «سینتکس کدها».
دفعه بعد که یک User Story را برای تست در دست گرفتید، قبل از باز کردن ابزارهای اتومیشن یا نوشتن اسکریپتها، از خود بپرسید: «هدف تجاریِ پشت این دکمه چیست و کاربر چگونه میتواند این قانون را دور بزند؟». این سوال ساده، شما را به یک متخصص بیبدیل در مهندسی کیفیت تبدیل خواهد کرد.
🎮 چالش مهارت: آیا میتوانید باگهای منطقی را شکار کنید؟
یک معمار کیفیت (QA) باید تفاوت ارورهای کدنویسی و خطاهای قوانین کسبوکار را بشناسد. قوانین بیزینس و رفتار سیستم را بخوانید و نوع باگ را مشخص کنید. (برای شروع کلیک کنید)
آمادهاید مچ برنامهنویسها را بگیرید؟
- شما ۵ سناریوی واقعی از سیستمهای نرمافزاری را بررسی میکنید.
- باید تشخیص دهید مشکل فنی است، منطقی است، یا سیستم سالم است.
- هر پاسخ درست ۲۰ امتیاز دارد.
در حال بارگذاری...
در حال بارگذاری...
پایان ارزیابی
در حال محاسبه سطح مهارت شما...