تقسيم الفئات المتكافئة - شرح أكثر

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

مقدمة

تخيل معي إنك تريد أن تختبر خاصية في موقع مثل Carrefour Jordan أو Amazon - مثلاً نظام الخصومات. عندك كود خصم بشتغل لكن للطلبات التي قيمتها أكثر من 50 دينار.

السؤال: كم حالة اختبار لازم تعمل؟

هل تختبر كل مبلغ ممكن؟ 1 دينار، 2 دينار، 3 دينار... لحد لا توصل 1000 دينار؟ طبعاً لأ! هذه مش practical ولا efficient.

هون بيجي دور تقسيم الفئات المتكافئة - أداة ذكية تساعدك تقلل عدد الحالات الاختبارية وبنفس الوقت تحافظ على تغطية فعّالة.


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

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

  • فهم مبدأ تقسيم الفئات المتكافئة وكيف بشتغل
  • تقسيم المدخلات إلى فئات صالحة (Valid) وغير صالحة (Invalid)
  • استخدام ECP لتقليل عدد حالات الاختبار بذكاء
  • فهم متى وكيف تستخدم هذه التقنية في الواقع
  • التفكير بشكل نقدي في حدود وقيود هذه التقنية

الجزء الأول: التعريف التقليدي

ما هو تقسيم الفئات المتكافئة؟

الفكرة الأساسية: كل المدخلات في نفس الفئة المتكافئة تتصرف بنفس الطريقة في النظام - يعني إذا واحدة منهم شتغلت صح، الباقي أيضاً راح يشتغل صح (نظرياً على الأقل).

بدل لا تختبر كل قيمة ممكنة، تقسم المدخلات لمجموعات (فئات) وتختار ممثل واحد من كل مجموعة.


مثال عملي: نظام الخصومات في Amazon

خلينا ناخد مثال واقعي من مواقع التسوق:

القاعدة:

  • الطلبات من 0 - 49.99 دينار: لا يوجد خصم
  • الطلبات من 50 - 99.99 دينار: خصم 10%
  • الطلبات 100 دينار فأكثر: خصم 20%
  • القيم السالبة أو الحروف: invalid input

تقسيم الفئات

الفئة النوع مثال على القيمة السلوك المتوقع
أقل من 50 Valid 25 دينار لا يوجد خصم
من 50 إلى 99.99 Valid 75 دينار خصم 10%
100 فأكثر Valid 150 دينار خصم 20%
قيمة سالبة Invalid -10 دينار رسالة خطأ
صفر Invalid/Edge 0 دينار رسالة خطأ
حروف Invalid "ABC" رسالة خطأ

كيف نصمم الحالات الاختبارية؟

بدلاً من أن نختبر مئات القيم، نختار ممثل واحد من كل فئة:

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

  1. TC-001: المبلغ = 25 دينار → Expected: لا يوجد خصم
  2. TC-002: المبلغ = 75 دينار → Expected: خصم 10%
  3. TC-003: المبلغ = 150 دينار → Expected: خصم 20%
  4. TC-004: المبلغ = -10 دينار → Expected: رسالة خطأ
  5. TC-005: المبلغ = 0 دينار → Expected: رسالة خطأ
  6. TC-006: المبلغ = "Test" → Expected: رسالة خطأ

من مئات أو آلاف الاحتمالات، وصلنا ل 6 حالات بس!


مثال آخر: التحقق من العمر في Netflix

تخيل إنك تختبر نظام التحقق من العمر في Netflix للمحتوى +18.

القاعدة: العمر المسموح من 1 إلى 120 سنة، والمحتوى +18 محجوب للأعمار أقل من 18.

الفئة النوع مثال السلوك المتوقع
أقل من 1 Invalid 0, -5 رسالة خطأ
من 1 إلى 17 Valid (Minor) 10, 15 محتوى محدود
من 18 إلى 120 Valid (Adult) 25, 50 كل المحتوى متاح
أكثر من 120 Invalid 150 رسالة خطأ
غير رقمي Invalid "عشرين" رسالة خطأ

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

  1. العمر = -1 → خطأ
  2. العمر = 10 → محتوى محدود
  3. العمر = 25 → كل المحتوى
  4. العمر = 150 → خطأ
  5. العمر = "ABC" → خطأ

