فريق Dokumenterra يعهد إلى Claude بكتابة اختبارات آلية في خمس ساعات

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

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

من تعليمات إلى اختبارين

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

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

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

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

مراجعتان تبقيان من مسؤولية البشر

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

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

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

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

ما الذي يمكن تطبيقه في فريقك

تكمن القيمة العملية لهذه التجربة في تنظيم العملية. يتلقى الوكيل وصف الميزة، والمهمة، وطلب دمج التغييرات PR، وحالات الاختبار الموجودة، ثم يبحث بنفسه عن الوثائق ويقترح خطة اختبار. وبذلك يحصل مسؤول الاختبار على مادة ملموسة لمراجعتها.

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

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

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