كيف تكتب حالة اختبار (Test Case) فعّالة — مع قالب ومثال كامل
دليل عملي بالعربي لكتابة حالات اختبار واضحة وقابلة للتكرار: مكوّناتها، من المتطلب للحالات بمثال كامل، تقنيات التصميم، قالب جاهز، وأخطاء شائعة.
فرق كثيرة عندها مئات حالات اختبار، وبرضو بتوصل Bugs للمستخدم. السبب غالباً واحد: الحالات مكتوبة لتُخزَّن، مش لتُنفَّذ. حالة اختبار فعّالة معيارها بسيط: أي شخص بالفريق ينفّذها وبيوصل لنفس النتيجة.
هذا الدليل بيمشي معك من المتطلب لحالات الاختبار، بمثال كامل وقالب جاهز.
ثلاثة مصطلحات بتختلط
- شرط الاختبار (Test Condition): شي ممكن نختبره — «التحقّق من حدود مبلغ التحويل».
- سيناريو الاختبار (Test Scenario): مسار عام — «تحويل مبلغ لحساب آخر».
- حالة الاختبار (Test Case): خطوات محدّدة ببيانات محدّدة ونتيجة متوقّعة واحدة.
القاعدة: السيناريو بيقول شو نختبر، وحالة الاختبار بتقول كيف ننفّذه وشو المفروض يصير بالضبط.
مكوّنات حالة الاختبار
| العنصر | ملاحظة |
|---|---|
| المعرّف والعنوان | عنوان بيوصف الهدف: «تحويل مبلغ يساوي الحد الأعلى المسموح» |
| المتطلّبات المسبقة | حالة النظام والبيانات قبل البدء (حساب مفعّل، رصيد كافي) |
| بيانات الاختبار | القيم الفعلية: 5000، 5001، حرف، فراغ |
| الخطوات | مرقّمة، وكل خطوة إجراء واحد |
| النتيجة المتوقّعة | واحدة، محدّدة، وقابلة للتحقّق من الواجهة |
| الحالة بعد التنفيذ | شو صار بالنظام (رصيد ناقص، إشعار ظهر) |
| الأولوية | لترتيب التنفيذ وقت ضغط الوقت |
| الربط بالمتطلب | رقم المتطلب أو معيار القبول اللي بتغطّيه |
أهم بند: نتيجة متوقّعة واحدة. إذا لقيت حالك بتكتب «و… و… و…»، فهي أكثر من حالة.
من المتطلب لحالات الاختبار — مثال كامل
المتطلب: المستخدم يقدر يحوّل مبلغ من 1 إلى 5000 لحساب مستفيد مفعّل، بشرط إنّ رصيده كافي.
1) تقسيم متكافئ (Equivalence Partitioning)
| الصنف | مثال قيمة | متوقّع |
|---|---|---|
| أقل من الحد الأدنى | 0 | رسالة خطأ واضحة، ما بيتم التحويل |
| ضمن النطاق | 250 | التحويل ينجح |
| أكبر من الحد الأعلى | 6000 | رسالة خطأ واضحة |
| غير رقمي | «abc» | الحقل ما يقبل الإدخال أو رسالة خطأ |
2) تحليل قيم الحدود (Boundary Value Analysis)
القيم اللي بتكشف أكثر الـ Bugs: 0، 1، 5000، 5001.
3) جدول قرار (Decision Table)
| رصيد كافي | مستفيد مفعّل | النتيجة المتوقّعة |
|---|---|---|
| نعم | نعم | التحويل ينجح |
| نعم | لأ | رسالة: المستفيد غير مفعّل |
| لأ | نعم | رسالة: الرصيد غير كافي |
| لأ | لأ | رسالة واحدة واضحة (وحدّد بالمتطلب أي واحدة أولاً) |
الصف الأخير بالذات هو النوع اللي بيكشف نقص المتطلبات — واسأله قبل التطوير، مش بعد.
4) الحالات النهائية
من الجداول فوق بتطلع مجموعة مضبوطة (حوالي 8–10 حالات) بدل ما تكتب 40 حالة متشابهة: قيم الحدود الأربعة + تركيبات جدول القرار + حالة الإدخال غير الرقمي.
كم حالة تكفي؟
التغطية الكاملة مستحيلة — الهدف تغطية مبنية على المخاطر:
- ابدأ بالمسارات اللي فشلها مكلف (دفع، تسجيل دخول، بيانات المستخدم).
- بعدين الحدود والقيم غير الصالحة.
- بعدين الحالات التجميلية والحالات النادرة.
اربطها بمعايير القبول
كل معيار قبول (acceptance criterion) لازم يقابله حالة اختبار واحدة على الأقل. هذا الربط (traceability) بيعطيك جوابين جاهزين بأي وقت: شو غطّينا؟ وشو أثر هذا التغيير؟
قالب جاهز
المعرّف: TC-TRF-004
العنوان: تحويل مبلغ يساوي الحد الأعلى (5000) بحساب رصيده كافي
الأولوية: عالية
المتطلب / معيار القبول: REQ-14
المتطلّبات المسبقة:
- مستخدم مسجّل دخول برصيد 10000
- مستفيد مفعّل ومحفوظ بالقائمة
بيانات الاختبار: المبلغ = 5000
الخطوات:
1. افتح شاشة «تحويل».
2. اختر المستفيد المحفوظ.
3. أدخل المبلغ 5000.
4. اضغط «تحويل» وأكّد العملية.
النتيجة المتوقّعة:
- تظهر رسالة نجاح مع رقم مرجعي للعملية.
- الرصيد الظاهر بيصير 5000.
الحالة بعد التنفيذ: العملية تظهر بسجل الحركات بنفس الرقم المرجعي.أخطاء شائعة
- نتيجة متوقّعة غامضة: «النظام يشتغل صح» — ما بتنفع للتحقّق.
- خطوات مفرطة بالتفصيل: «اضغط على مربّع النص» لكل حقل — بتخلّي الحالة بطيئة وهشّة.
- حالات معتمدة على بعضها: إذا فشلت الأولى، الباقي بيصير غير قابل للتنفيذ.
- بيانات مثبّتة بلا بديل: حالة بتشتغل بس على حساب واحد بالبيئة التجريبية.
- تكرار مقنّع: 10 حالات بتغطّي نفس الصنف بنفس الأثر.
أسئلة شائعة
حالات الاختبار بتنفع مع Agile؟ نعم، بس أخفّ: حالات مختصرة مربوطة بمعايير القبول، ومع الاستكشافي — مش وثائق طويلة تتقادم بعد Sprintين.
أكتبها بأداة ولا بشيت؟ ابدأ بشيت مرتّب أو أداة إدارة اختبار حسب حجم الفريق. الأداة ما بتصلّح حالات مكتوبة غلط.
قديش خطوة مناسبة للحالة؟ غالباً 3 لـ 8 خطوات. أكثر من هيك يعني إنك دامج أكثر من هدف بحالة واحدة.
شو الفرق عن معايير القبول؟ معيار القبول شرط قبول الميزة، وحالة الاختبار الطريقة اللي بتتحقّق فيها من الشرط بخطوات وبيانات.
خطوتك الجاية
- حمّل قوالب QA الجاهزة وفيها قالب حالات الاختبار.
- تقنيات التصميم بالتفصيل بدورة ISTQB CTFL V4.
- وبعد التنفيذ، طبّق تقرير الـ Bug المثالي على أي Bug بتلاقيه.
النقاش 🔻