كيف خفّضت Policybazaar أعباء التدقيق بنسبة %92 وسرّعت عرض الشاشات بنسبة تزيد عن %90 باستخدام "أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء" و"إرشادات الويب الحديث"

تاريخ النشر: 10 نوفمبر 2026

Policybazaar هي إحدى منصات التأمين الرائدة في الهند، وتضم أكثر من 97 مليون عميل مسجَّل. يزور حوالي %80 من عملائها الموقع الإلكتروني كل شهر. أطلقت شركتها الرئيسية PB Fintech مؤخرًا منصة Pensionbazaar، وهي منصة شاملة للتخطيط للتقاعد، وهي علامة تجارية تابعة لشركة Paisabazaar Marketing & Consulting Private Limited.

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

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

إليك التأثير:

‫92%

جهد أقل في التدقيق اليدوي في حوالي 30 صفحة مقصودة في Policybazaar

>%90

تطوير واختبار أسرع لصفحات Pensionbazaar الجديدة، من حوالي أربعة أيام إلى بضع ساعات

>%90

انخفاض عدد الأخطاء في واجهة المستخدم التي تم الإبلاغ عنها في شاشات Pensionbazaar الجديدة

التحدي: كتابة الرموز البرمجية بسرعة، والتحقّق منها ببطء

واجهت Policybazaar وPensionbazaar مشكلتَين مختلفتَين لم تتمكّن سير العمل العادية لترميز الذكاء الاصطناعي من تحسينهما على مستوى الإنتاج.

‫Pensionbazaar: شاشات جديدة مع دورات طويلة لتأكيد الجودة

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

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

ثانيًا، كان الرمز البرمجي الذي تم إنشاؤه قديمًا. وبسبب عدم معرفة الوكلاء بمنصة الويب الحديثة، لجأوا إلى حلول بديلة قديمة، فكتبوا نوافذ JavaScript مشروطة ثقيلة بدلاً من استخدام عنصر <dialog> المضمّن، وأضافوا polyfills غير ضرورية، وتجاهلوا تلميحات الأداء مثل fetchpriority.

‫Policybazaar: ‏30 صفحة مقصودة وتدقيق يدوي

يدير فريق التأمين على الحياة في Policybazaar حوالي 30 صفحة مقصودة لمنتجات تأمين مختلفة، ويمكن أن تتضمّن كل صفحة صيغًا مختلفة لحملات تسويقية مختلفة. معًا، يتلقون من 200000 إلى 300000 زائر يوميًا، وكل صفحة تحصل على تحديثات شهرية للتصميم ومنطق الأعمال. على الفريق الحفاظ على ارتفاع نتائج Core Web Vitals والتأكّد من أنّ كل صيغة تظل متاحة ويتم عرضها بشكل صحيح على كل حجم شاشة.

قبل استخدام الأساليب الآلية، كان المهندس يراجع كل صفحة يدويًا:

  1. شغِّل أداة إحصاءات PageSpeed لجمع بيانات المستخدمين الفعلية.
  2. قيِّم نتائج Core Web Vitals والاقتراحات.
  3. افحص إصدار التطوير أو الإصدار التجريبي، وشخِّص المشاكل التي تسبّبت في انخفاض النتائج، وطبِّق إصلاحات الرموز البرمجية.

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

قبل تغيير سير العمل، حدّدت الفِرق ثلاثة أهداف: تقليل الوقت الذي يقضيه المطوّرون في عمليات تدقيق الأداء بنسبة تزيد عن %80 مع جعل تغطية التدقيق مستمرة، وتقليل الوقت المستغرَق في تأكيد الجودة من خلال التقارير التي تم التحقّق منها، وتقليل أخطاء واجهة المستخدم التي تظهر بسبب عدم تطابق الشاشة مع الإطارات الشبكية.

الحلّ: حلقة "الترميز والتحقّق"

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

