تقنيات تصميم الاختبار: Equivalence Partitioning و Boundary Value Analysis و Decision Table

حقل «العمر» بيقبل من 18 لـ 65. كم حالة اختبار بدك تكتب؟

الجواب العشوائي: نجرّب 20، 30، 40، 50 وهيك. الجواب المدروس: ست قيم بتغطّي كل السلوك المحتمل، وأي قيمة زيادة عليهم ما بتضيف معلومة جديدة.

هذا الفرق هو كل الموضوع. تقنيات تصميم الاختبار مش أكاديميّة — هي أدوات بتوصلك لتغطية أعلى بعدد حالات أقل، ووقتك محدود دايماً.

1) تقسيم التكافؤ — Equivalence Partitioning (EP)

الفكرة

قسّم المدخلات لمجموعات (partitions) كل مجموعة النظام بيعاملها بنفس الطريقة. إذا قيمة من المجموعة نجحت، المفروض كل قيم المجموعة تنجح. فبتختبر قيمة واحدة من كل مجموعة.

مثال محلول: حقل العمر (18–65)

المجموعة	النوع	قيمة تمثيلية	النتيجة المتوقّعة
أقل من 18	غير صالحة	10	رسالة رفض
من 18 لـ 65	صالحة	35	قبول
أكبر من 65	غير صالحة	80	رسالة رفض
نص بدل رقم	غير صالحة	abc	رسالة رفض
فاضي	غير صالحة	``	رسالة حقل مطلوب

خمس حالات بدل عشرين، وبتغطية أعلى — لأنّ العشرين كانوا كلهم من نفس المجموعة الصالحة تقريباً.

القاعدة اللي كثير بينسوها

المجموعات غير الصالحة تُختبر وحدة وحدة. لو حطّيت عمر 10 ونص abc بنفس الحالة، وطلعت رسالة خطأ، ما بتعرف مين منهم سبّبها — وممكن يكون واحد فيهم ما اتفحص أصلاً.

2) تحليل قيم الحدود — Boundary Value Analysis (BVA)

الفكرة

الـ Bugs بتتجمّع على حدود المجموعات، مش بوسطها. سبب بسيط: المبرمج بيكتب > بدل >=، فبينكسر السلوك على القيمة الحديّة بالضبط.

فبدل ما تختبر وسط المجموعة، اختبر أطرافها.

مثال محلول: نفس حقل العمر (18–65)

BVA بقيمتين (المعتمد بـ ISTQB) — القيمة الحديّة والقيمة اللي قبلها/بعدها مباشرة:

القيمة	التصنيف	المتوقّع
17	خارج الحد الأدنى	رفض
18	الحد الأدنى	قبول
65	الحد الأعلى	قبول
66	خارج الحد الأعلى	رفض

BVA بثلاث قيم: بتضيف 19 و 64 كمان (داخل الحدود مباشرة). أدق، وأغلى.

أين تنفع BVA أكثر شي

• أي حقل رقمي (عمر، مبلغ، كمية، عدد أيام).
• طول النصوص: حقل بيقبل 50 حرف → اختبر 49 و 50 و 51.
• التواريخ: أول الشهر، آخر الشهر، 29 شباط بسنة كبيسة، نهاية السنة.
• الصفحات: صفحة فيها 0 عنصر، عنصر واحد، الحد الأقصى، الحد الأقصى + 1.
• حجم الملفات المرفوعة: بالضبط على الحد، وفوقه بكيلوبايت.

EP و BVA مع بعض

الاثنين بيشتغلوا كفريق: EP بتحدّد المجموعات، و BVA بتختبر حوافّها. لحقل العمر، مجموعتك النهائية:

17, 18, 35, 65, 66, abc, فاضي — سبع حالات بتغطّي الحقل كامل.

3) جدول القرار — Decision Table

الفكرة

لمّا يكون السلوك ناتج عن تركيبة شروط (مش شرط واحد)، الجدول بيمنعك تنسى تركيبة.

مثال محلول: خصم على طلب

القاعدة: «الخصم 20% للعميل المميّز إذا الطلب فوق 100 دينار؛ و 10% لأي عميل إذا الطلب فوق 100 دينار؛ ولا يوجد خصم لو الطلب أقل».

#	عميل مميّز؟	الطلب > 100؟	كوبون صالح؟	النتيجة المتوقّعة
1	نعم	نعم	نعم	خصم 20% + قيمة الكوبون
2	نعم	نعم	لأ	خصم 20%
3	نعم	لأ	نعم	قيمة الكوبون فقط
4	نعم	لأ	لأ	بلا خصم
5	لأ	نعم	نعم	خصم 10% + قيمة الكوبون
6	لأ	نعم	لأ	خصم 10%
7	لأ	لأ	نعم	قيمة الكوبون فقط
8	لأ	لأ	لأ	بلا خصم

