جودة البرمجيات & الاختبار

5.1 نظرة عامة & الغرض

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

لا يجوز ترقية أي إصدار أو تحديث أو ترقية كبرى (حسب التعريف الوارد في الفصل 1، §1.4) إلى الإنتاج ما لم تُستكمل بنجاح دورة الاختبار الموضحة هنا.

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

إضافةً إلى منع العيوب، يضم إطار SQT خدمة استشارية استباقية لتحسين العمليات، يتم فيها تحليل مخرجات وكلاء الذكاء الاصطناعي لتحديد أوجه القصور في سير العمل، والشذوذات في التهيئة، وفرص تحسين نموذج البيانات داخل نشر كل عميل. وتُقدَّم هذه الرؤى كتوصيات قابلة للتنفيذ خلال مراجعات الخدمة الربع سنوية (§3.9).

5.2 النطاق

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

• (a) الإصدارات/التحديثات (v11.xx) — تغييرات تدريجية خاصة بالعميل يتم تسليمها عبر سبرنتات Agile مدتها 3 أيام (§4.7).
• (b) الترقيات (v11 → v12) — تغييرات رئيسية على مستوى المنتج تُسلَّم تقريباً سنوياً (§4.8).
• (c) تغييرات التهيئة — تفعيل الوحدات، وتخصيص سير العمل، وقوالب التقارير، وتعديلات الأدوار والصلاحيات.
• (d) مخرجات ترحيل البيانات — تحويلات الاستيراد، ونصوص ETL، ورقع ترحيل المخطط.
• (e) واجهات التكامل — نقاط نهاية API، ومعالجات webhooks، ومهايئات موصلات الأطراف الثالثة.
• (f) تغييرات البنية التحتية — تحديثات محرك قاعدة البيانات، وترقيات إصدارات البرمجيات الوسيطة، وتدوير شهادات TLS.

يغطي إطار SQT كلّاً من الاختبار الداخلي للمزود (5.4–5.7) الذي يُجرى قبل اختبار قبول العميل، واختبار قبول المستخدم الشامل الخاص بالعميل (5.8) الذي يُعد بوابة الجاهزية الرسمية للإنتاج.

5.3 إطار الاختبار المعزَّز بالذكاء الاصطناعي

5.3.1 نظرة عامة على المعمارية

يستخدم المزود منصة اختبار بالذكاء الاصطناعي مصممة لغرض محدد وتتألف من ثلاث طبقات أساسية:

5.3.2 وكلاء اختبار الذكاء الاصطناعي

تُقرن كل نسخة من ProjectVIEW ERP الخاصة بالعميل بوكيل أو أكثر من وكلاء اختبار الذكاء الاصطناعي المخصصين، والمُهيَّئين بمعرفة خاصة بمجال العميل حول:

• تهيئة الوحدات: الوحدات المفعلة (مثل Project-Management وContract-Management وQuality-Management) واعتمادياتها البينية.
• القواعد التجارية: سير العمل الخاصة بالاعتماد، ومصفوفات التصعيد، وقواعد الإشعارات، وصيغ الحساب الخاصة بالمتطلبات التشغيلية للعميل.
• مخطط البيانات: الحقول المخصصة، وجداول البحث، ونطاقات القيم المرمّزة، وقيود السلامة العلائقية المهيأة في نسخة العميل.
• تصنيف الأدوار: أدوار المستخدمين، ومجموعات الصلاحيات، وقواعد فصل المهام المنطبقة على منظمة العميل.
• خريطة التكامل: الأنظمة المتصلة التابعة لأطراف ثالثة (المحاسبة، والموارد البشرية، وإدارة المستندات، وذكاء الأعمال) واتفاقيات تبادل البيانات الخاصة بها.

تُدار إصدارات الوكلاء جنباً إلى جنب مع قاعدة شيفرة التطبيق باستخدام استراتيجية التفريع Git الخاصة بالمزود (Master → Client → Working branches، §4.7.2)، بما يضمن تطور تكوينات الاختبار بالتوازي مع البرمجيات التي تتحقق منها.

5.3.3 التكامل الآمن مع API

توفر طبقة التكامل الآمن مع API طبقة اتصال منظمة بين وكلاء اختبار الذكاء الاصطناعي وProjectVIEW ERP، بما يتيح:

