الفصل الثاني: الاختبار خلال دورة حياة تطوير البرمجيات — Testing Throughout the SDLC

هذا الدرس بيغطّي الفصل الثاني من منهج ISTQB CTFL نسخة 4.0 — Testing Throughout the Software Development Lifecycle. الشرح التفصيلي بالفيديو، وهذا ملخّص مرجعي ترجعله قبل الامتحان.

1. الاختبار وسياق دورة حياة التطوير

• نموذج التطوير اللي بتشتغل فيه بيحدّد إمتى بتختبر وكيف بتختبر — مش بس بيغيّر الجدول الزمني.
• النماذج التسلسلية (Waterfall، V-model): كل مرحلة بتخلص قبل اللي بعدها. بالـ V-model كل مستوى تطوير بيقابله مستوى اختبار، والتصميم بيبدأ بدري — بس التنفيذ الفعلي بيبقى بالنص الأخير من المشروع.
• النماذج التكرارية والتزايدية (Scrum، Kanban، Spiral): المنتج بينبني على دفعات صغيرة، وكل دفعة بتنختبر لحالها — فالاختبار بيصير مستمر، وحجم الـ regression بيكبر مع كل دورة.
• القاعدة العملية: كل ما قصرت الدورة، زادت الحاجة للأتمتة وللاختبار المبكر.

2. ممارسات جيّدة وأساليب بتقود التطوير

• لكل نشاط تطوير في نشاط اختبار مقابله — ما في مرحلة بتمرّ بدون اختبار.
• كل مستوى اختبار إله هدف مختلف، فما منكرّر نفس الاختبار بمستويين.
• تحليل وتصميم الاختبارات بيبدأ من مرحلة المتطلبات، مش بعد ما يخلص الكود.
• TDD: تكتب اختبار وحدة فاشل ← أبسط كود بينجّحه ← refactor.
• ATDD: تشتق اختبارات القبول من معايير القبول قبل ما يبدأ التطوير.
• BDD: تكتب السلوك المتوقّع بصيغة Given / When / Then بلغة يفهمها الفريق والعميل.
• الفكرة المشتركة بالثلاثة: الاختبار بيقود كتابة الكود، مش بيجي بعدها.

3. DevOps و Shift-left

• DevOps: التطوير والعمليّات بفريق واحد مع CI/CD — كل تغيير بيمرّ على اختبارات آلية والتغذية الراجعة بترجع بسرعة.
• منافعه للاختبار: تغذية راجعة أسرع، بيئات متكرّرة وموثوقة، وثقة أعلى بالإصدار. وحدوده: بده استثمار بالأتمتة والبنية التحتية، والاختبار اليدوي بيضل ضروري (استكشافي وتجربة المستخدم).
• Shift-left: تنقل نشاطات الاختبار لبدري — مراجعة المتطلبات، كتابة الحالات قبل الكود، اختبار static، وأتمتة من أول يوم. كل ما تأخّر اكتشاف الـ Bug، غليت كلفة إصلاحه.
• Retrospectives: بنهاية كل دورة الفريق بيسأل شو زبط وشو لأ وشو منحسّن — وهاي أداة تحسين مستمر للعملية وللاختبار.

4. مستويات الاختبار

• اختبار المكوّن (Component / Unit): وحدة معزولة، عادة المطوّر بيكتبه وبينفّذه.
• تكامل المكوّنات (Component integration): التفاعل والواجهات بين الوحدات جوّا نفس النظام.
• اختبار النظام (System): سلوك النظام كامل من طرف لطرف — وظيفي وغير وظيفي.
• تكامل الأنظمة (System integration): الربط مع أنظمة خارجية مثل بوابة دفع أو خدمة رسائل.
• اختبار القبول (Acceptance): جاهزية النشر — UAT، اختبار تشغيلي (OAT)، تعاقدي وتنظيمي، وألفا وبيتا.
• لكل مستوى: هدف، قاعدة اختبار، كائن اختبار، Bugs نموذجية، ومسؤول محدّد — وهاي أكثر نقطة بتتلخبط بالامتحان.

5. أنواع الاختبار

• وظيفي: شو بيعمل النظام — التغطية بتنقاس بنسبة الوظائف المختبَرة.
• غير وظيفي: كيف بيعمله — أداء، أمان، قابلية استخدام، توافقية، موثوقية، قابلية صيانة ونقل. الغلط الشائع: تأجيله لآخر المشروع.
• Black-box: مبني على المواصفات بدون النظر بالكود.
• White-box: مبني على البنية الداخلية وتغطية الكود.
• Confirmation testing: بعد الإصلاح — بيتأكّد إنّ الـ Bug راح فعلاً.
• Regression testing: بيتأكّد إنّ التغيير ما كسر شي كان شغّال — وهو أول مرشّح للأتمتة.
• المستويات والأنواع بتتقاطع: بتقدر تعمل اختبار أداء (نوع) على مستوى المكوّن أو على مستوى النظام.

6. اختبار الصيانة

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

بالدرس الجاي: الفصل الثالث — الاختبار الساكن (Static Testing).