الفوائد التقليدية لـ ECP

  1. تقليل عدد الحالات الاختبارية - من الآلاف للعشرات
  2. تغطية أفضل - تضمن إنك اختبرت كل نوع من المدخلات
  3. سهولة الفهم - الطريقة منطقية ومباشرة
  4. توفير الوقت والجهد - بدل لا تضيع وقت على قيم متكررة
نصيحة
استخدم ECP مع Boundary Value Analysis (BVA) للحصول على تغطية أقوى - ECP للفئات، BVA للحدود!

الجزء الثاني: تحدي التفكير التقليدي

المواصفات ≠ الواقع

خلينا نكون صريحين - ECP أداة مفيدة، لكن مش سحر!

الفكرة الأساسية في ECP مبنية على افتراض: "كل القيم في نفس الفئة تتصرف بنفس الطريقة"

لكن هذا الافتراض مش دايم صحيح في الواقع!


ECP هو Heuristic، مش Formula سحرية

Heuristic يعني "قاعدة إبهامية" - أداة تساعدك تفكر، مش قانون مطلق.

المشكلة: كثير testers ياخدوا ECP وكأنه formula رياضية - "قسّم الفئات، اختار ممثل، وخلص!"

الواقع: البرمجيات معقدة، والـ bugs مش دايم تتبع منطق المواصفات.


مثال حقيقي: Standing-State Failure

تخيل معي هذه القصة من موقع تسوق:

السيناريو:

  1. المستخدم يضيف منتج سعره 60 دينار → الخصم 10% يظهر ✅
  2. المستخدم يضيف منتج ثاني سعره 50 دينار → المجموع 110، الخصم يتحول ل 20% ✅
  3. المستخدم يحذف المنتج الثاني → المجموع يرجع 60 دينار...

المفروض: الخصم يرجع 10% اللي صار: الخصم ضل 20%! 🐛

هذا Bug مش راح تلاقيه بـ ECP التقليدي!

ليش؟ لأنك اختبرت القيم الثابتة، لكن ما اختبرت التغييرات في الحالة (State Changes).

هذا النوع من الأخطاء نسميه Standing-State Failure - عندما الحالة السابقة تأثر على السلوك الحالي.


كن متشككاً (Be Skeptical)!

تحذير
لا تثق بأي تقنية بشكل أعمى - حتى لو كانت مشهورة أو "معتمدة من ISTQB"!

ECP أداة قوية، بس:

  • لا تضمن لك إنك راح تلاقي كل الـ bugs
  • لا تغنيك عن الاستكشاف والتفكير النقدي
  • لا تاخد بعين الاعتبار السياق (Context)

أسئلة لازم تسألها:

  • هل الفئات التي حددتها منطقية للنظام الحقيقي؟
  • ما الـ states اللي ممكن تأثر على السلوك؟
  • ما السيناريوهات التي المستخدمين فعلياً راح يعملوها؟
  • في تكامل مع أنظمة خارجية ممكن يغير السلوك؟

خلاصة الدرس

ECP تقنية قوية لتقليل عدد حالات الاختبار مع الحفاظ على تغطية جيدة

الفكرة الأساسية: قسّم المدخلات لفئات متكافئة، واختر ممثل من كل فئة

استخدمها مع تقنيات أخرى مثل BVA للحصول على نتائج أفضل

لكن تذكّر: ECP هو heuristic، مش formula سحرية

المواصفات مش الواقع - الـ bugs الحقيقية تظهر في السياقات المعقدة

اختبر الفروقات الكبيرة أولاً قبل لا تضيع وقت على التفاصيل الصغيرة

استخدم models متعددة - كل model يكشف bugs مختلفة

كن متشككاً - فكّر بشكل نقدي، واستكشف، ولا تعتمد على أي تقنية بشكل أعمى