حين يكتب الوكيل الاختبار: لماذا لم تعد نسبة التغطية تعني شيئاً؟

في 2019 كانت الجملة الأشهر في اجتماع مراجعة الجودة: «التغطية 40% فقط، نحتاج مزيداً من الاختبارات». في 2026 صارت الجملة نفسها بلا معنى تقريباً. ليس لأن الفرق توقّفت عن الاهتمام بالجودة، بل لأن العائق الذي كانت نسبة التغطية تقيسه — وهو صعوبة كتابة اختبار — اختفى.

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

ما الذي تغيّر فعلاً؟

سقف كتابة الاختبارات كان بشرياً وثابتاً منذ عقدين: مهندس جودة ماهر يكتب ويُثبّت ما بين 5 و10 اختبارات شاملة (E2E) أسبوعياً، وهذا المعدّل ينهار بعد أن تتجاوز المجموعة نحو 150 اختباراً، لأن صيانة الموجود تلتهم ساعات كتابة الجديد. هذا هو السبب الحقيقي وراء مجموعات الاختبارات الراكدة في معظم الشركات: لم تكن مشكلة أولويات، بل مشكلة حسابية.

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

والأدوات لحقت بالتحوّل بسرعة. Playwright حسم عملياً حرب اختبارات المتصفح بفضل الانتظار التلقائي الذي جعل الاختبارات المتذبذبة أقلّ شيوعاً. وJetBrains أطلقت مهارة للوكلاء باسم finding-tests تُغني الوكيل عن التجوال العشوائي في قاعدة الكود بحثاً عن الاختبار المناسب، وشحنتها أداةً مستقلّة عبر MCP تعمل مع وكلاء خارجيين.

المشكلة: اختبار يمرّ دائماً ولا يختبر شيئاً

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

الأنماط المتكرّرة:

• تأكيدات ضعيفة: تحقّق مثل toBeVisible() على عنصر ظاهر دائماً في الصفحة. يمرّ إلى الأبد ولا يختبر شيئاً.
• محدّدات مهلوسة: الوكيل يخمّن اسم عنصر بدل أن يقرأه من الصفحة الفعلية، فينجح محلياً ويتذبذب في التكامل المستمر.
• انتظارات ثابتة: waitForTimeout بدل انتظار الحالة الفعلية — يمرّ على جهازك السريع ويفشل عشوائياً على خادم مزدحم.
• تحقّق من الوصول لا من النتيجة: الاختبار يتأكّد أن الصفحة حُمّلت، لا أن العملية تمّت بنجاح.

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

الرقم الذي يلخّص الفجوة

بحث Forrester في أبريل 2026 عن منصّات الاختبار المستقلّة وجد أن المستخدمين بلغوا تغطية أتمتة بين 51% و60% — قفزة حقيقية من سقف تاريخي عند 25% تقريباً. لكنهم في الوقت نفسه قيّموا الاستقلالية الكاملة عند 2.2 من 5، ووصفوا الأدوات بأنها «مساعد لا بديل عن المختبِر البشري».

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

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

المقياس البديل: هل ينكسر الاختبار حين يُكسَر الكود؟

المقياس الذي عاد إلى الواجهة في 2026 ليس جديداً — بل قديم وكان يُعدّ رفاهية أكاديمية: درجة الطفرة (Mutation Score).

الفكرة بسيطة إلى حدّ الأناقة: غيّر الكود عمداً تغييراً صغيراً — اقلب > إلى >=، احذف سطراً، بدّل true بـfalse — ثم شغّل الاختبارات. إن ظلّت كلها تمرّ، فاختباراتك لا تختبر هذا السطر، مهما قالت نسبة التغطية.

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

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

ست خطوات عملية، مرتّبة بالأثر

1. ضع بوّابة طفرة على الكود الجديد فقط. تشغيل اختبار الطفرة على قاعدة كود كاملة مكلف؛ تشغيله على الملفّات المعدَّلة في طلب الدمج رخيص ويلتقط الاختبارات الفارغة قبل الدمج مباشرة.
2. أرضِ الوكيل في الصفحة الحقيقية. استخدام خادم Playwright عبر MCP يجعل الوكيل يقرأ شجرة الوصول الفعلية ويختار محدّدات مبنية على الأدوار بدل أن يخمّن أسماء عناصر غير موجودة.
3. قيّد التوليد في الأمر نفسه. اطلب صراحةً getByRole أو getByTestId، وامنع الانتظارات الثابتة، واشترط تأكيداً على النتيجة لا على التحميل.
4. شغّل كل اختبار مولّد ثلاث مرات قبل الدمج. الاختبار الذي يتذبذب في ثلاث تشغيلات متتالية على جهازك سيتذبذب يومياً في التكامل المستمر.
5. اعزل المتذبذب بدل حذفه. القاعدة الشائعة: اختبار يفشل 3 مرات من 10 يُصنَّف متذبذباً ويُنقل إلى الحجر الصحّي؛ أمّا 4 فشلات من 20 فهي غالباً مشكلة بيئة لا مشكلة كود.
6. احتفظ بالحكم النهائي حتمياً. اترك للوكيل التنقّل والتعافي الذاتي، لكن اجعل قرار النجاح أو الفشل تأكيداً حتمياً مكتوباً — لا رأي نموذج في لقطة شاشة.

ملاحظة عن مصادر هذه الأرقام

كثير من التحليلات المتداولة حول «أزمة الاختبارات المولّدة» يصدر عن شركات تبيع أدوات تحليل التذبذب. هذا لا يُبطل الملاحظات — الأنماط التقنية قابلة للتحقّق بنفسك في أي مشروع — لكنه يستدعي حذراً من تضخيم حجم المشكلة. تحقّق من درجة الطفرة في مشروعك أنت قبل أن تشتري حلّاً لمشكلة قد تكون أصغر مما يُقال.

أسئلة شائعة

هل يعني هذا أن نتوقّف عن قياس نسبة التغطية؟

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

كم تكلّف بوّابة اختبار الطفرة عملياً؟

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

هل الاختبارات المولّدة أسوأ من عدم وجود اختبارات؟

في حالة واحدة نعم: حين تُستخدم كمبرّر لعدم المراجعة. مجموعة اختبارات خضراء تمنع السؤال «هل جرّبنا هذه الحالة؟»، بينما غياب الاختبار يبقي السؤال مفتوحاً. لهذا المراجعة البشرية للتأكيدات — لا للاختبار كله — هي أرخص تأمين متاح.

الخلاصة

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

القاعدة العملية التي تختصر كل ما سبق: توقّف عن السؤال «كم اختباراً عندنا؟» وابدأ بالسؤال «كم عيباً تكتشفه اختباراتنا؟». الأول رقم يرفعه الوكيل نيابةً عنك، والثاني رقم لا يرتفع إلا بعمل حقيقي — ولهذا بالضبط هو الرقم الذي يستحقّ أن تراقبه.