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

اليوم، يستطيع المطوّرون كتابة عشرات اختبارات الوحدة (unit tests) في ثوانٍ وباستخدام مساعدي البرمجة المدعومين بالذكاء الاصطناعي. ما كان يستغرق ساعات أصبح يُنجَز في ثوانٍ. ونتيجة لذلك لم يَعُد التحدّي يَكْمُن في إنشاء الاختبارات، بل في فهم ما إذا كانت هذه الاختبارات تُضيف قيمة حقيقيّة (value). فقد تنجح هذه الاختبارات جميعها وترفع نسبة تغطية الكود (code coverage) ومع ذلك لا تزيد ثقتك في البرنامج.

وهنا يبرُز سؤال مهم: من يُراجِع هذه الاختبارات؟

عُنُق الزجاجة الجديد (Bottleneck)

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

قد يمتلك مشروعان نسبة تغطية متطابقة لكن مستوى الثقة في اختباراتهما يختلف جذريًا. فقد يحتوي أحدهما على اختبارات مصممة بعناية وتتحقق من السلوكيات الأساسية (behaviors) ولا تفشل إلا عند حدوث تغيير جوهري في النظام. بينما قد يحتوي الآخر على اختبارات مكرّرة وهشّة وتعتمد بشكل كبير على تفاصيل التنفيذ (implementation details). قد تبدو المجموعتان متشابهتين على لوحة المؤشّرات (dashboard)، لكن أي مهندس ضمان جودة سيُدْرِك أن الفرق بينهما كبير.

لماذا يُغيّر الذكاء الاصطناعي طبيعة التحدّي؟

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

عندما تتحوّل الاختبارات إلى دَيْن تقني (Technical Debt)

يُفترَض كثيرًا أن زيادة عدد الاختبارات تعني تلقائيًا جودة أعلى لكن الواقع مختلف، فلكل اختبار تكلفة. يجب تشغيل الاختبارات باستمرار وصيانتها ومراجعتها وتحديثها. وقد تُبطِئ عمليات البناء (build) وتُسبّب أعطالًا وهميّة (false failures) وتزيد من الجُهد المطلوب لإعادة هيكلة الكود (refactoring). وعندما لا يعود الاختبار يضيف قيمة حقيقيّة، فإنه يتحوّل من أصلٍ يدعم الجودة إلى دَيْنٍ تقني.

التطوّر التالي في اختبار البرمجيات

يدخل اختبار البرمجيات اليوم مرحلة جديدة. فقد ركّزت المرحلة الأولى على تشجيع المطوّرين على كتابة الاختبارات ثم جاءت مرحلة أتمتة الاختبارات ودمجها في التكامل المستمر (continuous integration) وتَلَتْها مرحلة تحسين تغطية الاختبارات (test coverage) وسرعة تنفيذها. أما اليوم، فقد أصبح التحدّي مختلفًا. فلم يَعُد يتمثّل في إنتاج المزيد من الاختبارات، بل في تقييم جودتها ومعرفة أيّها يستحق الثقة.

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

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

* المصدر والصورة: https://www.softwaretestingmagazine.com/knowledge/ai-can-generate-unit-tests-but-who-reviews-them