الأدوات الداعمة للاختبار

لماذا يهم

بالنسبة إلى المنتج، يكلّف قرار الأداة الخاطئ مرتين: مال ووقت يُنفقان على أداة لا يستخدمها أحد، وعيوب تتسرّب بينما الفريق منشغل بإعدادها. وحزمة انحدار لا يصونها أحد تتحوّل إلى بناء أحمر يتجاهله الجميع، وهذا أسوأ من غياب الحزمة، لأنه يبدو كأنه اختبار.

أما بالنسبة إلى المختبِر، فالأدوات هي الفرق بين إعادة إدخال الطلبات الخمسين نفسها يدوياً في كل إصدار، وقضاء ذلك الوقت في استكشاف الميزة الجديدة. والفئات تبقى بعد أي منتج: أدوات وظيفتك الأولى لن تكون أدوات وظيفتك الثالثة، لكن الأنشطة التي تدعمها تبقى كما هي.

فئات الأدوات والنشاط الذي تدعمه كل فئة

يعدّد القسم 6.1 من منهج CTFL v4.0 أنواع الأدوات التي تدعم الاختبار. تعلّم كل فئة مع نشاط الاختبار الذي تخدمه، لأن هذا ما سيمكّنك من تمييز الفجوة في فريق حقيقي: «لا شيء يدعم هذا النشاط». والأمثلة أدناه عامة عن قصد؛ فالمنتجات تتغير والفئات لا تتغير.

• أدوات إدارة الاختبار (Test management tools): تدير دورة حياة تطوير البرمجيات (SDLC) والمتطلبات والاختبارات والعيوب والتكوين. مثال: نظام إدارة اختبار يربط حالات الاختبار بالمتطلبات وتقارير العيوب. تخدم التخطيط والمتابعة والتحكم والتقارير.
• أدوات الاختبار الساكن (Static testing tools): تدعم المراجعات والتحليل الساكن. مثال: محلّل ساكن يرصد المتغيرات غير المستخدمة في الشيفرة، أو أداة مراجعة تجمع التعليقات على وثيقة متطلبات. تخدم تحليل الاختبار، حيث يُراجَع أساس الاختبار، وتكشف العيوب في نواتج العمل مثل الشيفرة دون تنفيذها.
• أدوات تصميم الاختبار وتهيئته (Test design and implementation tools): تولّد حالات الاختبار وبياناته وإجراءاته. مثال: أداة تشتق حالات الاختبار من جدول قرار، أو مولّد بيانات اصطناعية. تخدم تصميم الاختبار وتهيئته.
• أدوات تنفيذ الاختبار والتغطية (Test execution and coverage tools): تنفّذ الاختبارات آلياً وتقيس التغطية. مثال: مشغّل اختبارات الوحدة، وإطار أتمتة المتصفح، ومولّد تقارير التغطية. تخدم تنفيذ الاختبار وتغذّي التقارير.
• أدوات الاختبار غير الوظيفي (Non-functional testing tools): تجعل ممكناً ما يصعب أو يستحيل اختباره يدوياً. مثال: مولّد حمل يحاكي آلاف المستخدمين المتزامنين، وماسح أمان، وفاحص إمكانية الوصول. تخدم تنفيذ الاختبارات غير الوظيفية.
• أدوات DevOps: تدعم خط أنابيب التسليم وتتبّع سير العمل والبناء الآلي وCI/CD. مثال: خادم تكامل مستمر يبني كل إيداع ويشغّل الاختبارات. تخدم التهيئة والتنفيذ عند كل تغيير.
• أدوات التعاون (Collaboration tools): تسهّل التواصل. مثال: محادثة الفريق أو ويكي مشترك. تدعم التواصل في كل الأنشطة لا في نشاط واحد، وأوضح ما يكون ذلك في المتابعة والتحكم وفي التقارير.
• أدوات قابلية التوسّع وتوحيد النشر (Scalability and deployment standardisation): الأجهزة الافتراضية والحاويات (Containers، وهي بيئات مُعبّأة تعمل بالطريقة نفسها على أي جهاز)، ليحصل كل مختبِر وكل خط أنابيب على البيئة نفسها. تخدم تهيئة الاختبار (جاهزية البيئة) والتنفيذ المتوازي.
• أي أداة أخرى تساعد في الاختبار: يقول المنهج إن جدول البيانات أداة اختبار عندما يُستخدم للاختبار، مثلاً لحفظ مصفوفة تتبع أو بيانات الاختبار لتشغيلٍ ما.