• (a) استدعاء API: يستدعي الوكلاء واجهات ProjectVIEW REST/GraphQL لإنشاء السجلات وقراءتها وتحديثها وحذفها، محاكين المعاملات الحقيقية للمستخدمين دون الاعتماد على واجهة المستخدم.
• (b) فحص قاعدة البيانات: وصول للقراءة فقط إلى قاعدة بيانات Dev/Sandbox الخاصة بالعميل للتحقق من قيود سلامة البيانات، والاتساق المرجعي، والحقول المحسوبة بعد المعاملة.
• (c) موصلات أتمتة واجهة المستخدم: حيث يكون منطق العمل مترابطاً بإحكام مع الواجهة الأمامية (مثل الرؤية الشرطية للحقول، والتحقق الديناميكي من صحة النماذج)، تقوم طبقة التكامل بتوجيه تعليمات الوكيل عبر واجهة متصفح بلا رأس تعرض واجهة ProjectVIEW بدقة.
• (d) التقاط الأحداث: تُسجَّل جميع تفاعلات الوكيل مع نظام ERP في مسار تدقيق غير قابل للتعديل، بما في ذلك حمولات الطلبات، وأكواد الاستجابة، ومقاييس التوقيت، ونتائج التحقق.

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

5.4 منهجية الاختبار

5.4.1 مستويات الاختبار

تشمل دورة الاختبار لدى المورّد خمسة مستويات متدرجة، لكل منها معايير دخول وخروج ومسؤوليات محددة:

5.4.2 بيئات الاختبار

تُنفَّذ جميع الاختبارات على جانب المورّد (L1–L4) حصرياً في بيئة Dev/Sandbox المخصّصة للعميل (§2.5.1). وتتميّز هذه البيئة بما يلي:

• مطابقة معماريّاً لبيئة الإنتاج — نفس إصدار محرك قاعدة البيانات، ومجموعة البرامج الوسيطة، وإصدار التطبيق.
• مزوَّدة ببيانات مجهَّلة مكافئة للإنتاج — بحجم وتنوّع كافيين لاختبار الحالات الحدية الواقعية دون كشف بيانات شخصية.
• معزولة — لا توجد لها اتصالات شبكية مع الإنتاج؛ ونطاق DNS مستقل ومجال مصادقة منفصل.
• قابلة لإعادة التهيئة — تتيح قدرة الالتقاط/الاستعادة تنفيذ اختبارات متكررة انطلاقاً من خط أساس معروف الجيد.

بعد الإطلاق، تنتقل بيئة Dev/Sandbox إلى دور Staging (§2.5.1)، مع الاحتفاظ بجميع الخصائص أعلاه، وفي الوقت نفسه تُستخدم كبيئة UAT للعميل.

5.5 محاكاة تدفّق البيانات من البداية إلى النهاية

5.5.1 أهداف المحاكاة

تحاكي وكلاء الذكاء الاصطناعي تدفقات بيانات واقعية شاملة تعبر دورة الحياة الكاملة لمعاملة أعمال داخل ProjectVIEW ERP. والأهداف هي:

• (a) التحقق من أن البيانات التي تُنشأ في وحدة ما تُنقل وتتحوّل وتصبح متاحة بشكل صحيح في جميع الوحدات اللاحقة.
• (b) تأكيد أن قواعد العمل (سلاسل الاعتماد، الإشعارات، الحسابات) تُنفَّذ بشكل صحيح في كل مرحلة.
• (c) التحقق من أن إجراءات المستخدمين المتزامنة لا تسبب حالات سباق أو تعليقات متبادلة أو تلفاً في البيانات.
• (d) قياس زمن استجابة المعاملة ومعدل الإنتاجية مقابل عتبات SLO المحددة (§3.3).

5.5.2 سيناريوهات المحاكاة

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

5.5.3 إعداد البيانات وتنفيذ السيناريو

قبل كل عملية محاكاة، يقوم وكلاء الذكاء الاصطناعي تلقائياً بما يلي:

