فريق QA في ياندكس بميزانية 15 ألف روبل شهريًا يسلّم قوائم الفحص والاختبارات الآلية إلى وكيل ذكاء اصطناعي

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

من إضافة في IDE إلى حدث في Tracker

عاشت النسخة الأولى داخل Roo Code لمحرر VS Code. كان المهندس يفتح المحرر، ويختار وضعًا، ويكتب «أعدّ قائمة فحص للمهمة»، فيذهب الوكيل بنفسه إلى Tracker ويقرأ طلب الدمج ويقدّم النتيجة. نجح ذلك، لكن لم يستخدمه إلا من يجيدون الأتمتة أصلًا. أما الباقون فكان عليهم إعداد البيئة والتحقق من الصلاحيات، أي استبدال عمل يدوي بآخر.

لذلك نُقل الوكيل إلى نموذج الأحداث. عندما تنتقل المهمة إلى حالة «جاهزة للاختبار»، يرسل Tracker طلب HTTP POST إلى CI، فيشغّل حاوية فيها الوكيل، ويفتح المختبر التذكرة وقد وجد قائمة الفحص جاهزة. وهناك مشغّل ثانٍ: كلمة مفتاحية في تعليق، وهي مفيدة لإعادة التوليد بعد تحديث طلب الدمج. أما الاختبارات الآلية فالمخطط مشابه، لكن الوكيل يطلب أولًا تأكيد المهندس ثم ينشئ طلب الدمج. هذه حماية من الإغراق بالطلبات (السبام).

وكلاء فرعيون بدل موجّه واحد كبير

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

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

أما مع الاختبارات الآلية فلم تكفِ ثلاث خطوات. لدواعٍ أمنية مُنع الوكيل من الدخول إلى متصفح حي، ولذلك جاءت المحددات (locators) في المسودة الأولى غير دقيقة. الحل: تشغيل الاختبار في CI (وهذه لم تعد مهمة LLM)، وتزويد الوكيل بالتقرير ليصحح المحددات بنفسه، ثم التشغيل مرة أخرى. فبلغت الخطوات ست، اثنتان منها تشغيلان عاديان بلا نموذج.

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

المهارات وبنك الذاكرة

معرفة الوكيل موجودة في مكانين، كلاهما في المستودع. المهارة (skill) هي تعليمات خطوة بخطوة كما تُكتب لمبتدئ: ماذا يفعل، وأي قوالب يستخدم، وكيف يتحقق من النتيجة. فمثلًا يوضع الاختبار ذو المحاكاة (mocks) في integration، وبلا محاكاة في e2e، ولا تُختلق فحوص غير موجودة في الحالة. لدى الفريق مهارات منفصلة لجمع السياق، وتحليل طلب الدمج، وتصدير الحالات من TMS، وكتابة الاختبار، ومراجعة الكود، وإصلاح حالات الفشل. وكلما كانت المهارة أضيق كانت الخطوة أرخص وأكثر استقرارًا.

ويجيب بنك الذاكرة عن سؤال «كيف جرت العادة لدينا»: مجموعة ملفات Markdown فيها الحزمة التقنية (stack)، والتجهيزات (fixtures)، والأنماط المضادة، وحالات الفشل المتكررة. والقاعدة بسيطة: نسجّل فقط ما سيفيد في المهام اللاحقة، دون تفاصيل تذكرة بعينها ودون تكرار. والبنك أيضًا يستهلك رموزًا (tokens)، لذا فدليل قصير محدّث أفضل من مئتي صفحة من وثائق قديمة.

كم كلّف ذلك

خُصص لفريق من خمسة أشخاص 15 ألف روبل شهريًا. وكانت النفقات الشهرية: 11 600 و9 300 و14 600 و15 000 روبل. وبحلول الشهر الرابع استُنفد الحد بالكامل. ولهذا يحسب الفريق تكلفة كل خطوة على حدة: يسجّل رموز الإدخال والإخراج ويتتبع أين يذهب المال. ينقطع نص قسم الخلاصات في المصدر في نهايته، لذا تبقى تفاصيل حجم الطلبات خارج الصورة.

ما الذي يمكن أخذه

المخطط غير مرتبط بياندكس ولا بنموذج بعينه. لتكراره تحتاج إلى CI بمشغّل خارجي، وحساب روبوت، وبيئة تشغيل للوكلاء. ويمكن أن يؤدي Jira Automation أو Linear Webhooks دور Tracker، وأن يؤدي GitHub Actions أو GitLab CI دور الـ tasklet، وأن يتولى Claude Code أو OpenAI Agents SDK أو LangGraph التنسيق.

خمس قواعد من المقال: تثبيت مراجعة الكود، وحفظ التعليمات بجانب الكود، وتقسيم العمل إلى خطوات يربطها JSON، وحساب الرموز لكل خطوة، وتقييد صلاحيات الوكيل بصرامة.

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