مخطط انسيابي يتضمّن خمس مراحل من الأعلى إلى الأسفل أولاً، إطار شبكي في Figma،
            تمت قراءته باستخدام خادم Figma MCP. ثانيًا، إنشاء الرموز البرمجية،
            حيث يتم توجيه وكيل الترميز من خلال إرشادات الويب الحديث. ثالثًا،
            عمليات التدقيق المبرمَجة في متصفّح معزول يتم تشغيله باستخدام &quot;أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء&quot;: تدقيق في إطار العرض والتصميم البصري، وتدقيق في أخطاء وحدة التحكّم والاستثناءات، وتدقيق مبرمَج في الأداء.
            رابعًا، التحقّق، حيث تطبّق حلقة الملاحظات والتصحيح الذاتي المستقلة التغييرات استنادًا إلى نتائج التدقيق، وتقارن النتيجة بإطار Figma الشبكي الأصلي، وتعود إلى عمليات التدقيق عند الحاجة. خامسًا، الرمز البرمجي النهائي الذي تم التحقّق منه، بما في ذلك تقرير آلي لضمان الجودة مع لقطات شاشة
حلقة التحقّق من الرمز في Pensionbazaar يُكرّر الوكيل عمليات التدقيق والتصحيحات إلى أن تتطابق الصفحة مع التصميم، ثم يتحقّق تلقائيًا من الرمز البرمجي باستخدام تقرير تأكيد الجودة.

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

وكيل الترميز في Pensionbazaar ينفّذ شاشة من تصاميم Figma، ثم يستخدم "أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء" للتحقّق منها وإصلاحها.

الخطوة 1: تزويد الوكيل بمعلومات حول معايير الويب الحديثة

أراد فريق Pensionbazaar أن يتّبع الرمز الذي تم إنشاؤه أفضل الممارسات الحديثة على الويب، وأن يستخدم ميزات المنصة الحالية، وأن يعمل أيضًا في المتصفّحات القديمة. من الصعب التحقّق من ذلك يدويًا، ولا يطّلع الوكلاء دائمًا على آخر الأخبار على المنصة. إرشادات الويب الحديث تحلّ هذه المشكلة. وهي مهارة وكيل، كتبها ويحافظ عليها خبراء الويب من Chrome و منتدى الويب، وتغطي أكثر من 200 حالة استخدام. ويوجّه الوكلاء نحو واجهات برمجة التطبيقات الحديثة لمنصات الويب ونحو أفضل الممارسات المتعلّقة بالأداء وأدوات تسهيل الاستخدام التي تتناسب مع هدفك الأساسي. إذا لم تحدّد هدفًا، يتم ضبطه تلقائيًا على Baseline Widely Available.

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

  • حلّت العناصر الأصلية محلّ الحلول البديلة في JavaScript. استخدم الوكيل عنصر <dialog> المضمّن وPopover API للنوافذ المشروطة لتفاصيل الخطة، وCSS Grid وFlexbox لبطاقات الملخّص المالي.
  • أضاف الوكيل تلميحات حول الأداء لا تتضمّنها عادةً النماذج الأساسية. وشمل ذلك fetchpriority="high" على صور LCP الرئيسية، وloading="lazy" على بطاقات الخطة في الجزء السفلي غير المرئي من الصفحة، وميزانية تنفيذ مستندة إلى الوقت مع scheduler.yield() لحماية مدى استجابة الصفحة لتفاعلات المستخدم (INP).
  • لم تؤدِّ الميزات الحديثة إلى تعطُّل المتصفّحات القديمة. يتيح Pensionbazaar استخدام إصدارات المتصفّحات القديمة، والتي يحدّدها في Browserslist. استخدم الوكيل ميزات مثل فئة :user-invalid CSS الزائفة وautoComplete="one-time-code" في حقل كلمة المرور الصالحة لمرة واحدة (OTP). تتجاهلها المتصفحات القديمة، وتستمر الوظائف الأساسية في العمل.

لم تكن النماذج الأساسية بعيدة عن ذلك، فقد وجد الفريق أنّها تتوافق بنسبة %70 تقريبًا مع أفضل الممارسات من حيث الأداء. أدرج تقرير الوكيل نفسه 12 قاعدة من قواعد إرشادات الويب الحديث التي سدّت الفجوة المتبقية. أربعة أمثلة:

منطقة الفجوة في النموذج الأساسي قاعدة "إرشادات الويب الحديث"
تحميل الصور مجموعات متضاربة غير صحيحة، مثل الجمع بين fetchpriority="high" وloading="lazy" ويحظر صراحةً الجمع بينهما، ويحدّد عدد الصور ذات الأولوية العالية بصورة واحدة أو صورتين لكل صفحة.
ثبات التنسيق تم اقتراح content-visibility: auto لتحسين الأداء، ولكن تم حذف contain-intrinsic-size. يتطلّب ذلك إقران السمتَين لمنع حدوث تغييرات كبيرة في التنسيق عند عرض المحتوى.
التنازل عن سلسلة التعليمات الرئيسية تم استخدام scheduler.yield() بشكل عام بدون نمط الموعد النهائي. يفرض هذا الإعداد موعدًا نهائيًا صارمًا يستند إلى الوقت (performance.now() + 50) لحماية مقياس "مدى استجابة الصفحة لتفاعلات المستخدم" (INP).
التخزين المؤقت في Service Worker لم يتم احتساب عمليات إرسال النماذج بلا إنترنت. تحذير الوكيل من أنّ مشغّلي الخدمات لا يمكنهم تخزين طلبات استرداد البيانات باستخدام GET في ذاكرة التخزين المؤقت بشكلٍ أصلي.

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

أمان سوني، مدير الهندسة في Policybazaar

الخطوة 2: منح الوكيل متصفّحًا

أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء هي مجموعة من الأدوات، بما في ذلك خادم MCP وواجهة سطر الأوامر (CLI) ومهارات الوكلاء، تتيح لوكلاء الترميز الوصول في الوقت الفعلي إلى بيانات تصحيح الأخطاء في وقت التشغيل، مثل سجلّات وحدة التحكّم وحركة بيانات الشبكة وشجرة تسهيل الاستخدام وإمكانات أدوات مطوّري البرامج الأخرى.

ثبّت الفريق "أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء" كمكوّن إضافي في وكيل الترميز Claude Code:

# Add the marketplace registry
/plugin marketplace add ChromeDevTools/chrome-devtools-mcp

# Install the plugin (MCP server and skills)
/plugin install chrome-devtools-mcp@chrome-devtools-plugins

أراد الفريق تشغيل كل اختبار في مثيل متصفح نظيف، لذلك لا يمكن أن تؤثر إضافات Chrome المثبتة على النتائج ولا يمكن تسريب البيانات الشخصية أو الحساسة. للحصول على ذلك، أضِف --isolated إلى مصفوفة args في إعدادات خادم MCP:

{
  "args": ["-y", "chrome-devtools-mcp@latest", "--isolated"]
}

إذا كانت اختباراتك تحتاج إلى جلسة متصفّح حالية تم تسجيل الدخول إليها، استخدِم --autoConnect.

الخطوة 3: السماح للوكيل بالتحقّق من عمله وإصلاحه

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

  • يفحص شجرة نموذج العناصر في المستند (DOM) وCSS المحسوبة ويقارنها بتصميم Figma.
  • تغيير حجم الصفحة لتناسب إطارات العرض على الأجهزة الجوّالة من أجل اختبار مدى استجابتها
  • تسجّل هذه الميزة عمليات تتبُّع الأداء للعثور على الصور المتحركة التي يستغرق عرضها وقتًا طويلاً (LoAF) بسبب النصوص البرمجية والموارد التي تحظر العرض ومشاكل الأداء الأخرى.
  • يعيد كتابة الرمز البرمجي لإصلاح حالات عدم التطابق في التصميم ومشاكل الأداء واستثناءات وحدة التحكّم قبل أن يراجعه مهندس.

يوضّح الجدول التالي أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء التي تتوافق مع كل فحص:

شيك الأدوات
اختبار الاستجابة عبر إطارات العرض يغيّر resize_page حجم نافذة الصفحة إلى أبعاد صريحة. تحاكي أداة emulate بيئات أجهزة معيّنة. يلتقط "take_screenshot" النتيجة.
مقارنة نموذج DOM وCSS المحسوب بتصميم Figma تعرض الدالة take_snapshot لقطة نصية للصفحة استنادًا إلى شجرة تسهيل الاستخدام. يقرأ "get_css_styles" قواعد CSS المطبَّقة. تنفّذ دالة evaluate_script دالة JavaScript داخل الصفحة.
العثور على مشاكل LoAF والموارد التي تحظر العرض ومشاكل Core Web Vitals يُحاكي click وdrag التفاعلات. performance_start_trace وperformance_stop_trace يسجّلان بيانات تتبُّع الأداء. تعرض السمة performance_analyze_insight بيانات تشخيص تفصيلية للإحصاءات في عملية التتبُّع. يعرض list_network_requests وget_network_request نشاط الشبكة. تُجري أداة lighthouse_audit تدقيقًا في الجوانب غير المتعلّقة بالأداء، مثل تحسين محركات البحث وأدوات تسهيل الاستخدام.

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

  1. تلتقط "أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء" الخطأ بدقة.
  2. يحلّل الوكيل البيانات ويعيد كتابة CSS أو JavaScript التي تتضمّن مشاكل.
  3. يعيد موظف الدعم تحميل الصفحة للتأكّد من حلّ المشكلة.

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

الخطوة 4: تسليم تقرير تم التحقق منه إلى فريق تأكيد الجودة

عند اكتمال عملية التحقّق، يقدّم الوكيل رمزًا برمجيًا جاهزًا للإنتاج مع تقرير تدقيق لفريق تأكيد الجودة. ويتضمّن التقرير ما يلي:

  • مقارنة مرئية مع تصميم Figma الذي يبرز الاختلافات في وحدات البكسل، والتي تم إنشاؤها من لقطات الشاشة ولقطات DOM والأنماط المحسوبة.
  • لقطات شاشة للصفحة المعروضة بأحجام شاشات مختلفة
  • مؤشرات Core Web Vitals وبيانات تشخيص الأداء من performance_start_trace وperformance_analyze_insight، مثل Speed Index وإجمالي وقت الحظر (TBT)
  • نتائج Lighthouse لتحسين محركات البحث وأفضل الممارسات وأدوات تسهيل الاستخدام من lighthouse_audit.
  • تحديد ما إذا كانت التفاعلات ناجحة أو فاشلة، مثل تصغير الصفوف ومفاتيح التبديل، بالإضافة إلى أخطاء وحدة التحكّم والتغييرات في حالة التطبيق، مثل تعديل الصفوف وحذفها والحالات الفارغة
تقرير تأكيد الجودة لصفحة التفاصيل المالية للعميل يعرض تصميم Figma والتنفيذ واختلاف البكسل جنبًا إلى جنب، مع تطابق %98.7 و%97.1 من وحدات البكسل
مقارنة مرئية من إنشاء الوكيل بين الصفحة المعروضة (تم التقاطها باستخدام أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء) ومواصفات التصميم التجريبي في Figma، مع تمييز الاختلافات حسب البكسل
جدول تقرير Lighthouse لإصدار الإنتاج أما بالنسبة إلى الأجهزة الجوّالة وأجهزة الكمبيوتر المكتبي، فقد حصل الموقع الإلكتروني على 90 و93 نقطة للأداء، و91 نقطة لأدوات تسهيل الاستخدام، و100 نقطة لأفضل الممارسات، و92 نقطة لتحسين محركات البحث. وتشمل المقاييس سرعة عرض أكبر محتوى مرئي تبلغ 2.1 ثانية على الأجهزة الجوّالة و0.5 ثانية على أجهزة الكمبيوتر المكتبي، و0 ملي ثانية لإجمالي وقت الحظر، ومتغيّرات التصميم التراكمية تبلغ 0.006 على الأجهزة الجوّالة و0.001 على أجهزة الكمبيوتر المكتبي.
نتائج Lighthouse وCore Web Vitals على الأجهزة الجوّالة وأجهزة الكمبيوتر المكتبي

اتّباع النهج نفسه في 30 صفحة حملة