جرّبها: مولّد حالات الاختبار جرّبها: مصنع بيانات الاختبار جرّبها: مدقّق OpenAPI

ما لا تستطيع أي أداة فعله: الحكم ومرجع الاختبار

كل أداة تنفّذ اختباراً تقارن نتيجة فعلية بنتيجة متوقعة. والنتيجة المتوقعة تأتي من مرجع الاختبار (Test Oracle): مصدر للسلوك الصحيح، مثل متطلب أو مواصفة أو معادلة أو إصدار سابق أو خبير. والأداة لا تملك مرجعاً. فإن لم يكتب أحد النتيجة المتوقعة، فلن تستطيع الأداة إلا أن تقول «تغيّر المخرج» أو «لم يُرمَ استثناء»، وهذا ليس «المخرج صحيح». وهذه هي «مشكلة مرجع الاختبار» (Test oracle problem) التي مرّت بك في درس مواد الاختبار وأساسه ومرجعه، أي صعوبة معرفة النتيجة الصحيحة عموماً؛ والأداة ترثها ولا تحلّها.

وتتسع الفجوة حيث يلزم الحكم: هل رسالة الخطأ مفهومة للعميل؟ هل المتطلب غامض؟ هل استجابة خلال ثانيتين مقبولة يوم الإطلاق؟ الأداة تبلّغ عن فروق وقياسات، والإنسان يقرر هل الفرق إخفاق وهل القياس كافٍ. وهذا القرار جزء من تحليل الحالات الشاذة (Anomalies) أثناء تنفيذ الاختبار، ويبقى معك.

• التشغيل الآلي الأخضر يعني «لم يفشل أي فحص كتبه أحد»، لا «المنتج يعمل».
• الفحوص المكررة دون تغيير تكشف عيوباً جديدة أقل فأقل، كما يقول مبدأ «الاختبارات تَبلى». وهي تظل تحمي من الانحدار، لكن الإنسان وحده يضيف أفكار اختبار جديدة.
• لأدوات الذكاء الاصطناعي الحد نفسه: حالة الاختبار المولَّدة أو الخطورة المقترحة مسودة تراجعها مقابل أساس الاختبار، لا مرجع.

فوائد أتمتة الاختبار ومخاطرها

يبدأ القسم 6.2 من CTFL v4.0 بتنبيه: مجرد اقتناء أداة لا يضمن النجاح، لأن كل أداة جديدة تحتاج إلى جهد لإدخالها وصيانتها والتدريب عليها قبل أن تصبح فوائدها حقيقية ودائمة. ثم يعدّد ست فوائد لأتمتة الاختبار: (1) عمل يدوي متكرر أقل، مثل تنفيذ اختبارات الانحدار وإعادة إدخال بيانات الاختبار نفسها ومقارنة النتائج المتوقعة بالفعلية وفحص الشيفرة مقابل معايير البرمجة؛ (2) أخطاء بشرية بسيطة أقل، لأن الاختبارات تُشتق والبيانات تُنشأ والتشغيل يجري بالطريقة نفسها كل مرة؛ (3) تقييم أكثر موضوعية، مثل التغطية، ومقاييس أعقد من أن يستخرجها الإنسان؛ (4) وصول أسهل إلى المعلومات لإدارة الاختبار والتقارير، مثل الإحصاءات والرسوم البيانية عن تقدم الاختبار ومعدلات الإخفاق ومدة تنفيذ الاختبارات؛ (5) زمن تنفيذ أقصر، فتُكتشف العيوب أبكر وتصل التغذية الراجعة أسرع ويصل المنتج إلى السوق أسرع؛ (6) وقت أكبر للمختبِرين لتصميم اختبارات جديدة وأعمق.

ويعدّد القسم نفسه ثمانية مخاطر تحتاج إلى تحليل وتخفيف قبل اعتماد الأداة وبعده:

• توقعات غير واقعية عن فوائد الأداة، ومنها وظائفها وسهولة استخدامها.
• تقديرات غير دقيقة للوقت والتكلفة والجهد اللازم لإدخال الأداة وصيانة سكربتات الاختبار (Test scripts) وتغيير عملية الاختبار اليدوي القائمة، كأن لا تُرصد أي ميزانية للصيانة.
• استخدام أداة حيث يكون الاختبار اليدوي أنسب، مثل فحص يُجرى مرة واحدة أو أي شيء يحتاج إلى حكم.
• الاعتماد على الأداة إلى حد تجاهل التفكير النقدي البشري.
• الاعتماد على مورّد قد يخرج من السوق أو يوقف الأداة أو يبيعها أو يقدّم دعماً ضعيفاً.
• برمجيات مفتوحة المصدر قد تُهجر، أو تحتاج مكوناتها إلى تحديثات متكررة لتبقى عاملة.
• أداة أتمتة غير متوافقة مع منصة التطوير.
• أداة لا تمتثل للمتطلبات التنظيمية أو معايير السلامة التي يجب أن يستوفيها المنتج.

مثال تطبيقي: جرد الأدوات لفريق صفحة الدفع

مختبِران وخمسة مطورين يُصدرون صفحة دفع إلكترونية كل أسبوعين. كبرت حزمة الانحدار حتى بلغت ⁦180⁩ حالة اختبار يدوية تستغرق ثلاثة أيام، فاقترح قائد الاختبار «أتمتة كل شيء بالأداة التي عرضها المورّد». وقبل الموافقة، سرد المختبِران ما يدعم كل نشاط اليوم:

• التخطيط والتحكم: جدول بيانات وسلسلة محادثة. الفجوة: أداة إدارة بتتبع إلى قصص المستخدم.
• تحليل الاختبار: اجتماعات مراجعة دون دعم من أداة. الفجوة: أداة مراجعة تجمع التعليقات على كل قصة.
• تصميم الاختبار وتهيئته: الحالات والبيانات تُكتب يدوياً. الفجوة: مولّدات القيم الحدّية والبيانات الاصطناعية.
• تنفيذ الاختبار: ⁦180⁩ حالة يدوية، ثلاثة أيام لكل إصدار. الفجوة: مشغّل اختبارات API أولاً، ثم أتمتة المتصفح.
• الاختبار غير الوظيفي: لا شيء. الفجوة: مولّد حمل وفحص لترويسات الأمان.
• البناء والنشر: خادم تكامل مستمر يبني كل إيداع لكنه لا يشغّل أي اختبار. الفجوة: إعداد، لا شراء.
• البيئات: خادم staging واحد مشترك يكتب فيه المختبِرون فوق عمل بعضهم. الفجوة: حاويات ليحصل كل مختبِر على بيئة متطابقة ومنفصلة.

من الجرد إلى القرار

يغيّر الجرد القرار. فمن الحالات الـ ⁦180⁩، تفحص ⁦60⁩ حالة قواعد السلة والتسعير والدفع التي يمكن التحقق منها عبر API. وحين تُؤتمت فحوصاً على مستوى API تتعطّل أقل من سكربتات المتصفح وتعمل خلال دقائق، لذا تأتي أولاً وتُربط بخادم التكامل المستمر القائم، وهذا يسدّ فجوة DevOps دون أي شراء. وتحصل أداة المورّد على تجربة أولية لأربعة أسابيع مقابل قائمة المخاطر: التوافق مع إطار الواجهة الأمامية للفريق، وجهد الصيانة بعد تغيير حقيقي واحد في الواجهة، وشروط الدعم، وإمكانية تصدير النتائج، وهل تفي تقاريرها بمتطلبات الجهة التنظيمية للمدفوعات. وتبقى حالات الواجهة يدوية حتى تجيب التجربة، وتذهب الأيام الموفَّرة إلى الاختبار الاستكشافي.

جرّبها: مختبِر REST API جرّبها: محلّل زمن الاستجابة جرّبها: محلّل ترويسات الأمان

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0ISTQB · 2024منهج ISTQB المتقدم لتصميم حلول أتمتة الاختبار وتنفيذها وصيانتها وبنيتها.