وكيل Momentic عثر على 269 خطأ خلال ساعة، أي ثلاثة أضعاف Codex

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

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

في معيار القياس الذي نشرته الشركة، عثر Mo خلال 60 دقيقة على 269 خطأ مؤكدًا. واكتشف Codex مع Playwright MCP عدد 86 خطأ، وClaude Code عدد 59، وDevin عدد 27. تبدو النتيجة مثيرة للإعجاب، لكن الخلاصة الأساسية ليست أن «وكيلًا واحدًا هزم البقية». الأهم هو أن الاختبار ينفصل تدريجيًا عن السيناريوهات المكتوبة مسبقًا، ويتحول إلى استكشاف مستقل للمنتج.

كيف يبحث الوكيل عما لا تتضمنه حالة الاختبار

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

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

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

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

الأرقام قوية، لكنه معيار قياس أعده البائع

تضمنت المجموعة 1,396 خطأ موسومًا في أربعة تطبيقات مفتوحة المصدر: Gitea وMetabase وTwenty وSaleor. وخلال ساعة واحدة، حقق Mo استدعاءً قدره 19.3% بدقة 84%. أما Codex فبلغ استدعاؤه 6.2%، لكن دقته كانت أعلى قليلًا عند 86%.

بعبارة أخرى، عثر Mo على عدد أكبر بكثير من العيوب المعروفة، لكن بلاغاته تضمنت أيضًا عددًا أكبر قليلًا من الإنذارات الكاذبة. وهناك فارق في التكلفة كذلك: بلغ سعر الخطأ المؤكد الواحد 2.67 دولار مع Mo، مقابل 0.80 دولار مع Codex. ووفقًا لهذه البيانات، يُعد Mo أكثر فاعلية للاستكشاف الواسع للمنتج، بينما يبدو Codex أوفر عند العمل بميزانية محدودة.

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

ما الذي يمكن للفريق فعله الآن

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

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

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