على منصتها الرئيسية، استبدلت Policybazaar عمليات التشغيل اليدوية لأداة PageSpeed Insights بعمليات تدقيق يتم إجراؤها من خلال "أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء" في Kiro. قبل نشر صفحة الحملة، يشغّل المهندس عملية تدقيق لعنوان URL الخاص بالموقع الإلكتروني المرحلي على الأجهزة الجوّالة وأجهزة الكمبيوتر المكتبي. يُجري الوكيل عمليات تدقيق في الأداء وLighthouse، وتسحب &quot;أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء&quot; تلقائيًا بيانات الحقول الواقعية من &quot;تقرير تجربة المستخدم على Chrome&quot; (CrUX) إلى جانب بيانات المختبر. وقد حلّ ذلك محلّ خطوة "إحصاءات PageSpeed" بالكامل

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

يُكمل الوكيل الآن 12 عملية تدقيق في الأداء في الوقت الذي يحتاجه المهندس لإكمال عملية واحدة. ويعني ذلك انخفاضًا بنسبة %92 في الجهد اليدوي.

يستخدم Kiro &quot;أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء&quot; لإجراء عمليات تدقيق Lighthouse وتتبُّع الأداء على صفحة Policybazaar المقصودة، ثم يسرد مشاكل الأداء التي يعثر عليها.

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

أمان سوني، مدير الهندسة في Policybazaar

التأثير

بفضل ميزتَي &quot;إرشادات الويب الحديث&quot; و&quot;أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء&quot;، تحوّلت عملية اختبار الواجهة الأمامية في Policybazaar وPensionbazaar من عملية يدوية وتفاعلية إلى عملية مبرمَجة واستباقية. يقارن الجدول التالي بين سير العمل قبل التغيير وبعده:

منطقة في السابق: المراجعة اليدوية والنماذج الأساسية بعد: "إرشادات الويب الحديث" و"أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء"
جهود التدقيق في الأداء (Policybazaar) شغّل أحد المهندسين أداة إحصاءات PageSpeed وراجع مؤشرات Core Web Vitals وطبّق الإصلاحات يدويًا على كل صفحة من الصفحات المقصودة التي يبلغ عددها 30 صفحة تقريبًا. جهد يدوي أقل بنسبة %92 يُكمل الوكيل 12 عملية تدقيق في الوقت الذي يحتاجه المهندس لإجراء عملية واحدة.
تغطية التدقيق (Policybazaar) كانت تغطية التدقيق على مستوى صيغ الحملات غير متسقة. تغطية اختبار الأداء بنسبة %100 لصفحات الحملات
New screen turnaround (Pensionbazaar) يستغرق الأمر بضعة أيام من كتابة الرمز إلى ظهور الشاشة التي تم التحقّق منها. بضع ساعات، أي أسرع بنسبة تزيد عن %90
أخطاء في تكافؤ التصميم (Pensionbazaar) وصول واجهة المستخدم المقتطعة وتغييرات التنسيق إلى مرحلة تأكيد الجودة اليدوي تم الإبلاغ عن أخطاء أقل في واجهة المستخدم بنسبة تزيد عن %90.

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

الخلاصات الرئيسية لفريقك

  • يجب أن يستند الوكيل إلى إرشادات موثوقة. تساعد الإرشادات المنظَّمة، مثل &quot;إرشادات الويب الحديث&quot;، الوكلاء على تجنُّب الأنماط القديمة والحفاظ على توافق الرموز البرمجية مع أهداف Baseline.
  • لا تسمح للوكيل بوضع علامة "مكتملة" على مهمة في الواجهة الأمامية قبل أن يتحقّق من الصفحة المعروضة. تتيح "أدوات مطوّري البرامج في Chrome المخصّصة للوكلاء" للوكيل فحص التنسيق ومساحات العرض وتتبُّع الأداء في متصفّح حقيقي.
  • حدِّد معايير واضحة للخروج من الحلقة. يجب وضع حدود لعدد الخطوات وشروط واضحة للنجاح والفشل كي لا يدخل الوكيل في حلقة مفرغة ويستهلك الرموز المميزة بلا فائدة.
  • ابدأ بالصفحات التي يتم تكرارها كثيرًا وتعتمد على النماذج. تكون مهام سير العمل المغلقة أكثر فائدة عندما تكون سرعة الإنجاز مهمة.
  • إجراء عمليات التدقيق في متصفّح نظيف: استخدِم --isolated لكي لا تؤثر الإضافات والبيانات المخزّنة مؤقتًا في النتائج أو تكشف عن البيانات الشخصية.

الموارد