الذكاء الاصطناعي في اختبار البرمجيات: ما الذي تغيّر وما الذي لم يتغيّر

ما الذي غيّره الذكاء الاصطناعي فعلًا في اختبار البرمجيات

• لم تعد كتابة الاختبارات هي عنق الزجاجة. كانت ترجمة سلوك معروف إلى شيفرة اختبار تستهلك معظم العمل، أما الآن فتكلفتها تكاد تكون معدومة، وهو ما ينقل القيد إلى تحديد ما ينبغي أن يكون صحيحًا.

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

ما الذي لم يتغيّر

ما الذي صار أصعب

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

أما المخاطرة الجديدة الثانية فأدقّ: الوكيل المطلوب منه أن يجعل فحصًا ما ينجح قد يُرضي الفحص بدل أن يصلح المنتج. الفحوص الغامضة تدعو إلى ذلك، أما الفحوص المحددة القابلة للدحض فلا.

العادة التي تستحق التبنّي

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

المقياس الأسرع في التضليل

كانت نسبة التغطية دائمًا مؤشرًا بديلًا ناقصًا، وقد أفسدها التوليد تمامًا، وهذا مهم لأنها ما زالت ما تُبلّغ عنه معظم الفرق.

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

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

من أين تبدأ

تغطي لوحة المعلومات الأمر نفسه لمن لا يريد تثبيتًا محليًا، ومجموعة الأوامر الكاملة موجودة في مستودع CLI.

إذا كان خط الأنابيب يخصّ فريقًا آخر، فإن GitHub App هو المسار الأقل مقاومة: فهو عبارة عن webhook، ولا يغيّر شيئًا في مستودعك، ويُطلَق حين يُبلّغ بناؤك بأن الإصدار الجديد صار حيًّا. وإذا أردت بدل ذلك أن يكون الفحص ظاهرًا داخل المستودع، فإن خطوة GitHub Actions تفي بالغرض.

ما الذي تفعله TestSprite بشأن الجزء الذي صار أصعب

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

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

وما لم يتغيّر يبقى بلا تغيير هنا أيضًا: أنت من يحدد معنى الصحيح، وبيانات الاختبار والبيئات تبقى مسؤوليتك. ما تكسبه هو أن التغطية تتوقف عن التخلّف عن وتيرة وصول الشيفرة.