جداول القرار - شرح أكثر

مقال مجاني 15 دقيقة

مقدمة

مرحبا ويعطيكم العافية وأهلا وسهلا فيكم في درس جديد عن جداول القرار أو Decision Tables!

تخيل معي هالسيناريو: انت ويتر في مطعم، وعندك زبون جديد. ماذا تفكر فيه قبل لا تقرر كيف تريد أن تخدمه؟

  • هل الزبون VIP؟
  • هل اليوم عطلة نهاية الأسبوع؟
  • هل في طاولة متوفرة؟
  • هل الزبون عنده حجز مسبق؟

كل واحد من هالأسئلة إله إجابة (نعم/لا)، وبناءً على المزيج من الإجابات، تتغيّر طريقة التعامل. هذا بالضبط لا نحاول نحلّه بجداول القرار!

في عالم البرمجيات، كثير من الأنظمة عندها منطق معقد (Complex Business Logic) يعتمد على مجموعة من الشروط اللي تتفاعل مع بعضها. جداول القرار هي أداة قوية جداً تساعدنا نغطي كل الاحتمالات بطريقة منظمة ومنهجية.


الأهداف التعليمية

بنهاية هالدرس، ستكون قادراً على:

  • ✅ فهم ما هو جدول القرار ومتى نستخدمه
  • ✅ التعرف على مكونات جدول القرار (الشروط، الإجراءات، القواعد)
  • ✅ بناء جدول قرار كامل لأمثلة واقعية
  • ✅ تحويل جداول القرار لحالات اختبار
  • ✅ معرفة متى نستخدم ومتى ما نستخدم جداول القرار
  • ✅ تطبيق التقنية على أنظمة حقيقية (Amazon, Netflix, Royal Jordanian)

ما هو جدول القرار؟

جدول القرار هو جدول يربط الشروط (Conditions) بالإجراءات (Actions) أو النتائج.

ببساطة، جدول القرار يساعدك تختبر كل الاحتمالات الممكنة عندما يكون عندك شروط متعددة تتفاعل مع بعضها حتى تعطي نتيجة معينة.

متى نستخدمه؟

جداول القرار مثالية عندما يكون عندك:

  • شروط متعددة (Multiple Conditions)
  • الشروط تتفاعل مع بعض وتأثر على النتيجة النهائية
  • منطق أعمال معقد (Complex Business Rules)
  • حاجة تتأكد إنك ما نسيت أي احتمال

مكونات جدول القرار

أي جدول قرار يتكون من ثلاث مكونات رئيسية:

1. الشروط (Conditions)

هي المدخلات أو الأسئلة التي إجابتها عادةً True/False أو Yes/No أو نعم/لا.

مثلاً:

  • هل المستخدم مسجل دخول؟
  • هل الكوبون صالح؟
  • هل المخزون متوفر؟

2. الإجراءات (Actions/Results)

هي النتائج أو التصرفات التي تصبح بناءً على الشروط.

مثلاً:

  • عرض رسالة خطأ
  • تطبيق خصم 20%
  • إرسال إيميل تأكيد
  • حجب الحساب

3. القواعد (Rules)

كل عمود في الجدول يمثل قاعدة (Rule)، وهي مزيج فريد من الشروط والنتيجة المترتبة عليها.

ملاحظة مهمة: إذا عندك n شرط، سيكون عندك 2^n قاعدة ممكنة (لأنه كل شرط إله احتمالين: صح أو خطأ).


مثال عملي #1: نظام الخصومات في Amazon/Carrefour

خلينا ناخذ مثال واقعي: نظام خصومات في متجر إلكتروني زي Amazon أو تطبيق كارفور.

الشروط:

  1. هل المستخدم Premium؟ (عضوية مدفوعة)
  2. هل المبلغ أكثر من 100$؟
  3. هل اليوم Black Friday؟ (جمعة البيع السوداء)

الإجراءات:

  • نسبة الخصم: 0%, 5%, 10%, 20%

جدول القرار الكامل:

القاعدة R1 R2 R3 R4 R5 R6 R7 R8
الشروط
Premium؟
مبلغ > 100$؟
Black Friday؟
الإجراءات
نسبة الخصم 20% 15% 10% 5% 10% 5% 5% 0%

تحليل القواعد:

  • R1: مستخدم Premium + مبلغ كبير + Black Friday = خصم 20% (أفضل سيناريو للزبون!)
  • R8: مستخدم عادي + مبلغ صغير + يوم عادي = لا يوجد خصم
  • R2: Premium + مبلغ كبير + يوم عادي = خصم 15%

حالات الاختبار:

كل قاعدة من القواعد الثمانية تتحول لحالة اختبار:

حالة اختبار R1:

  • Precondition: حساب Premium مفعّل
  • Steps:
  1. سجل دخول بحساب Premium
  2. أضف منتجات بمبلغ أكثر من 100$
  3. افتح السلة يوم Black Friday
  • Expected Result: خصم 20% يظهر

حالة اختبار R8:

  • Precondition: حساب عادي (غير Premium)
  • Steps:
  1. سجل دخول بحساب عادي
  2. أضف منتج بمبلغ 50$
  3. افتح السلة في يوم عادي
  • Expected Result: لا يوجد خصم

مثال عملي #2: تسجيل الدخول (Login System)

نظام تسجيل الدخول في أي موقع (Facebook, Instagram, Gmail) عنده منطق معقد قليلاً.

الشروط:

  1. هل الإيميل صحيح؟ (موجود في قاعدة البيانات)
  2. هل الباسورد صحيح؟
  3. هل الحساب مفعّل؟ (Account Active)

الإجراءات:

  • دخول ناجح (Successful Login)
  • رسالة خطأ: "بيانات غير صحيحة"
  • رسالة: "الحساب غير مفعّل" + إرسال رابط تفعيل
  • قفل الحساب بعد 3 محاولات فاشلة

جدول القرار:

القاعدة R1 R2 R3 R4 R5 R6 R7 R8
الشروط
إيميل صحيح؟
باسورد صحيح؟
حساب مفعّل؟
الإجراءات
دخول ناجح
رسالة "حساب غير مفعّل"
رسالة "بيانات خاطئة"

ملاحظة: القواعد R5, R6, R7, R8 كلها مستحيلة منطقياً (إذا الإيميل غلط، لن نقدر نتحقق من الباسورد أو حالة الحساب). هذه القواعد ممكن نحذفها أو نعتبرها "لا تنطبق".

اكتشاف متطلب ناقص!

عندما نبني جدول القرار، أحياناً نكتشف متطلبات ناقصة (Missing Requirements).

مثلاً: ماذا يصير عندما الإيميل صحيح والحساب مفعّل، لكن الباسورد غلط؟ (R3)

  • هل بنعطي رسالة: "الباسورد غلط"؟
  • ولا رسالة عامة: "بيانات الدخول غير صحيحة" (حتى الأمان)؟
  • بعد كم محاولة فاشلة بنقفل الحساب؟

جداول القرار بتجبرك تفكر في كل الاحتمالات، وهذا يجعلك تكتشف حالات ما كانت واضحة من المتطلبات!


مثال عملي #3: حجز طيران - Royal Jordanian

تخيل إنك تريد أن تحجز تذكرة على موقع Royal Jordanian أو أي شركة طيران.

الشروط:

  1. هل المقاعد متوفرة؟
  2. هل الدفع ناجح؟ (بطاقة صالحة ورصيد كافي)
  3. هل الجواز صالح؟ (ما انتهت صلاحيته)

الإجراءات:

  • تأكيد الحجز + إرسال تذكرة إلكترونية
  • إلغاء الحجز + رسالة خطأ
  • وضع في قائمة الانتظار
  • 📧 طلب تحديث بيانات الجواز

جدول القرار:

القاعدة R1 R2 R3 R4 R5 R6 R7 R8
الشروط
مقاعد متوفرة؟
دفع ناجح؟
جواز صالح؟
الإجراءات
تأكيد الحجز
رسالة "حدّث الجواز"
رسالة "فشل الدفع"
قائمة انتظار
إلغاء الحجز

تحليل القواعد المهمة:

  • R1: كل شي تمام = حجز مؤكد ✅
  • R2: مقاعد متوفرة + دفع ناجح، لكن الجواز منتهي = طلب تحديث الجواز قبل التأكيد
  • R5: لا مقاعد متوفرة، لكن الدفع ناجح والجواز صالح = قائمة انتظار (ممكن يفضي مقعد)
  • R8: كل شي غلط = إلغاء مباشر

كيف تبني جدول القرار خطوة بخطوة؟

الخطوة 1: حدد كل الشروط

اسأل نفسك: ما هي المدخلات أو الأسئلة اللي تأثر على النتيجة؟

مثال (نظام شحن Amazon):

  • هل العنوان داخل الأردن؟
  • هل الطلب Prime؟
  • هل الوزن أقل من 5 كيلو؟

الخطوة 2: حدد كل الإجراءات الممكنة

ما هي النتائج أو التصرفات اللي ممكن تصير؟

