ابدأ من هنا
الرئيسية›ISTQB CTFL V4›الفصل السادس: أدوات دعم الاختبار — Test Tools

الفصل السادس: أدوات دعم الاختبار — Test Tools

6 أيلول 2026·14:00·مبتدئأساسياتشرح

الفصل السادس والأخير من منهج 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 اختبار حقيقية

  1. خذ 15 حالة اختبار من مشروع بتعرفه (أو من تمرين الفصل الرابع على شاشة التحويل)
  2. صنّف كل حالة: كم مرة بتنفّذها بالإصدار، وهل الشاشة مستقرّة ولا بعدها بتتغيّر، وشو مستوى المخاطرة
  3. حدّد أي الحالات بتأتمتها أول، وأي حالات الأفضل تبقى يدوية — وبرّر كل قرار بجملة
  4. وزّع الحالات المؤتمتة على مستويات هرم الاختبار: وحدة، تكامل/API، واجهة
  5. اذكر ثلاث فوائد وثلاث مخاطر متوقّعة لو أتمتّ هذه الحالات بمشروعك تحديداً
  6. اختر تصنيفين من تصنيفات الأدوات بتحتاجهم فعلياً بمشروعك، وشو المشكلة اللي بيحلّها كل تصنيف

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

اكشف الحل
  • المرشّحون الأوائل للأتمتة: اختبارات الدخان والانحدار اللي بتتكرّر كل إصدار، الحسابات والقواعد المالية، والتحقّق من الـ API — تكرار عالي وشاشات مستقرّة
  • الأفضل تبقى يدوية: الاختبار الاستكشافي، قابلية الاستخدام والشكل، الحالات اللي بتنفّذ مرة أو مرتين، والشاشات اللي لسّا تصميمها بيتغيّر كل sprint
  • التوزيع على الهرم: منطق الحساب على مستوى الوحدة، قواعد العمل والتكامل على مستوى API، وسيناريوهين أو ثلاثة بس من طرف لطرف على الواجهة
  • فوائد متوقّعة: تشغيل الانحدار كل ليلة بدل كل أسبوع، نتائج ثابتة بلا خطأ بشري، ووقت المختبر بيتفرّغ للاستكشافي
  • مخاطر متوقّعة: كلفة صيانة الـ Scripts مع كل تغيير بالواجهة، اختبارات هشّة (flaky) بتفقد ثقة الفريق، والاعتماد الزائد على الأتمتة وإهمال الاستكشافي
  • تصنيفات مفيدة عملياً: أداة إدارة حالات وBugs (تتبّع وتغطية وتقارير)، وأداة تنفيذ آلي مربوطة بـ CI (تغذية راجعة مع كل دمج) — وممكن أداة اختبار أداء لو المخاطرة بالأداء عالية
تقدّم الشهادة0%

شاهد 90% من الفيديو حتى ينحسب هذا الدرس مكتمل.

خلصت الدرس؟ 👏خذ استراحة 60 ثانية واصطد bugsلعبة Debug Hunt — بتلعبها عالموبايل كمان
العب هسا

النقاش 🔻

اكتب سؤالك أو ملاحظتك. التعليقات بتظهر بعد المراجعة.