AIM Tech

كتير من الـ Testers أول ما يسمعوا AI Testing، أول حاجة بتيجي في بالهم هي الـ Accuracy.
هل الموديل بيطلع النتيجة الصح؟ وهل نسبة الدقة عالية؟ 🤔

لكن الحقيقة إن فيه حاجة أخطر بكتير من مجرد الـ Accuracy... وهي:
**Robustness Testing** أو **Adversarial Testing**.

الفكرة هنا إننا مش بنختبر الـ AI Model بمدخلات "طبيعية" بس، لكن بنحاول نشوف هيستجيب إزاي لو اتعرض لـ Inputs غير متوقعة أو فيها تعديلات بسيطة جدًا، أحيانًا العين البشرية أصلًا متلاحظهاش، لكنها ممكن تخلي الموديل يدي Prediction مختلف تمامًا. 🤯

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

وده ليه مهم جدًا بالنسبة لينا

لأن دورنا مش إننا نثبت إن الـ AI بيشتغل في الظروف المثالية، لكن إننا نحاول نكسره قبل ما المستخدم الحقيقي يعمل ده.

الـ Robustness Testing بيساعدنا نكتشف:
✅ هل الموديل هيصمد قدام Inputs غير مألوفة؟
✅ هل ممكن حد يتلاعب بالمدخلات ويخليه يطلع نتائج خاطئة؟
✅ هل الموديل فعلًا فهم الـ Patterns، ولا بيعتمد على Features سطحية ممكن تتغير بسهولة؟

ودي واحدة من أهم الفروقات بين Testing التطبيقات التقليدية وTesting أنظمة الذكاء الاصطناعي...
في الـ AI، النجاح مش إن الموديل يجاوب صح في الـ Happy Path، لكن إنه يفضل موثوق حتى في أصعب السيناريوهات.

**سؤال للنقاش:**
لو كنت بتختبر AI Model، إيه أول سيناريو هتحاول "تكسر" بيه الموديل؟ 👇

أكبر غلطة ممكن يقع فيها أي تيستر …

إنه يسأل:
"إزاي أختبر الـ System؟"

قبل ما يسأل:
"هو الـ System متبني إزاي؟"🤔

لأن الحقيقة إن أفضل Testing Strategy مش بتبدأ من كتابة الـ Test Cases…

بتبدأ من فهم الـ Software Architecture.

الـ Architecture هي اللي بتحدد:
📌 إيه أكتر الأماكن المعرضة للمخاطر؟
📌 أركز على أنهي نوع Testing؟
📌 وإيه الأدوات والتقنيات المناسبة للسيستم ده؟

خلينا نشوف الفرق.

لو السيستم Monolith

كل الـ Components غالبًا شغالة داخل Application واحدة.

وده بيخلي الـ Integration Testing أبسط نسبيًا…

لكن في المقابل، أي تغيير صغير ممكن يأثر على أجزاء كتير من السيستم بسبب الـ Tight Coupling.

عشان كده، غالبًا هتركز على:

✅ End-to-End Testing
✅ Regression Testing
✅ Performance Testing
✅ التأكد من استقرار النظام بعد كل Release

---

أما لو السيستم Microservices

فالوضع بيختلف تمامًا.

كل Service مستقلة، وليها مسؤولية محددة، وغالبًا بتتواصل مع باقي الخدمات عن طريق APIs أو Events.

وده معناه إن التحديات نفسها بتتغير.

بدل ما تسأل:
"هل الـ Feature شغالة؟"

هتسأل:

🔹 هل الـ Services متوافقة مع بعض؟
🔹 هل الـ Contracts بين الـ APIs مستقرة؟
🔹 إيه اللي هيحصل لو واحدة من الـ Services وقعت؟
🔹 وهل البيانات هتفضل Consistent بين الخدمات المختلفة؟

وهنا بيبقى التركيز على:

✔️ Contract Testing
✔️ Service-Level Testing
✔️ API Testing
✔️ Distributed Tracing & Logging

