حدود الذكاء الاصطناعي: لا يُمكنه تقييم مخرجاته ذاتيًا

يُغير الذكاء الاصطناعي بسرعة طريقة تصميم البرمجيات وكتابتها واختبارها. فبإمكان فرق التطوير الآن استخدام الذكاء الاصطناعي لتوليد التعليمات البرمجية، وإنشاء حالات الاختبار، وتحديد العيوب المحتملة، وأتمتة مهام ضمان الجودة (QA) المتكررة، وذلك بسرعة كانت تبدو غير واقعية قبل بضع سنوات فقط.

هذه السرعة لها قيمة كبيرة، لكنها في الوقت نفسه تخلق مشكلة جديدة في ضمان الجودة.

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

بعبارة أخرى، لا يمكن للذكاء الاصطناعي أن يكون الحكم الوحيد على عمله الخاص. وهذا ما يجعل الاعتماد الكلي عليه أمرًا غير حكيم.

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

الافتراضات المشتركة تخلق نقاط عمياء مشتركة

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

وينطبق المبدأ نفسه على الذكاء الاصطناعي.

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

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

والنتيجة يمكن أن تكون نظامًا متسقًا من الناحية التقنية، لكنه خاطئ من الناحية العملية.

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

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

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

النجاح الوظيفي ليس نجاح المستخدم

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

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

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

من منظور النظام، قد تكون البرمجيات قد تصرفت بشكل صحيح. أما من منظور المستخدم، فقد فشلت.

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

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

لماذا يُعد التحقق البصري مهمًا

يوفر التحقق البصري لواجهة المستخدم منظورًا مستقلاً، لأنه يختبر النتيجة المعروضة للمستخدم بدلاً من الاعتماد فقط على البنية الداخلية للتطبيق.

هذا الاستقلال له أهمية كبيرة. فالاختبارات المعتمدة على الكود غالبًا ما تعتمد على معرفة بالنظام الذي تختبره: مثل معرفات الكائنات (object identifiers)، وهياكل المستندات، وتسميات إمكانية الوصول (accessibility labels)، وواجهات برمجة التطبيقات (APIs)، أو استجابات البيانات المتوقعة. بينما يمكن للتحقق البصري تقييم الواجهة النهائية كما تُعرض للمستخدم، بما في ذلك التخطيط، والموضع، والمحتوى، والحالة، وسهولة الاستخدام عبر بيئات مختلفة.

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

يؤكد الاختبار الوظيفي أن العملية اكتملت بشكل صحيح؛ بينما يؤكد التحقق البصري أن النتيجة معروضة بدقة واتساق، وأنها تظل قابلة للاستخدام. يتطلب ضمان الجودة الموثوق به كلاهما طوال دورة حياة التطوير.

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

يعمل التحقق البصري كضمان لسد الفجوة بين التنفيذ التقني والتجربة البشرية.

التكرارية تحوّل الأتمتة إلى دليل موثوق

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

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

يُعد الذكاء الاصطناعي فعالاً في توليد الأفكار والبرامج النصية وسيناريوهات الاختبار المحتملة، لكن الأنظمة التوليدية والوكيلة (generative and agentic systems) ليست ضوابط حتمية بطبيعتها. يمكن أن تختلف مخرجاتها بسبب التوليد الاحتمالي، وتغيرات الأوامر والسياق، وتحديثات النماذج، ونتائج الاسترجاع، والقرارات التي يتخذها الوكيل عند اختيار الأدوات وتخطيط حركته التالية. بالنسبة لتطوير البرمجيات، يمكن لهذه المرونة أن تسرع عملية الاكتشاف. أما بالنسبة لضمان الجودة الرسمي، فإنها تخلق مشكلة تحكم جوهرية.

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

عندها فقط يمكن قياس حالات النجاح والفشل بمرور الوقت، وإعادة إنتاج العيوب، والاعتماد على الأدلة في عمليات التدقيق أو البيئات المنظمة.

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

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

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

البيئات المنظمة ترفع المخاطر

لا تتوزع عواقب أخطاء الواجهة بالتساوي.

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

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

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

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

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

في هذه البيئات، لا تُعد الواجهة مجرد طبقة تجميلية؛ بل هي جزء لا يتجزأ من نظام التحكم التشغيلي.

الجمع بين السرعة والتحكم

لا يكمن النهج الأمثل في الاختيار بين الذكاء الاصطناعي وممارسات الجودة الراسخة، بل في إسناد الدور الأنسب لكل منهما.

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

يتيح هذا النموذج الطبقي للمؤسسات الاستفادة من الذكاء الاصطناعي دون الخلط بين الإنتاجية والإثبات.

كما يدرك هذا النموذج أنه لا توجد طريقة اختبار واحدة يمكنها توفير ضمان كامل. ففحوصات مستوى الكود يمكنها تأكيد سلوك المكونات الفردية.

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

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

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

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