ثلاثة شروط ثنائية = 2³ = ثمان تركيبات. الجدول بيضمن إنّك ما نسيت ولا وحدة، وبيكشف كمان الثغرات بالمتطلب نفسه: هل الكوبون بينضاف على الخصم ولا بيستبدله؟ لو المتطلب ما بيجاوب، هذا سؤال لـ Product Owner قبل ما يبدأ التطوير.

نصيحة عملية

لو صار عندك 5 شروط (32 تركيبة)، ما تختبرهم كلهم بالضرورة — احذف التركيبات المستحيلة، ودمج اللي إلها نفس النتيجة، وركّز على التركيبات اللي إلها أثر مالي أو أمني.

4) انتقال الحالات — State Transition Testing

الفكرة

بعض الأنظمة سلوكها بيعتمد على الحالة اللي هي فيها، مش على المُدخل لحاله. مثال كلاسيكي: تسجيل الدخول مع قفل الحساب بعد 3 محاولات فاشلة.

الحالة الحالية	الحدث	الحالة الجديدة
مسجّل خروج	دخول صحيح	مسجّل دخول
مسجّل خروج	دخول خاطئ (محاولة 1، 2)	مسجّل خروج
مسجّل خروج	دخول خاطئ (محاولة 3)	الحساب مقفول
مقفول	دخول صحيح	مقفول (رفض)
مقفول	إعادة تعيين كلمة المرور	مسجّل خروج

الحالات اللي بتكشف Bugs: الانتقالات غير المسموحة. مثلاً: هل الدخول الصحيح على حساب مقفول بيفتحه؟ هل عدّاد المحاولات بيصفّر بعد نجاح؟ هذي بالضبط أشهر ثغرات هذا النوع.

نفس التقنية بتنفع لأي شي إله حالات: حالة الطلب (جديد → مدفوع → مشحون → ملغى)، حالة العقار (مسودّة → منشور → مؤرشف)، حالة الـ bug نفسه.

5) اختبار الاستخدام — Use Case Testing

بدل ما تختبر حقل حقل، اختبر رحلة كاملة كما يستخدمها المستخدم: تسجيل → بحث → اختيار → دفع → تأكيد. هذي التقنية بتكشف Bugs التكامل بين الشاشات — وهي أكثر Bugs بتوصل للمستخدم النهائي، لأنّ كل شاشة لحالها كانت تشتغل.

كيف تختار التقنية؟

نوع المُدخل أو المتطلب	التقنية
حقل إله مدى أو أنواع قيم	EP + BVA
قاعدة عمل فيها أكثر من شرط	Decision Table
سلوك بيعتمد على حالة سابقة	State Transition
رحلة مستخدم عبر عدّة شاشات	Use Case
منطقة عالية المخاطر وما فيها وقت	استكشافي موجّه + المخاطر

القاعدة العملية: ابدأ من الخطر. المسار اللي فيه مال أو بيانات حسّاسة أو استخدام يومي كثيف بياخد التقنيات الأدق. الشاشة اللي بتُستخدم مرّة بالسنة بتاخد حالة أو اثنتين.

تمرين سريع (جاوب قبل ما تكمّل)

حقل «كلمة المرور» بيقبل من 8 لـ 20 خانة، ولازم يحتوي رقم واحد على الأقل وحرف كبير واحد على الأقل.

اكتب الحالات باستخدام EP + BVA. الجواب المختصر: قيم الأطوال 7, 8, 20, 21، ومجموعات المحتوى بلا رقم، بلا حرف كبير، مستوفي الشرطين، وحالة فاضي. صار عندك ثمان حالات تغطّي الحقل — بدل تخمين عشوائي.

بتلاقي تمارين زيّها بـ بنك أسئلة المقابلات.

أسئلة شائعة

شو الفرق بين Black Box و White Box؟ كل التقنيات فوق هي Black Box — مبنيّة على المواصفات بلا نظر للكود. White Box (تغطية الجمل والقرارات) مبنيّة على بنية الكود نفسه، وغالباً مسؤولية المطوّر.

كم حالة اختبار «كافية»؟ ما فيه رقم. المعيار: كل مجموعة تكافؤ مغطّاة، كل حدّ مُختبر، كل تركيبة شروط ذات أثر مُغطّاة، وكل مسار عالي المخاطر مُغطّى.

هل لازم أستخدم كل التقنيات بكل ميزة؟ لأ. اختَر حسب نوع المتطلب ومستوى الخطر.

هذي التقنيات بتيجي بامتحان ISTQB؟ نعم، وبشكل مكثّف مع أسئلة حسابية — الفصل الرابع من منهج CTFL.

كيف أطبّقها على تطبيقات الموبايل؟ نفس التقنيات، مع إضافة أبعاد الأجهزة وأنظمة التشغيل والاتصال — تفصيلها بـ دورة ISTQB CT-MAT.

خطوتك الجاية

• حوّل التقنيات لحالات مكتوبة: كيف تكتب حالة اختبار فعّالة.
• افهم مكانها بالدورة: STLC من التخطيط للإغلاق.
• الفرق اللي لازم يسبقها: Test Scenario ولا Test Case؟.
• الأساسيات كاملة بالعربي: دورة ISTQB CTFL V4.