---

ولو Architecture بتعتمد على Events أو Serverless…

فأنت مش بس بتختبر Function Calls.

أنت بتختبر رحلة كاملة من الأحداث.

لازم تتأكد إن:

📌 الـ Events بتوصل بالترتيب الصحيح.
📌 الـ Triggers شغالة في الوقت المناسب.
📌 الـ Handlers بتنفذ المطلوب بدون فقدان للبيانات.
📌 والـ Monitoring والـ Observability قادرين يوضحوا أي مشكلة بتحصل خلف الكواليس.

---

عشان كده فهمك للـ Software Architecture مش مجرد Knowledge إضافية.

هو اللي بيساعدك:

🎯 تحدد الـ Risks الحقيقية.
🎯 تبني Testing Strategy مناسبة لكل System.
🎯 تختار الـ Tools والـ Frameworks الصح.
🎯 وتوجه فريقك يختبر الأماكن اللي فعلًا تستحق التركيز.

💡 لأن السؤال مش:

**"إزاي أختبر؟"**

السؤال الحقيقي هو:

**"إيه اللي محتاج يتختبر… وليه؟"**

وده هو الفرق بين تنفيذ التستات…

وبين بناء **Testing Strategy** فعالة

إيه أكتر Software Architecture غيرت طريقة تفكيرك في الـ Testing؟
وهل حسيت إن استراتيجيتك اختلفت لما اشتغلت على Microservices أو Event-Driven Systems؟

لو عجبك موضوعنا النهارده ما تنساش تزور موقعنا https://aimtech.online/posts وتكمل رحلتك في عالم السوفتوير تيستنج

الـ AI مش دايمًا بيديك إجابة واحدة تقدر تقول عليها: صح أو غلط. 🤔

وده واحد من أكبر التحديات في الـ AI Testing.

في الـ Traditional Software Testing، الموضوع غالبًا بيكون أوضح:

عندي Input معين، وExpected Output معروف.

لكن لما بنتعامل مع AI Models، خصوصًا الـ Models اللي بتطلع Probabilistic Outputs، فالموضوع بيختلف تمامًا.

ممكن نفس الـ Input يطلع Outputs مختلفة…
وممكن أكتر من Output يكون مقبول…
وممكن الـ Output يكون "صحيح" من ناحية، لكنه غير مفيد أو غير عادل من ناحية تانية.

هنا السؤال بيكون:

**إزاي نحدد الـ Expected Result لما مفيش دايمًا إجابة واحدة صحيحة؟** 🧐

خلينا ناخد مثال من واحدة من أشهر تقنيات الـ Software Testing:

# # # Boundary Value Analysis

في الـ Traditional Testing، بنركز على الـ Boundaries بتاعة الـ Input Range.

مثلاً:
لو الـ Age المسموح من 18 لـ 60، هختبر:

🔹 17
🔹 18
🔹 19
🔹 59
🔹 60
🔹 61

لكن مع الـ AI Models، الـ Boundaries مش دايمًا أرقام واضحة.

ممكن تكون الـ Boundary مرتبطة بـ:

📌 نوع أو توزيع الـ Data.
📌 حجم أو جودة الـ Input.
📌 اختلاف الـ User Demographics.
📌 الـ Confidence Level للـ Model.
📌 أو إن الـ Input يكون Out of Distribution تمامًا عن الـ Training Data.

ودي بالذات الأماكن اللي ممكن تظهر فيها مشاكل خطيرة، زي:

❌ Bias في الـ Model.
❌ Unexpected Behavior.
❌ Outputs غير دقيقة.
❌ Model بيشتغل كويس مع نوع معين من البيانات ويفشل مع نوع تاني.
❌ أو Security Vulnerabilities ممكن يتم استغلالها.

والأهم…

الـ Fail في الـ AI مش لازم يكون Crash أو Error Message. 🚨

