أفضل أداة اختبار بالذكاء الاصطناعي تتحدد حسب الفجوة التي لديك

أفضل أداة اختبار بالذكاء الاصطناعي لثلاث فجوات مختلفة

• الكمّ. «لا نملك اختبارات تقريبًا.» ما تحتاجه هو التوليد. وانتبه إلى أن الاختبارات المولَّدة ترث افتراضات الكود.

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

• الثقة. «الاختبارات خضراء، ومع ذلك تنهار الإصدارات، ومعظم الكود يأتي من وكيل.» ما تحتاجه هو تحقّق مقابل المنتج أثناء تشغيله.

السؤال الذي يفرز المرشّحين

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

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

السؤال الثاني

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

الفخّ الموجود في كل فئة

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

حيلة العرض التوضيحي التي ينبغي الانتباه لها

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

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

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

كيف تُجري تقييمًا سليمًا

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

إذا كنت تفضّل ألّا تثبّت شيئًا، فلوحة التحكم تؤدي الغرض نفسه. وكل ما يستطيع سطر الأوامر فعله بخلاف ذلك موجود في مستودع CLI.

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

ما الفجوة التي بُنيت TestSprite لمعالجتها

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

وهي تولّد الحالات وتصمد أمام تغيّر الواجهة، فتلامس بذلك فجوتي الكمّ والصيانة أيضًا، لكن ذلك في خدمة الحكم النهائي لا أنه الغاية.

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