مثال:

  • شحن مجاني
  • شحن بـ 3 دنانير
  • شحن بـ 7 دنانير
  • شحن غير متوفر

الخطوة 3: احسب عدد القواعد

عدد القواعد = 2^n

حيث n = عدد الشروط

مثال:

  • 3 شروط = 2^3 = 8 قواعد
  • 4 شروط = 2^4 = 16 قاعدة
  • 5 شروط = 2^5 = 32 قاعدة
تحذير
انتبه! كلما زاد عدد الشروط، عدد القواعد يضاعف. نظام بـ 10 شروط سيعطيك 1024 قاعدة! لهذا السبب جداول القرار مش مناسبة لكل شي.

الخطوة 4: املأ كل الاحتمالات

ابدأ بتعبئة الجدول بطريقة منهجية:

  • الشرط الأول: نص القواعد ✅ ونص ❌
  • الشرط الثاني: ربع ✅ ربع ❌ ربع ✅ ربع ❌
  • الشرط الثالث: بدّل كل عمود

الخطوة 5: حدد النتيجة لكل قاعدة

لكل مزيج من الشروط، حدد ما الإجراء أو النتيجة المتوقعة.

نصيحة: لو مش متأكد من النتيجة، هذه فرصة إنك تسأل صاحب المنتج (Product Owner) أو تراجع المتطلبات.

الخطوة 6: حوّل كل قاعدة لحالة اختبار

كل قاعدة في الجدول = حالة اختبار واحدة على الأقل.


متى نستخدم جدول القرار؟

جداول القرار مثالية في الحالات التالية:

✅ استخدمه عندما:

  1. يكون في شروط متعددة (2-6 شروط عادةً)
  2. الشروط تتفاعل مع بعض - يعني نتيجة شرط تأثر على التاني
  3. النتيجة تعتمد على مزيج من الشروط مش شرط واحد
  4. منطق أعمال معقد - Business Rules صعب تفهمها من الكلام
  5. حاجة تتأكد إنك غطيت كل الاحتمالات

أمثلة واقعية:

  • نظام التأمين الصحي (العمر، التدخين، الأمراض المزمنة → قيمة القسط)
  • نظام القروض البنكية (الدخل، الراتب، تاريخ الائتمان → الموافقة/الرفض)
  • نظام التوصيل (المنطقة، الوزن، السرعة → سعر الشحن)
  • ألعاب الفيديو (المستوى، الصحة، الأسلحة → النتيجة)

متى ما نستخدمه؟

❌ لا تستخدمه عندما:

  1. يكون في شرط واحد بس - استخدم Equivalence Partitioning أو BVA
  2. الشروط مستقلة تماماً - كل شرط إله نتيجة منفصلة
  3. عدد الشروط كبير جداً - 10 شروط = 1024 قاعدة! (غير عملي أبداً)
  4. المنطق بسيط جداً - جدول القرار سيكون Over-engineering

مثال متى لا تستخدمه:

نظام بسيط: "إذا العمر أقل من 18، ممنوع الدخول. إذا 18 أو أكثر، مسموح."

هذا ما بحتاج جدول قرار، هذا Equivalence Partitioning كافي:

  • Partition 1: عمر < 18 → Denied
  • Partition 2: عمر >= 18 → Allowed

نصائح عملية لبناء جداول قرار فعّالة

1. ابدأ بالشروط الأهم

رتب الشروط من الأهم للأقل أهمية. الشروط التي تأثر على معظم القواعد حطها أول.

2. دوّر على القواعد المستحيلة

مش كل القواعد منطقية! بعض المزيجات مستحيلة أو لا تنطبق.

مثال (نظام تسجيل دخول):

  • إذا الإيميل غلط، لا داعي نفحص الباسورد أو حالة الحساب
  • القواعد هذه ممكن نحذفها أو نعلمها بـ "N/A"