• (a) تهيئة البيانات المتطلبة مسبقاً: إنشاء السجلات الرئيسية (المشاريع، الموردون، المستخدمون، رموز التكاليف) اللازمة كمدخلات للسيناريو الجاري اختباره.
• (b) تنفيذ سلسلة المعاملة: استدعاء واجهات ProjectVIEW عبر طبقة تكامل API الآمنة لتنفيذ كل خطوة من عملية الأعمال بالترتيب الصحيح، مع قيم بيانات وفواصل زمنية واقعية.
• (c) إجراء التحقق عند كل نقطة فحص: بعد كل خطوة، يستعلم الوكيل قاعدة البيانات و/أو واجهة API للتأكد من حدوث التغيير المتوقع في الحالة (إنشاء/تحديث سجل، تقدم سير العمل، إرسال إشعار).
• (d) تسجيل الأدلة: يُسجَّل كل استدعاء API، وكل استعلام قاعدة بيانات، وكل نتيجة تحقق، وكل قياس زمني في مستودع أدلة اختبار غير قابل للتعديل مرتبط بتذكرة النشر.
• (e) التنظيف: عند الاكتمال، يعيد الوكيل البيئة إلى خط الأساس باستخدام قدرة الالتقاط/الاستعادة، بما يضمن عدم تلوث أي نواتج اختبار للتشغيلات اللاحقة.

5.6 محاكاة تفاعل المستخدم

5.6.1 الغرض

بينما يثبت الاختبار على مستوى API (§5.5) منطق الواجهة الخلفية، تتحقق محاكاة تفاعل المستخدم من أن واجهة ProjectVIEW تعمل بشكل صحيح عند تشغيلها بواسطة مستخدمين بشريين. ويقلّد وكلاء الذكاء الاصطناعي تفاعلات المستخدم الواقعية بما في ذلك:

• إكمال النماذج ببيانات صحيحة وغير صحيحة وذات قيم حدية.
  • التنقل عبر تدفقات عمل متعددة الخطوات (المعالجـات، سلاسل الاعتماد، تسلسلات تحميل المستندات).
  • فرض الوصول القائم على الدور — ينتحل الوكلاء صفة مستخدمين عبر مجموعات أدوار/أذونات مختلفة للتأكد من إظهار/إخفاء عناصر الواجهة وتمكينها/تعطيلها بشكل صحيح.
  • السلوك المتجاوب — الاختبار عبر أحجام العرض المكتبية وحجم عرض الأجهزة اللوحية للتأكد من سلامة التخطيط.
  • الامتثال لإمكانية الوصول — التحقق من أن التنقل عبر لوحة المفاتيح، وسمات ARIA، ونسب التباين تستوفي متطلبات WCAG 2.1 AA.

5.6.2 سيناريوهات التفاعل

تُنظَّم محاكاة تفاعل المستخدم حول نصوص اختبار قائمة على الشخصيات الوظيفية:

5.6.3 تصنيف العيوب

تُصنَّف العيوب التي يتم تحديدها أثناء محاكاة تفاعل المستخدم باستخدام نفس تصنيف الشدة المعتمد للحوادث التشغيلية (§4.3):

5.7 التحقق من سلامة البيانات

5.7.1 النطاق

تُتحقق سلامة البيانات على ثلاثة مستويات بعد كل تشغيل اختبار وقبل أي ترقية للنشر:

5.7.2 التحققات من السلامة

ينفّذ الوكيل بالذكاء الاصطناعي التحققات التالية من السلامة عند نهاية كل سيناريو محاكاة:

(a) صفر سجلات يتيمة: تؤكد استعلامات SELECT عبر جميع جداول الربط والجداول الفرعية عدم وجود سجلات تشير إلى سجلات أصل غير موجودة. (b) التحقق من التوازن: بالنسبة للوحدات المالية — إجمالي المدين يساوي إجمالي الدائن داخل كل مركز تكلفة؛ والميزانية الملتزم بها + الفعلية + المتبقية تساوي إجمالي الميزانية. (c) سلامة التسلسل: التسلسلات المرقمة تلقائياً (أرقام المستندات، معرفات المعاملات) لا تحتوي على فجوات ولا تكرارات. (d) سلامة التزامن: تنتج سلاسل الوكلاء المتوازية التي تنفذ تحديثات متعارضة نتائج حتمية وصحيحة مع استجابات مناسبة للقفل التفاؤلي. (e) التشفير أثناء التخزين: تُخزَّن الحقول الحساسة (PII، البيانات المالية) مشفّرة في قاعدة البيانات؛ ولا يتاح النص الصريح إلا عبر طبقة فك التشفير في التطبيق.

