TCS تبني وكلاء لاختبارات البنوك: 100 سيناريو في 24 ساعة بدلًا من 200

لطالما سرّعت أتمتة الاختبارات عملية التشغيل، لكنها بالكاد تمسّ بقية الحلقات. فالسيناريوهات ما زال البشر يبتكرونها، والسكربتات تُعاد كتابتها بعد كل تعديل على user story، والاختبار الفاشل يُحلَّل يدويًا. وهذا بالضبط الجزء من السلسلة الذي قررت TCS أتمتته لعملائها في البنوك والمالية والتأمين (BFSI). وقد تحدثت عن ذلك مع AWS.

موجّه واحد لا يكفي، والمطلوب خط إنتاج متكامل

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

استدعاء واحد لنموذج لغوي كبير لا يمنح هذا القدر من التحكم. لذلك وزّعت TCS العمل بين وكلاء، لكل منهم أدواته وقواعد التحقق والسياق الخاص به. ولا يتولى النموذج التوجيه، بل مشرف حتمي. كُتب الوكلاء باستخدام Strands Agents SDK ويعملون في Amazon Bedrock AgentCore Runtime.

وهذا هو توزيع الأدوار:

• الوكيل المولِّد يبني السيناريوهات ويحوّلها إلى Gherkin ويكتب اختبارات آلية بلغتي Java أو Python؛
• وكيل الدردشة يميّز بين السؤال وطلب تعديل أحد المخرجات، فيجيب أو يعدّل؛
• وكيل المهام يحوّل BRD إلى user stories مع معايير القبول؛
• الوكيل التزايدي يستكمل الاختبارات على امتداد سلسلة مهام Jira المترابطة بدلًا من البدء من الصفر؛
• وكيل التنفيذ يشغّل الاختبارات ويصنّف حالات الفشل ويحفظ النتيجة.

يُستمد السياق من Amazon Bedrock Knowledge Bases: Jira وBRD وSwagger والشيفرة والمحددات (locators) وبيانات الاختبار. وتُصفّى النتائج بحسب العميل والمشروع والجلسة، ولذلك لا تصل معارف عميل إلى اختبارات عميل آخر. أما لواجهة المستخدم، فتبني خدمة مستقلة قائمة على Puppeteer وصفًا للسيناريو ومحددات XPath انطلاقًا من عنوان URL وهدف نصي.

كيف يعمل التشغيل والإصلاح الذاتي

يحدد وكيل التنفيذ نوع الاختبار بنفسه من الشيفرة. تعمل اختبارات API على ECS مع Fargate. وتعمل اختبارات Selenium على ECS فوق EC2، حيث يعمل Chrome بشاشة افتراضية، ويُبثّ التسجيل عبر FFmpeg إلى S3 وCloudFront.

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

عزل العملاء والنتيجة

المنصة متعددة المستأجرين. تشمل طبقة الإدارة المشتركة EKS وسجلًّا وبوابة إدارية. ولكل عميل namespace خاص في Kubernetes، ومجموعة Cognito، ومفتاح KMS، وحاوية S3، وجداول DynamoDB، وقاعدة معارف. ويجري الإعداد الأولي عبر EventBridge وCodeBuild مع AWS CDK، ما يجعل نشر عميل جديد قابلًا للتكرار. وتُحفظ أسرار Jira وGitLab في Secrets Manager، وتعمل فوقها WAF وNetworkPolicy وResourceQuota، بينما يجمع OpenTelemetry تتبّع الوكلاء.

في حمل تمثيلي يبلغ نحو 100 سيناريو، كانت العملية اليدوية تستغرق نحو ساعتين للسيناريو الواحد، أي 200 ساعة. ومع المنسّق يصبح الزمن نحو 14 دقيقة للسيناريو، أي 24 ساعة. وهذا يعني انخفاضًا في الجهد بنسبة 88%.

القيود وما ينبغي الانتباه إليه

الرقم مستمد من الاختبار المرجعي الداخلي لـ TCS نفسها، وتعتمد المدد على تعقيد التطبيق والفريق. وهذا منشور مشترك مع AWS، التي تبيع الحل أيضًا عبر Marketplace. ولا يوجد تحقق مستقل، ولا بيانات عن نسبة الاختبارات التي يُعيد المهندسون كتابتها على أي حال.

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