3. استخدم "-" للشروط اللي لا تفرق (Don't Care)

أحياناً، شرط معين ما بأثر على النتيجة في قاعدة معينة. بهاي الحالة، استخدم علامة - أو "Don't Care".

مثال:

القاعدة R1 R2
مسجل دخول؟
Premium؟ -
الإجراء عرض محتوى Premium طلب تسجيل دخول

في R2، مش مهم إذا Premium ولا لا، لأنه أصلاً مش مسجل دخول!

نصيحة
استخدام "Don't Care" يقلل عدد القواعد ويخلي الجدول أوضح وأسهل للقراءة.

4. ركز على القواعد عالية المخاطر

مش كل القواعد لها نفس الأهمية. ركز جهودك على:

  • القواعد التي فيها أموال (مثل نظام الدفع)
  • القواعد التي تأثر على الأمان (مثل الصلاحيات)
  • القواعد التي كثير تستخدم (مثل تسجيل الدخول)

5. راجع الجدول مع الفريق

جداول القرار أداة تواصل ممتازة. اعرضها على:

  • Product Owner (حتى يتأكد من المنطق)
  • المطورين (حتى يفهموا كل الحالات)
  • الـ Testers التانيين (حتى يراجعوا معك)

تمرين عملي: Netflix Subscription Check

حان وقت التطبيق! خلينا نبني جدول قرار لنظام Netflix.

السيناريو:

عندما مستخدم بدّه يشغل فيلم أو مسلسل على Netflix، النظام يفحص:

  1. هل المستخدم مشترك؟ (Is user subscribed?)
  2. هل المحتوى متوفر في منطقته؟ (Is content available in region?)
  3. هل عمر المستخدم يناسب التصنيف؟ (Is user age >= content rating?)

الإجراءات الممكنة:

  • ▶️ Play: تشغيل المحتوى
  • 💳 Show upgrade message: "اشترك الآن للمشاهدة"
  • 🌍 Show unavailable: "هذا المحتوى غير متوفر في منطقتك"
  • 🔞 Show age restriction: "هذا المحتوى غير مناسب لعمرك"

جدول القرار:

القاعدة R1 R2 R3 R4 R5 R6 R7 R8
الشروط
مشترك؟
متوفر في المنطقة؟
العمر مناسب؟
الإجراءات
Play ▶️
Age Restriction 🔞
Unavailable 🌍
Upgrade 💳

حالات الاختبار:

TC-R1: مشترك + متوفر + عمر مناسب = تشغيل ناجح

Given: مستخدم مشترك في Netflix Basic
And: المحتوى "Stranger Things" متوفر في الأردن
And: عمر المستخدم 25 سنة (المحتوى TV-14)
When: المستخدم يضغط Play
Then: المحتوى يبدأ التشغيل بنجاح

TC-R2: مشترك + متوفر + عمر غير مناسب = قيد عمري

Given: مستخدم مشترك (عمره 14 سنة)
And: المحتوى "Breaking Bad" متوفر (تصنيف TV-MA, 18+)
When: المستخدم يضغط Play
Then: رسالة "هذا المحتوى مخصص للبالغين فقط"

TC-R5: غير مشترك + متوفر + عمر مناسب = طلب اشتراك

Given: مستخدم غير مشترك (Free Account)
And: المحتوى متوفر في منطقته
When: المستخدم يضغط Play
Then: رسالة "اشترك الآن لمشاهدة هذا المحتوى" + عرض باقات الاشتراك

تحسين الجدول:

ممكن نستخدم "Don't Care" لتبسيط بعض القواعد:

القاعدة R1 R2 R3
مشترك؟
متوفر؟ -
عمر مناسب؟ - -
الإجراء Play ▶️ Unavailable 🌍 Upgrade 💳

لاحظ إن في R3 (غير مشترك)، مش مهم إذا المحتوى متوفر أو العمر مناسب، لأنه أصلاً لن يقدر يشوف!


الخلاصة

جداول القرار هي أداة قوية جداً لاختبار الأنظمة التي فيها منطق معقد.

النقاط الأساسية:

جدول القرار = شروط + إجراءات + قواعد

مثالي عندما الشروط تتفاعل مع بعض وتعطي نتائج مختلفة

يساعدك تغطي كل الاحتمالات ولا تنسَ أي حالة

يكشف متطلبات ناقصة عندما تبني الجدول

استخدمه مع ECP و BVA حتى تغطية شاملة

مش مناسب لكل شي - عدد الشروط الكبير = عدد قواعد ضخم

ركز على القواعد عالية المخاطر اللي فيها أموال أو أمان

استخدم "Don't Care" لتبسيط الجدول

المعادلة الذهبية:

عدد الشروط (n) → عدد القواعد (2^n) → عدد حالات الاختبار

متى تستخدمه؟

استخدم جداول القرار عندما يكون المنطق معقد والشروط متداخلة وحاجة تغطية شاملة.

لا تستخدمه عندما يكون المنطق بسيط أو الشروط مستقلة أو العدد كبير جداً.


مصادر إضافية:

  • ISTQB Foundation Syllabus (Section 4.2 - Decision Tables)
  • "Software Testing Techniques" by Boris Beizer
  • "Lessons Learned in Software Testing" by Kaner, Bach & Pettichord

يعطيكم العافية، ونلتقي في الدرس الجاي! 🚀