5.7.3 تقرير سلامة البيانات

ينتج عن كل دورة اختبار تقرير سلامة بيانات آلي يتضمن:

• إجمالي التحققات المنفذة وعدد حالات النجاح/الفشل.
  • سجلات تفصيلية للإخفاقات مع اسم الجدول، والعمود، ومعرّف السجل، والقيمة المتوقعة، والقيمة الفعلية.
  • تحليل اتجاهات يقارن درجات السلامة عبر آخر عشر دورات اختبار لتحديد أنماط التدهور.
  • إجراءات المعالجة المتخذة (تم التصحيح تلقائياً مقابل تصعيده إلى التطوير).

تُرفَق تقارير سلامة البيانات بتذكرة النشر وتُدرج ضمن حزمة أدلة UAT المقدَّمة إلى العميل.

5.8 اختبار قبول المستخدم الشامل (UAT)

5.8.1 متطلبات ما قبل UAT

لا يجوز للمورّد دعوة العميل لبدء UAT حتى تستوفى المتطلبات التالية:

• (a) يكون قد اكتمل جميع مستويات الاختبار L1–L4 دون وجود أي عيوب P1/P2 معلّقة.
• (b) يُظهر تقرير سلامة البيانات (§5.7.3) معدل اجتياز 100% لجميع التحققات.
• (c) تم تحديث بيئة Staging الخاصة بالعميل بالبناء المرشح.
• (d) تم إعداد قوالب حالات الاختبار وبيانات الاختبار وبيانات اعتماد المستخدمين وإبلاغها إلى قائد UAT المعين لدى العميل.

5.8.2 تنفيذ UAT

ينفَّذ UAT بواسطة الممثلين المعينين لدى العميل باستخدام بيئة Staging. وعلى المورّد ما يلي:

• توفير قوالب منظمة لحالات الاختبار تتماشى مع العمليات التجارية لدى العميل.
  • إعداد بيانات اختبار واقعية تعكس سيناريوهات الإنتاج دون كشف البيانات الشخصية.
  • إتاحة مكتب الخدمة لتسجيل العيوب وفرزها ومعالجتها خلال نافذة UAT.
  • تخصيص مورد QA مخصص من المورّد ليكون حلقة وصل UAT، ومتوافراً للدعم الفوري عبر مجموعة WhatsApp Business المشتركة (§4.4) ونظام التذاكر المدمج (§4.1).

5.8.3 اعتماد UAT

لا يجوز المضي في أي نشر إلى الإنتاج دون اعتماد UAT مكتوب من ممثل العميل المفوّض. ويجب أن تؤكد وثيقة الاعتماد أن العميل قد تحقّق من الإصدار وفق معايير القبول لديه وأنه يصرّح بترقيته إلى الإنتاج.

إذا لم يقدم العميل الاعتماد أو الرفض خلال عشرة (10) أيام عمل من تاريخ بدء UAT، يصدر المورّد تذكيراً خطياً. وإذا لم يرد أي جواب خلال خمسة (5) أيام عمل إضافية، يُعد الإصدار مقبولاً من العميل.

5.8.4 معالجة عيوب UAT

تُدار العيوب التي يتم تحديدها أثناء UAT عبر نظام التذاكر المدمج (§4.1) وتُصنَّف وفق تصنيف الشدة الوارد في §5.6.3. وتُطبَّق القواعد التالية:

• العيوب من النوعين P1/P2: تمنع اعتماد UAT. على المزود معالجة الوظائف المتأثرة وإعادة عرضها ضمن دورة السبرنت الحالية.
  • عيوب P3: لا تمنع الاعتماد. ويجب على المورّد معالجتها في السبرنت اللاحق وتأكيد الإغلاق للعميل.
  • عيوب P4: تُسجَّل في قائمة الأعمال المتراكمة. وتُجدول المعالجة وفق السعة ومدخلات أولوية العميل.

