الفصل السادس: أدوات دعم الاختبار — Test Tools
الفصل السادس والأخير من منهج ISTQB CTFL V4 بالعربي: تصنيفات أدوات الاختبار، فوائد أتمتة الاختبار ومخاطرها، وشو بينفع يتأتمت وشو الأفضل يبقى يدوي.
قبل ما تبدأ
- خلّص الفصول من الأول للخامس
- ما بتحتاج تكون كتبت Script أتمتة قبل — الفصل بيحكي عن المفاهيم مش عن أداة معيّنة
الخلاصة بنقاط
- الأداة بتدعم الاختبار — ما بتعوّض عن تفكير المختبر ولا عن تصميم حالات صح
- تصنيفات الأدوات بتغطّي كل النشاطات: إدارة، اختبار ساكن، تصميم وتنفيذ، غير وظيفي، DevOps، وتعاون
- أكبر فايدة للأتمتة: تكرار سريع وموثوق للاختبارات المتكرّرة وتغذية راجعة أسرع
- أكبر خطر: توقّعات غير واقعية وتجاهل كلفة الصيانة — Scripts مهملة أسوأ من لا شي
- قرار الأتمتة بيتحدّد بالتكرار والاستقرار والمخاطر — مش بالحماس للأداة
هذا الدرس بيغطّي الفصل السادس والأخير من منهج ISTQB CTFL نسخة 4.0 — Test Tools. الشرح التفصيلي بالفيديو، وهذا ملخّص مرجعي ترجعله قبل الامتحان.
1. دور الأدوات بالاختبار
- الأداة بتدعم نشاطات الاختبار — ما بتفكّر مكانك ولا بتصمّم حالات بدالك.
- أتمتة عملية سيّئة بتعطيك نتائج سيّئة أسرع بس — لازم العملية تكون صحيحة قبل ما تأتمتها.
- الفايدة الأكبر بتكون بالمهام المتكرّرة والدقيقة والمملّة: تنفيذ، مقارنة، قياس، وتوليد بيانات.
2. تصنيفات أدوات الاختبار
- إدارة الاختبار والـ testware: حالات الاختبار، التتبّع، التغطية، والـ Bugs (مثل Jira وأدوات إدارة الاختبار المرتبطة فيه).
- دعم الاختبار الساكن: تحليل ساكن للكود ومراجعات.
- تصميم وتجهيز الاختبار: توليد حالات وبيانات اختبار وتجهيز البيئة.
- تنفيذ الاختبار وقياس التغطية: تشغيل الاختبارات آلياً وقياس ما تمت تغطيته.
- الاختبار غير الوظيفي: أداء وحمل وأمان.
- DevOps: خطوط CI/CD اللي بتشغّل الاختبارات مع كل تغيير.
- التعاون: أدوات التواصل ومشاركة المعرفة بين الفريق.
- أدوات مساندة: جداول بيانات، SQL، أدوات debugging وتصوير الشاشة — أدوات ما انعملت للاختبار بس بتخدمه.
3. فوائد أتمتة الاختبار
- توفير وقت وجهد بالمهام المتكرّرة، خصوصاً اختبارات الانحدار.
- تقليل الأخطاء البشرية وثبات التنفيذ — نفس الخطوات كل مرة.
- تغذية راجعة أسرع، خصوصاً لما تكون مربوطة بالـ CI.
- قياسات موضوعية يصعب أخذها يدوياً — مثل التغطية.
- تفريغ وقت المختبر للشغل اللي بيحتاج عقل: استكشافي، تصميم، تحليل مخاطر.
4. مخاطر أتمتة الاختبار
- توقّعات غير واقعية: الأداة ما بتحل مشاكل التخطيط أو المتطلبات الغامضة.
- الاستهانة بالكلفة: إدخال الأداة، التدريب، وبالأخص صيانة الـ Scripts مع كل تغيير بالواجهة.
- استعمال الأداة بمكان الأفضل فيه الاختبار اليدوي (استكشافي، قابلية استخدام).
- الاعتماد الزائد على الأتمتة وإهمال الاختبار اليدوي والتفكير النقدي.
- إهمال إدارة نسخ الـ testware — Scripts مش متزامنة مع نسخة التطبيق.
- الاعتماد على مورّد واحد، أو مشاكل توافق مع أدوات التطوير والبيئات.
- اختبارات هشّة (flaky) بتفشل عشوائياً — بتقتل ثقة الفريق بالنتائج أسرع من أي شي.
5. شو بينفع يتأتمت وشو الأفضل يبقى يدوي؟
- أتمت لما تجتمع: تكرار عالي + سلوك مستقر + مخاطرة تستاهل.
- مرشّحون ممتازون: اختبارات الدخان، الانحدار، الحسابات والقواعد، واختبارات الـ API.
- خلّيها يدوية: الاختبار الاستكشافي، قابلية الاستخدام والشكل، وأي شاشة تصميمها لسّا بيتغيّر.
- وزّع الأتمتة حسب هرم الاختبار من الفصل الخامس: أكثر شي على مستوى الوحدة والـ API، وأقل شي على الواجهة.
6. وصلت لنهاية الدورة
بهيك بتكون غطّيت الفصول الستّة لمنهج ISTQB CTFL نسخة 4.0. النصيحة قبل الامتحان: ارجع لنقاط الخلاصة بكل درس، تأكّد إنّك فاهم المصطلح مش حافظه، وطبّق التمارين على مشروع حقيقي — أسئلة الامتحان عادة بتختبر الفهم بسيناريو، مش نصّ التعريف.
قرّر شو بتأتمت من suite اختبار حقيقية
- خذ 15 حالة اختبار من مشروع بتعرفه (أو من تمرين الفصل الرابع على شاشة التحويل)
- صنّف كل حالة: كم مرة بتنفّذها بالإصدار، وهل الشاشة مستقرّة ولا بعدها بتتغيّر، وشو مستوى المخاطرة
- حدّد أي الحالات بتأتمتها أول، وأي حالات الأفضل تبقى يدوية — وبرّر كل قرار بجملة
- وزّع الحالات المؤتمتة على مستويات هرم الاختبار: وحدة، تكامل/API، واجهة
- اذكر ثلاث فوائد وثلاث مخاطر متوقّعة لو أتمتّ هذه الحالات بمشروعك تحديداً
- اختر تصنيفين من تصنيفات الأدوات بتحتاجهم فعلياً بمشروعك، وشو المشكلة اللي بيحلّها كل تصنيف
ما في إجابة وحيدة صح — المهم يكون قرار الأتمتة مبني على التكرار والاستقرار والمخاطرة، مش على «هاي حالة سهلة أأتمتها».
اكشف الحل
- المرشّحون الأوائل للأتمتة: اختبارات الدخان والانحدار اللي بتتكرّر كل إصدار، الحسابات والقواعد المالية، والتحقّق من الـ API — تكرار عالي وشاشات مستقرّة
- الأفضل تبقى يدوية: الاختبار الاستكشافي، قابلية الاستخدام والشكل، الحالات اللي بتنفّذ مرة أو مرتين، والشاشات اللي لسّا تصميمها بيتغيّر كل sprint
- التوزيع على الهرم: منطق الحساب على مستوى الوحدة، قواعد العمل والتكامل على مستوى API، وسيناريوهين أو ثلاثة بس من طرف لطرف على الواجهة
- فوائد متوقّعة: تشغيل الانحدار كل ليلة بدل كل أسبوع، نتائج ثابتة بلا خطأ بشري، ووقت المختبر بيتفرّغ للاستكشافي
- مخاطر متوقّعة: كلفة صيانة الـ Scripts مع كل تغيير بالواجهة، اختبارات هشّة (flaky) بتفقد ثقة الفريق، والاعتماد الزائد على الأتمتة وإهمال الاستكشافي
- تصنيفات مفيدة عملياً: أداة إدارة حالات وBugs (تتبّع وتغطية وتقارير)، وأداة تنفيذ آلي مربوطة بـ CI (تغذية راجعة مع كل دمج) — وممكن أداة اختبار أداء لو المخاطرة بالأداء عالية
شاهد 90% من الفيديو حتى ينحسب هذا الدرس مكتمل.





النقاش 🔻