مهندس QA في Cloud.ru يختصر مهمة الاختبارات الآلية من نصف يوم عمل إلى ساعة–ساعة ونصف بفضل OpenSpec

كتب الوكيل الاختبارات، والكود مرتب، وpytest يعرض اللون الأخضر. هل يمكن إغلاق المهمة؟ ليس بالضرورة. روى مهندس QA في Cloud.ru كيف بنى، بعد عدة حالات من هذا النوع، عملية مؤلفة من أربعة وكلاء ومواصفات. وهو اليوم يقضي وقتًا في المتطلبات والمخاطر أطول مما يقضيه في الكود نفسه.

اختبار أخضر لا يثبت شيئًا

يحتوي المشروع على وظيفة لنشر بنية التوثيق في Git. إذا اختفى قسم من البنية عند النشر مرة أخرى، فيجب حذف الملف المقابل من المستودع. كتب الوكيل اختبارًا باسم test_update_structure_removes_orphan_doc_file. ينشر الاختبار بنية تضم القسمين overview وsetup، ثم ينشرها مجددًا دون setup، ويستنسخ المستودع ويتحقق من أن ملف setup غير موجود.

يبدو ذلك معقولًا: فهو يفحص الحالة الفعلية في Git وليس استجابة API فقط. لكن الوكيل لم يتأكد ولو مرة واحدة، قبل الحذف، من أن الملف كان موجودًا. فقد أكد وجود المستند عبر get_repowiki_docs()، وهذه الدالة قد تعيد بيانات وصفية دون النظر إلى المستودع نفسه. وإذا لم يظهر الملف عند النشر الأول، فسيمر الاختبار على أي حال: فبعد النشر الثاني لن يكون الملف موجودًا أيضًا. الاختبار يتحقق من الحالة النهائية، لا من الانتقال نفسه «كان الملف موجودًا — ثم لم يعد موجودًا».

لم تلتقط المراجعة الذاتية للوكيل المطوِّر ذلك: فقد حلل منطق الاختبار لكنه لم يجرِ تجارب. اكتشف المشكلة وكيل آخر هو المراجِع. بعد ذلك أُضيفت إلى الاختبار خطوة مع repowiki_repo_clone() as clone_before تتحقق من وجود الملف قبل النشر الثاني. ويظهر الصنف نفسه من الأخطاء في حالات بسيطة أيضًا: يتحقق الوكيل من HTTP 400 لكنه لا ينظر إلى بنية جسم رسالة الخطأ.

كيف تعمل العملية

يفتح المؤلف Claude Code ويمنح الوكيل الرئيسي، المنسِّق (orchestrator)، رقم المهمة من Jira. القواعد موصوفة في ملف CLAUDE.md داخل المستودع: أي الوكلاء موجودون، وما مسؤولية كل منهم، وكيف يُنتقل بين المراحل، ومتى يلزم تأكيد الإنسان. حاليًا هناك أربعة وكلاء:

• test-planner يدرس المهمة والاختبارات القائمة وينشئ OpenSpec change. ويضم proposal.md (لماذا)، وdesign.md (النهج والقيود)، وtasks.md (الخطوات المحددة). ثم تمر الخطة عبر openspec validate --strict.
• test-qa-writer ينفذ الاختبارات وفق tasks.md ويعلّم البنود المنجزة.
• test-reviewer يطابق التنفيذ مع المواصفة والاتفاقات المعمارية. ولا يشغّل الاختبارات بنفسه، بل يعمل مع الكود والمخرجات فقط.
• docs-writer يحدّث التوثيق.

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

يبقى في change الملفان qa-report.md وreview.md. ولذلك يحتفظ سجل المهمة بتاريخها: ما خُطط، وما أُنجز، وما الملاحظات التي ظهرت.

فحص «ليس هراءً»

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

وهناك تحفظ صريح أيضًا. فقد يعمل المطوِّر والمراجِع على النموذج نفسه. تقسيم الأدوار لا يجعل الفحص مستقلًا تمامًا، لكنه يغيّر الموقع ومعايير التقييم. وهذا النمط تحديدًا هو ما التقط حالة ملف setup.

ما الذي يمكن الاستفادة منه

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

خلاصات عملية للفرق التي تفوّض الاختبارات إلى الوكلاء:

• أدرجوا في معايير القبول فحص الحالة الأولية، لا النهائية فقط. فأي اختبار من نوع «بعد الإجراء X تغيّر شيء ما» يحتاج إلى خطوة تؤكد أن هذا الشيء لم يكن موجودًا قبل X.
• لا تعتبروا المراجعة الذاتية للمنفِّذ مراجعةً حقيقية. فمرور منفصل بدور مختلف وprompt مختلف يلتقط ما لا يراه كاتب الكود.
• احفظوا المواصفات وخلاصات المراجعة في المستودع بجوار الكود.
• أبقوا الإنسان عند مفترقين: اعتماد الخطة وقبول النتيجة.

ويتناول المقال الأصلي لاحقًا حالة CRUD لوسوم Git: كانت هناك ثلاثة اختبارات لـGET /tags تتحقق من الحقل name فقط، ولم يكن هناك تغطية لـPOST وDELETE. لكن الخلاصة الرئيسية تظهر من وصف العملية نفسه. فالوكلاء يتولون التنفيذ، أما المتطلبات والجودة النهائية فما زال الإنسان مسؤولًا عنها.