5.9 استشارات تحسين العمليات

5.9.1 نظرة عامة

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

5.9.2 توليد الرؤى

أثناء تنفيذ الاختبارات، تقوم وكلاء الذكاء الاصطناعي بالتقاط وتحليل ما يلي باستمرار:

• (a) أنماط زمن استجابة المعاملات: تحديد خطوات سير العمل التي تستهلك وقت معالجة غير متناسب بشكل متكرر، بما يشير إلى اختناقات محتملة في قواعد العمل أو أنماط الوصول إلى البيانات.
• (b) تكرارات الاستثناءات: حصر حالات فشل التحقق، ورفض قواعد العمل، ورفض الاعتمادات لإظهار نقاط الاحتكاك في العملية التي قد تشير إلى قواعد مهيأة بشكل غير صحيح أو إرشادات مستخدم غير واضحة.
• (c) شذوذات جودة البيانات: اكتشاف أنماط السجلات غير المكتملة، أو الإفراط في استخدام القيم الافتراضية، أو أخطاء إدخال البيانات المنهجية التي تشير إلى الحاجة لإعادة تصميم النماذج أو تعديل الحقول الإلزامية.
• (d) تعارضات الصلاحيات: تحديد تركيبات الأدوار/الصلاحيات التي تخلق اختناقات اعتماد غير ضرورية أو، على العكس، فجوات في فصل الواجبات.
• (e) الميزات منخفضة الاستخدام: رصد الوحدات أو الميزات المفعّلة والمهيأة لكنها غير المستخدمة في سيناريوهات اختبار واقعية، بما يشير إلى فجوات تدريب محتملة أو تكاليف ترخيص غير ضرورية.

5.9.3 تسليم التوصيات

تكون توصيات تحسين العمليات:

• تم تجميعه: في تقرير منظم لتحسين العمليات بعد كل دورة اختبار رئيسية (إصدار سبرنت أو ترقية).
  • مصنفة: بحسب الأثر (عالٍ/متوسط/منخفض)، والجهد (تغيير تهيئة، تطوير بسيط، تطوير كبير)، والمخاطر (بلا مخاطر، منخفضة المخاطر، تتطلب UAT).
  • مقدمة: إلى العميل خلال مراجعة الخدمة الفصلية (§3.9) بواسطة مدير تقديم الخدمة.
  • متتبعة: كبنود عمل في سجل التحسين المستمر للخدمة (CSI) (§4.10) مع جداول زمنية ومسؤوليات متفق عليها.

5.9.4 حدود النطاق

تُقدَّم استشارات تحسين العمليات على أساس معلوماتي. ويُعد تنفيذ أي توصية تغييراً في التهيئة أو طلب تطوير يخضع لعمليات إدارة التغيير وتخطيط السبرنت السارية (§4.6، §4.7). ولا يجوز للمورّد تنفيذ تغييرات التحسين دون موافقة العميل، وعند الاقتضاء، دون طلب رسمي لتغيير النطاق (§2.7).

5.10 حوكمة الاختبار والتقارير

5.10.1 مستودع أدلة الاختبار

على المورّد الحفاظ على مستودع مركزي غير قابل للتعديل لأدلة الاختبار لكل عميل، ويحتوي على:

• خطط الاختبار ومواصفات حالات الاختبار لكل عملية نشر.
• سجلات تنفيذ وكلاء الذكاء الاصطناعي (آثار التفاعل الكاملة مع API، الطوابع الزمنية، نتائج التحقق).
• تقارير سلامة البيانات (§5.7.3).
• تقارير تحسين العمليات (§5.9.3).
• حزم أدلة UAT (نتائج حالات الاختبار، سجلات العيوب، مستندات الاعتماد).
• سجل تطور مجموعة الانحدار (حالات الاختبار المضافة/المعدلة/المهملة).

تُحتفظ أدلة الاختبار طوال مدة الإطار، بالإضافة إلى اثني عشر (12) شهراً، أو حسب ما تقتضيه لوائح حماية البيانات السارية (المادة 5(1)(e) من GDPR؛ المادة 5 من UAE PDPL)، أيهما أطول.

5.10.2 مقاييس الجودة

