الفصل الخامس: إدارة نشاطات الاختبار — Managing the Test Activities

هذا الدرس بيغطّي الفصل الخامس من منهج ISTQB CTFL نسخة 4.0 — Managing the Test Activities. الشرح التفصيلي بالفيديو، وهذا ملخّص مرجعي ترجعله قبل الامتحان.

1. تخطيط الاختبار

• خطة الاختبار بتوثّق: الهدف والنطاق، الاستراتيجية والمقاربة، البيئات والبيانات، الأدوار والمسؤوليات، الجدول والمخاطر، ومعايير الدخول والخروج.
• الخطة مش وثيقة تتكتب مرة وتتنسى — بتتحدّث مع كل تغيير بالمخاطر أو النطاق.
• دور المختبر بتخطيط الـ iteration والإصدار: تقدير الحجم، تحديد المخاطر، والمساهمة بترتيب أولويات الـ backlog.

2. معايير الدخول والخروج

• معايير الدخول (Definition of Ready): شو لازم يكون جاهز قبل ما نبدأ — بيئة، بيانات، ميزة منشورة، متطلبات واضحة.
• معايير الخروج (Definition of Done): إمتى منقول خلصنا — تغطية منفّذة، ما في Bugs عالية مفتوحة، نتائج موثّقة.
• بدون هالمعايير بتصير القرارات مزاجية، وبيتحوّل «خلصنا» لرأي مش لحقيقة.

3. التقدير وترتيب الأولويات

• تقنيات التقدير: المبنيّة على النِسَب والمقاييس (من بيانات مشاريع سابقة)، والمبنيّة على الخبرة (Wideband Delphi، planning poker، والتقدير الثلاثي: متفائل / محتمل / متشائم).
• ترتيب أولويات الحالات: حسب المخاطر، حسب التغطية، أو حسب المتطلبات وأهميتها للعميل.
• القاعدة العملية: لو ما بقي وقت، الحالات عالية المخاطر بتنفّذ أول — مش اللي أسهل.

4. هرم الاختبار والرباعيات

• هرم الاختبار: قاعدة عريضة من اختبارات وحدة سريعة ورخيصة، وسط من اختبارات التكامل والخدمات، وقمّة ضيّقة من اختبارات الواجهة البطيئة والهشّة.
• كل ما صعدت بالهرم: أبطأ، أغلى، وأصعب صيانة — بس أقرب لتجربة المستخدم.
• رباعيات الاختبار (Testing quadrants): بتصنّف الاختبارات حسب إذا كانت تدعم الفريق أو تنقد المنتج، وإذا كانت موجّهة للعمل أو للتقنية — بتساعدك تتأكّد إنّك ما نسيت نوع كامل.

5. إدارة المخاطر

• المخاطرة = احتمالية الحدوث × الأثر لو صار.
• مخاطر المشروع: تأخير، نقص موارد، مشاكل تنظيمية أو بالمورّد.
• مخاطر المنتج: Bugs بالمنتج ممكن تأذي المستخدم أو العمل — وهاي اللي بتوجّه الاختبار.
• تحليل مخاطر المنتج: تحديد المخاطر ← تقييمها (احتمالية وأثر) ← تحديد مستواها.
• ضبط المخاطر: تخفيف (نركّز اختبار أعمق وتقنيات أقوى على العالي منها) ومراقبة مستمرة — المخاطر بتتغيّر خلال المشروع.
• الاختبار المبني على المخاطر بيحدّد: شو نختبر، بأي عمق، وبأي ترتيب.

6. المراقبة والتحكّم والإغلاق

• المقاييس الشائعة: نسبة تنفيذ الحالات، نسبة النجاح والفشل، كثافة الـ Bugs، حالة الـ Bugs وعمرها، والتغطية.
• المقياس وسيلة لاتخاذ قرار — مش هدف بحد ذاته، وما بينحكم على المختبرين فيه.
• تقرير تقدّم الاختبار خلال الدورة، وتقرير إغلاق الاختبار بنهايتها (شو انعمل، شو النتائج، شو المخاطر المتبقية).
• التقرير بيتغيّر حسب الجمهور: تفاصيل تقنية للفريق، وصورة مخاطر وقرار للإدارة والعميل.

7. إدارة الإعدادات (Configuration Management)

• بتضمن إنّ كل عنصر اختبار معروف نسخته ومرتبط بنسخة البرنامج المقابلة له.
• بدونها: بتختبر نسخة وبتبلّغ عن Bug على نسخة ثانية — وبتضيع القدرة على إعادة إنتاج النتائج.
• بتشمل الـ testware كمان: حالات، بيانات، Scripts، وبيئات.

8. إدارة الـ Bugs

• تقرير الـ Bug هدفه: يخلّي المطوّر يعيد إنتاج المشكلة بدون ما يسألك.
• عناصره: عنوان واضح، معرّف، البيئة والنسخة، خطوات إعادة الإنتاج، النتيجة المتوقّعة والفعلية، الدليل (صورة/فيديو/لوق)، الشدّة والأولوية، والحالة.
• الشدّة (Severity) حكم تقني على أثر الـ Bug، والأولوية (Priority) قرار عمل على ترتيب إصلاحه — وممكن يختلفوا.
• دورة حياة الـ Bug: جديد ← مقبول/مرفوض ← قيد الإصلاح ← جاهز للاختبار ← مغلق أو مفتوح من جديد.
• تقارير الـ Bugs كمان مصدر لتحسين العملية — تحليل أسبابها الجذرية بيمنع تكرارها.

بالدرس الجاي: الفصل السادس — أدوات دعم الاختبار (Test Tools).