ممكن الـ Model يشتغل عادي جدًا…

لكن يطلع:

🔹 Output غير دقيق.
🔹 Prediction غير Fair.
🔹 إجابة مش Explainable.
🔹 أو Result صحيح تقنيًا، لكنه مش Useful للـ User.

عشان كده، الـ AI Testing محتاج نفكر في الـ Testing Oracles بشكل مختلف.

مش بس بنسأل:

**"هل الـ System اشتغل؟"**

لكن كمان:

🧠 هل الـ Model Robust؟
⚖️ هل الـ Output Fair؟
🔍 هل نقدر نفهم ليه الـ Model وصل للنتيجة دي؟
📊 هل أداء الـ Model ثابت مع اختلاف الـ Data؟
🌍 وإيه اللي بيحصل لما نخرج عن الـ Data اللي اتدرب عليها؟

وده بيخلينا ننتقل من Testing الـ Code Logic…

إلى Testing الـ **Model Behavior and Intelligence** نفسها. 🚀

💡 كل ما فهمك للـ AI Model والـ Data اللي بيتعامل معاها يكون أعمق، كل ما قدرت تكتشف Bugs مش هتظهر في الـ Happy Path التقليدي.

إيه أكتر تحدي شايفه في الـ AI Testing؟
هل هو تحديد الـ Expected Output؟ ولا التعامل مع الـ Bias والـ Unexpected Behavior؟ 👇

كتير من الـ Testers بيشوفوا الـ Database كأنها مجرد مكان بتتخزن فيه الداتا اللي بتظهر على الـ UI. 📉

لكن الحقيقة إن الـ Database مش مجرد Storage…

دي واحدة من أهم الأماكن اللي ممكن تكتشف فيها Bugs خطيرة، مشاكل في الـ Business Logic، وثغرات ممكن تأثر على الـ System كله. 😱

ممكن الـ UI يقولك إن كل حاجة تمام…

لكن في الـ Backend تكتشف إن:
❌ الداتا اتخزنت بشكل غلط.
❌ الـ Transaction اتنفذت جزئيًا وسابت بيانات ناقصة.
❌ حصلت Race Condition بسبب Concurrent Requests.
❌ فيه Data Inconsistency بين أكتر من Table.
❌ Query بطيئة جدًا لما حجم الداتا يزيد.
❌ أو حتى فيه ثغرة SQL Injection ممكن تعرض بيانات حساسة للخطر. 🛡️

عشان كده، كـ QA، فهمك للـ Database مش رفاهية.

لازم تكون فاهم:

🔹 الـ Database Schema وشكل الـ Tables.
🔹 الـ Relationships والـ Constraints بين الـ Tables.
🔹 إزاي الـ Transactions بتشتغل وإمتى يحصل Commit أو Rollback.
🔹 تأثير الـ Stored Procedures والـ Triggers على الـ Business Logic.
🔹 إزاي تختبر الـ Data Integrity مع الـ Concurrent Requests.
🔹 وتأثير الـ Indexing والـ Queries على الـ Performance.

لأنك لما تبدأ تختبر الـ Data Layer، أنت مش بس بتتأكد إن الـ Feature شغالة…

أنت بتتأكد إن الداتا:
✅ صحيحة.
✅ Consistent.
✅ آمنة.
✅ وقادرة تتحمل حجم الاستخدام الحقيقي.

وهنا بيبدأ الفرق بين إنك تختبر إن الـ System "بيشتغل"…

وإنك تختبر إن الـ System **Reliable, Secure, and Scalable**. 🚀

💡 كل ما فهمك للـ Database يكون أعمق، كل ما قدرت تكتشف Bugs أبعد بكتير من اللي المستخدم ممكن يشوفه على الـ UI.

إيه أكتر تحدي واجهك في Database Testing؟
وهل قابلت قبل كده Bug كان الـ UI بيقول إن كل حاجة تمام، لكن المشكلة كانت في الـ Database؟ 👇