على المورّد تتبع والإبلاغ عن مقاييس الجودة التالية، والتي تدرج ضمن مراجعة الخدمة الفصلية (§3.9):

5.10.3 التحسين المستمر

يخضع إطار SQT للتحسين المستمر بما يتماشى مع دورة ديمينغ (خطط-نفّذ-تحقق-اعمل):

• (a) خطط: تتم مراجعة استراتيجية الاختبار وتهيئات وكلاء الذكاء الاصطناعي وتحديثها في بداية كل ربع سنة استناداً إلى اتجاهات مقاييس الجودة وملاحظات العميل.
• (b) نفّذ: تُنشر مجموعات الاختبار المحدثة وتهيئات الوكلاء في بيئة Staging الخاصة بالعميل.
• (c) تحقق: تُقيَّم مقاييس الجودة (§5.10.2) مقابل الأهداف؛ ويُجرى تحليل السبب الجذري لأي إخفاق في تحقيق الهدف.
• (d) اعمل: تُسجَّل الإجراءات التصحيحية والوقائية في سجل CSI (§4.10) وتُنفَّذ في دورات السبرنت اللاحقة.

5.11 الأمن والامتثال

5.11.1 حماية بيانات الاختبار

تخضع جميع بيانات الاختبار المستخدمة في عملية SQT لالتزامات حماية البيانات في هذا الإطار (الفصل [حماية البيانات — مرجع فصل لاحق]). وعلى وجه التحديد:

• يجب إخفاء هوية بيانات الإنتاج أو تشفيرها بالاسم المستعار قبل استخدامها في البيئات غير الإنتاجية، وفقاً للمادة 89(1) من GDPR والمادة 5 من UAE PDPL.
• لا يخزن وكلاء الذكاء الاصطناعي بيانات العميل بعد جلسة الاختبار. فجميع البيانات التي يعالجها وكلاء الاختبار بالذكاء الاصطناعي مؤقتة وتُمحى عند إنهاء الجلسة.
• تكون رموز API محددة بأدنى الصلاحيات المطلوبة، ومحددة زمنياً، وتُلغى تلقائياً عند انتهاء الجلسة.
• تُشفَّر سجلات أدلة الاختبار أثناء التخزين (AES-256) وأثناء النقل (TLS 1.3).

5.11.2 حوكمة الوكلاء

يخضع استخدام المورّد لوكلاء الذكاء الاصطناعي في إطار SQT لما يلي:

• الامتثال لقانون الذكاء الاصطناعي في الاتحاد الأوروبي: تُصنَّف وكلاء الذكاء الاصطناعي المستخدمون في اختبار البرمجيات على أنهم منخفضو المخاطر وفقاً لقانون الذكاء الاصطناعي في الاتحاد الأوروبي (اللائحة (EU) 2024/1689)، إذ يعملون على بيانات غير إنتاجية ضمن بيئة محكومة ولا يتخذون قرارات ذاتية تؤثر في الأشخاص الطبيعيين.
• NIST AI RMF: تتوافق منهجية اختبار الذكاء الاصطناعي لدى المورّد مع مبادئ إطار NIST لإدارة مخاطر الذكاء الاصطناعي (AI RMF 1.0) الخاصة بالصلاحية والموثوقية والمساءلة.
• الإشراف البشري: يعمل وكلاء الذكاء الاصطناعي تحت إشراف بشري. وتخضع جميع نتائج الاختبار، وتوصيات التحسين، وقرارات النشر لمراجعة بشرية وموافقة قبل اتخاذ أي إجراء.
• الشفافية: على المورّد، بناءً على طلب العميل، تقديم وثائق تهيئات وكلاء الذكاء الاصطناعي، ومنطق القرار، وسجلات التفاعل لأي دورة اختبار.

قانون الذكاء الاصطناعي في الاتحاد الأوروبي — اللائحة (EU) 2024/1689 إطار NIST لإدارة مخاطر الذكاء الاصطناعي 1.0

5.12 سجل العمليات

5.12.1 سجل العمليات

5.12.2 مصفوفة RACI

R = مسؤول | A = معني بالمساءلة | C = تتم استشارته | I = يتم إبلاغه

5.12.3 مخطط العملية — دورة حياة جودة البرامج والاختبار