لا تَتَمَحْوَر مقاييس اختبار البرمجيات حول الأرقام. إنها موجودة للإجابة عن سؤالين: أولاً، ما مدى جودة البرمجيات التي نقدّمها للعملاء؟ وثانياً، هل يُجدِي أسلوبنا في الاختبار نفعًا بالفعل أم أننا نكتفي بأداء الإجراءات شكليًا وحسب؟

لسنواتٍ عديدة، كان قادة فِرَق الاختبار يجيبون عن السؤالين بالاعتماد على مجموعة ثابتة من المقاييس: عدد الاختبارات قيد التنفيذ وعدد الاختبارات الناجحة ومستوى تغطية الاختبارات وعدد الأخطاء البرمجية المُكتشفَة مصنّفةً حسب درجة خطورتها. وقد أثبتت هذه المقاييس فعاليتها لأنها كانت تعكس سلامة وكفاءة عملية الاختبار. فوجود مجموعة تضم ثلاثة آلاف اختبار كان يعني إنجاز أشهر من العمل الفعلي وأيضًا مُعدّل النجاح المُسْتَقِر كان يشير إلى أن المُنتَج تحت السيطرة. في حين كان انخفاض عدد الأخطاء الحرجة دليلاً على أن مستوى الجودة يسير في الاتجاه الصحيح.

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

لماذا توقّفت الأرقام القديمة عن عكس الواقع

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

بعد ذلك انخفض مُعدّل النجاح. تعتمد العديد من أدوات الذكاء الاصطناعي في كتابة الاختبارات على قراءة الكود الذي من المفترض أن تفحصَه وبالتالي تؤكّد الاختبارات أن الكود يؤدّي وظيفته كما هو متوقّع. يتم تسجيل الأخطاء كسلوك متوقّع (expected behavior) ويصبح الاختبار ناجحًا. كان مُعدّل نجاح 98% يعني سابقًا أن المُنتَج يعمل بشكل جيّد في الغالب. أما الآن، فقد يعني أيضًا أن الاختبارات تتّفق في الغالب مع العيوب.

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

المقاييس التي توضح جودة ما تُقدّمه

واجه فريقنا هذه المشكلة أيضًا، وتوقفت تلك المقاييس عن تقديم أي معلومات يمكن البناء عليها لاتخاذ إجراءات عمليّة. أما المقاييس المذكورة أدناه، فقد أثبتت جدواها عند إعادة تصميم نظام التقارير بدْءًا من منظور العميل، إذ أن هذا هو الموضع الذي تتحدّد فيه الجودة فعليًا.

• مُعدّل تسرّب العيوب (Defect Escape Rate): من بين كل العيوب التي وُجِدَت في فترة ما، كم عدد العيوب التي تم العثور عليها بعد أن قلنا أن العمل قد تم وكم عدد العيوب التي وصلت إلى العملاء؟
• مؤشرات الإنتاج (Production Signals): تُكمِل مقاييس الإنتاج الصورة الشاملة إذ تشمَل: اتجاهات العيوب التي يبلّغ عنها العملاء (trends) وأعداد الحوادث (incidents) والمدة الزمنية التي تظل فيها العيوب قائمة قبل اكتشافها.

المقاييس التي توضح ما إذا كانت طريقتك لا تزال فعّالة

• مُعدّل اكتشاف العيوب داخليًا (Defect Discovery Rate): لست بحاجة إلى انتظار تسرّب العيوب إلى مرحلة الإنتاج لتلاحظ حدوث ذلك، فمُعدّل اكتشاف العيوب الجديدة داخليًا يُعد أول مؤشر تحذيري ويُقصَد به عدد العيوب غير المكتشفة سابقاً التي ترصدها كل دورة اختبار regression في النُّسَخ البرمجية الداخلية. فمجموعة الاختبارات الفعّالة والمتطوّرة تواصل الكشف عن مشكلات حقيقية. أما إذا اتجه مُعدّل الاكتشاف هذا نحو الصفر بينما يستمر الكود في التغيّر، فهذا يعني أن الاختبارات قد توقفت عن التعلّم (learning) وستدرك ذلك قبل أن يتأثر أي عميل.
• الكَشْف عن العيوب حسب المرحلة (Defect Detection by Phase): يُظهِر اكتشاف العيوب حسب المرحلة التأخّر التدريجي. تتبَّعْ مكان اكتشاف العيوب في مراحل التطوير وهي الوحدة (unit) والتكامل (integration) والنظام (system) والقبول (acceptance). إذا انتقلت العيوب باستمرار نحو المراحل اللاحقة فهذا يعني أن الاختبارات المبكّرة تفقد فعاليتها.
• تحليل مصدر الاكتشاف (Source-of-discovery Analysis): يكشف تحليل مصدر الاكتشاف عن المنشأ الفعلي للعيوب التي تم العثور عليها إذ يوضّح نسبة العيوب التي كشفت عنها الاختبارات المُضافة في الإصدارات الأخيرة مقارنةً بتلك التي رصدتها مجموعة الاختبارات الأساسية القديمة وكذلك النسبة المكتشفة عبر الاختبارات الاستكشافية (exploratory testing) مقابل الاختبارات المؤتمتة (automated tests). وإذا استمر المختبرون البشريّون في العثور على عيوب تغفل عنها آلاف الاختبارات المُولَّدة آليًا فإن هذه الفجوة تُعَد مقياسًا دقيقًا لمدى سطحيّة مجموعة الاختبارات المُولَّدة.
• مراجعة النقاط العمياء (Blind-spot Review): تأتي مرحلة مراجعة النقاط العمياء عندما يفلت أحد العيوب من الاختبارات لتُكمِل الحلقة إذ ينبغي طرح سؤال واحد عن كل عيب أفلت من الرّصد: هل حاوَلَتْ أي من الاختبارات الموجودة ضمن المجموعة اكتشافه من الأساس؟ إن تصنيف هذه العيوب إلى فئتين وهما وجود اختبار لكنه أخفق في رصد العيب مقابل عدم وجود أي اختبار يغطّي هذا الجانب يُحدّد لك ما إذا كان يتعيّن عليك تعديل الاختبارات ذاتها أم تعديل الاستراتيجية التي تُنتِج تلك الاختبارات.

امتلاك الإجابة

لستَ بحاجة إلى المقاييس جميعها في اليوم الأول. ابدأ بـمُعدّل تسرّب العيوب كونه الرقم الذي تُدركه القيادة بالفعل. كذلك مُعدّل اكتشاف العيوب داخليًا إذ يُعَد هذا الأخير أقل وسائل الإنذار المبكّر تكلفةً على الإطلاق.

ينبغي أن تتضمّن مجموعة العمل الإجابة على الأسئلة: هل البرنامج المُسلّم جيّد؟ (مُعدّل تسرّب العيوب ومؤشرات الإنتاج) وهل لا يزال النّهْج المُتّبع فعّالاً؟ (مُعدّل اكتشاف العيوب داخليًا والكَشْف عن العيوب حسب المرحلة). من خلال الإجابة على هذه الأسئلة، يضمن الفريق استمرار فعاليّة عملية الاختبار.

* المصدر والصورة: https://www.softwaretestingmagazine.com/knowledge/qa-metrics-that-still-mean-something-in-the-ai-era/